Техподдержка сайтов
на Битрикс
в Нижнем Новгороде

Мы проверяем совместимость плагинов, восстанавливаем корректные сценарии и тестируем процесс до успешного платежа.

Да. Настраиваем интеграции, проверяем тарифы и корректность расчетов по регионам.

Настраиваем SMTP, чиним триггеры писем и следим, чтобы сообщения доходили.

Оптимизируем запросы к базе, настраиваем кеширование и ускоряем отображение карточек.

Да. Полный цикл: доступ к серверу по SSH, тестовый контур для проверки, скринкаст вместо очной встречи. Перенос на новый сервер, смена версии PHP, настройка почты на домене — всё делается удалённо через панель хостинга. Выезд обсуждаем только для старых серверных инсталляций без удалённого доступа, а таких сайтов на актуальной версии Bitrix почти не осталось.

Дубль появляется, когда символьный код товара в 1С и на сайте различается хотя бы одним символом. Система создаёт новую карточку вместо обновления существующей. Перед первым запуском обмена сверяем справочник артикулов вручную, а не полагаемся на автосопоставление по названию. Найденные дубли объединяем через встроенный инструмент склейки элементов, сохраняя историю заказов по обеим карточкам. После такой выверки повторный конфликт — редкость.

Устанавливаем обновление на тестовый контур и проходим ключевые сценарии руками: оформление заказа, работу личного кабинета, критичные интеграции. Лог ошибок PHP смотрим тоже, за первые пятнадцать минут — многие конфликты видны сразу. Чисто — ставим ночью, на минимальной нагрузке. План отката готовим до апдейта: снятый бэкап плюс зафиксированная версия модуля, которую можно вернуть за пару минут.

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

Обычная причина — задержка вебхука на стороне банка, а не ошибка на сайте. Система должна показать заказ в статусе «ожидает оплату», а не молча зависать. Опрос статуса повторяем через API. Не пришёл вебхук за пару минут — запрос уходит снова. Оплата прошла, а заказ не обновился? Тогда нужно проверить очередь обработки вебхуков на сервере, а не винить банк без разбора.

Да, если у компании работают сразу СДЭК, Boxberry и своя курьерка, статусы можно свести в один раздел личного кабинета. Каждая служба присылает данные в своём формате — нужен слой преобразования на стороне сайта. Клиент видит единый таймлайн заказа. Курьер меняется — вид не меняется. Настройка занимает больше времени, чем одна интеграция, но снимает путаницу у покупателей.

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

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

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

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

Файл robots.txt должен закрывать служебные разделы — корзину, личный кабинет, результаты поиска, но не сам каталог. Карта сайта обновляется сама, при добавлении товаров, а не вручную раз в месяц. Пагинацию каталога размечаем через rel=canonical на первую страницу раздела. Вторые и третьи страницы листинга не конкурируют друг с другом в поиске.

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

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

Технически это несложно. Поле добавляется через административный интерфейс за несколько минут. Сложность в другом: если поле уже используется в компонентах вывода и фильтрах, изменение типа данных задним числом требует правки кода сразу в нескольких местах. Структуру полей лучше продумывать до заполнения большим объёмом данных, а не расширять хаотично по ходу работы. Экономия времени заметнее всего на масштабе, когда поле используется в десятке разных мест сайта.