Создание
интернет-магазина
на Битрикс
в Нижнем Новгороде

Да, но начнем с ревизии: что реально используется, что ломает работу, и где технический долг. Отталкиваемся от реальной картины, не фантазий.

Значит, интерфейс и права не настроены. Наша студия разработки ограничит критичные действия, настроит роли и сделает админку предсказуемой.

Не обязательно. IT-компания может предложить доработку структуры и внедрение модулей, чтобы улучшить юзабилити без полной переделки.

Причин может быть много: конфликты шаблонов, тяжелые модули, неэффективные запросы. Разберем стек и оптимизируем.

Когда инфоблок с десятками свойств на карточке начинает тормозить выборку при росте каталога за несколько тысяч позиций. Highload-блок хранит данные плоской таблицей без древовидной структуры инфоблока, зато выбирает по множеству свойств заметно быстрее. Историю цены и характеристики туда переносят чаще всего. Категории такая таблица не строит — это закладывают в структуру каталога сразу. Починка постфактум переносит весь каталог. Фильтр не спотыкается на растущем каталоге.

Через типы цен с привязкой к группе пользователей: розничная, накопительная скидка после определённой суммы покупок, партнёрская по отдельному договору. Переход между группами происходит автоматически при достижении порога, без участия менеджера. Скидка на карточке видна только той группе, для которой она настроена — остальные покупатели её просто не видят. Расчёт при этом идёт без участия менеджера.

Копия магазина крутится на отдельном поддомене с той же версией PHP и базой данных, что на бою, и обновляется перед каждой крупной задачей самостоятельным циклом. Новая версия собирается рядом с рабочей, переключение происходит одной командой без простоя для покупателя. Откат при ошибке занимает минуты — старая версия остаётся доступной, пока новая не подтверждена стабильной. Магазин в момент релиза работает без пауз.

Карточка часто отдаёт исходный файл с камеры или от поставщика вместо сжатой версии под размер блока на странице. CDN раздаёт изображения с серверов ближе к покупателю, снимая эту нагрузку с основного хостинга магазина. Формат WebP экономит вес при том же визуальном качестве. Отложенная подгрузка картинок ниже экрана настраивается в стороне от общего кэша страницы. Карточка товара открывается за секунду.

База с телефонами, адресами и историей заказов размещается на сервере в России, без передачи данных за периметр без согласия покупателя. Согласие на обработку фиксируется чекбоксом при оформлении первого заказа, в стороне от согласия на рассылку. Доступ к базе покупателей в админке ограничен по ролям — менеджер склада не видит контакты, если это не нужно для его задачи. Доступ к данным виден в журнале действий.

Смотрим на характер нагрузки. Число товаров само по себе мало что объясняет. «Стандарт» тесен, когда фасетный фильтр по десяткам свойств начинает заметно тормозить страницу категории при одновременных заходах. «Малый бизнес» открывает REST API для внешних систем. Апгрейд считаем под конкретную нагрузку и задачу. Редакцию без расчёта продавать смысла нет. Лишнего в смете при таком подходе нет.

Правило скидки можно завязать на категорию, сумму заказа, конкретный промокод или комбинацию условий одновременно — например, скидка на вторую пару обуви при заказе от определённой суммы. Приоритет между пересекающимися акциями задаём до запуска вручную, иначе система применит только одну по порядку создания правила, и покупатель недосчитается скидки. С заданным приоритетом скидка применяется предсказуемо.

Приложение через тот же API получает каталог, остатки и статус заказа, что и сайт, без дублирования данных на отдельном сервере. Push-уведомление о смене статуса заказа доходит быстрее письма на почту. Разработка приложения поверх готового API обходится дешевле, чем отдельный бэкенд с нуля — данные и так уже структурированы под магазин. Дублей в базе от этого не возникает.

Цена и способ доставки определяются по региону покупателя автоматически, ещё до оформления заказа. Ожидание звонка менеджера теряет заказ. Валюта показа переключается для зарубежного покупателя, но фискальный чек по 54-ФЗ формируется в рублях независимо от витрины. Разные ставки НДС по товарным группам настраиваются в модуле цен в стороне от валютного блока. Чек покупателю приходит всегда в рублях.

Обмен CommerceML идёт по расписанию каждые 10–15 минут, а не раз в сутки, и резерв товара при оформлении заказа списывается на сайте сразу, до подтверждения оплаты. Отменённый заказ возвращает остаток обратным циклом обмена автоматически. Расхождение единиц измерения между системами — самая частая причина дублей, и справочник сверяем до первого запуска. Остаток тогда почти не расходится с реальным.

Покупатель на шаге оформления выбирает службу и способ — курьер, пункт выдачи, почта — и каждая считает стоимость своим API по весу и региону. Если одна служба недоступна, вариант скрывается из списка. Ошибка на весь блок доставки останавливает оформление. Приоритет служб по регионам настраивается до старта продаж. Ручной выбор на каждый заказ не масштабируется. Покупатель видит в списке только живые варианты.

Да, гостевым заказом — имя, телефон и адрес доставки, без пароля и подтверждения почты. Регистрация предлагается уже после оформления как опция для истории покупок. Обязательная регистрация до оплаты теряет покупателя. Длинная форма на этом шаге — частая причина, по которой покупатель уходит с середины оформления, так и не завершив заказ. Оформление в итоге занимает меньше минуты.

Иерархия категорий должна повторять то, как покупатель ищет товар. Внутренняя логика склада покупателю незнакома. Страницы фильтра с несколькими выбранными свойствами закрываем от индексации канонической ссылкой на основную категорию — иначе поисковик видит тысячи почти одинаковых страниц. Хлебные крошки повторяют путь от корня каталога до карточки товара без сокращений. Поисковик в такой структуре не путает страницы.

Оформление заказа каждым способом оплаты, включая отмену и возврат средств. Форма расчёта доставки при недоступном API службы — должна показывать заглушку с телефоном менеджера. Пустое поле читается как поломка. Письма покупателю о статусе заказа и чек проверяются на реальную доставку в ящик. Факт отправки из системы ничего не гарантирует. Без этой проверки дату запуска не подтверждаем. Риск без чек-листа заметно выше обычного.