Интеграции Битрикс: что ломается при смене платформы

Короткий план: сначала разберём, почему переезд с Битрикс бьёт не по дизайну, а по связям между системами. Потом пройдёмся по 1С, CRM, оплатам, аналитике, SEO и вебхукам. В финале — практичный чек-лист перед запуском.

Переезд сайта — это не только новый движок

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

Вот тут и начинается настоящая миграция. Особенно если речь про 1С-Битрикс: Управление сайтом или связку с Битрикс24. В Битрикс часто годами накапливаются доработки: кастомные обработчики, агенты, обмены, старые вебхуки, самописные модули. Они могут выглядеть как «пара строк кода», но держать на себе продажи. Честно говоря, это как переезд офиса: мебель перевезли, вывеску повесили, а телефон, кассу и доступ к складу забыли подключить.

Первой обычно страдает 1С

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

Что ломается при смене платформы? Не только сама выгрузка. Часто «едут» внешние идентификаторы товаров, торговые предложения, свойства SKU, статусы заказов, склады, типы цен и правила скидок. В Битрикс товар мог жить как инфоблок с торговыми предложениями, а на новой CMS модель данных другая. Один размер потерялся, второй цвет стал отдельным товаром, остатки приехали не на тот склад — и менеджер уже вручную тушит пожар.

Поэтому до переноса надо выгрузить карту соответствий: старый ID товара, XML_ID, артикул, торговое предложение, категория, склад, цена, НДС, статус заказа. Скучно? Да. Зато потом не будет грустного звонка: «Почему клиент купил товар, которого нет?»

CRM и лиды: тихий сбой, который дорого стоит

Следующий кандидат на поломку — CRM. Если сайт отправлял заявки в Битрикс24, то при смене платформы меняются формы, поля, события, источники и логика создания лидов. В Битрикс24 для доработок применяются вебхуки, приложения и REST API; в справке Битрикс24 указано, что эти инструменты собраны в разделе для разработчиков, а вебхук отслеживает изменения на одном сайте и передаёт данные на другой. Подробнее — в справке Битрикс24 для разработчиков.

В чём подвох? Форма на новом сайте может визуально работать: кнопка нажимается, «спасибо» показывается. Но в CRM не попадает UTM-метка, не создаётся сделка, не назначается ответственный, не срабатывает робот. Или заявка приходит, но в неверную воронку. Это особенно неприятно для рекламы: лид вроде есть, а атрибуция пропала, и маркетолог видит туман вместо отчёта.

Отдельная история — лимиты REST API. В официальной документации Bitrix24 указано, что при превышении суммарного времени выполнения запросов по методу за 10 минут метод может быть временно заблокирован для приложений и вебхуков портала; там же приводится пример, что даже 2 запроса в секунду дают 172 800 запросов в день. Смотрите раздел REST API Limits. На практике это значит простую вещь: массовый импорт, пересинхронизация заказов и фоновые роботы нельзя запускать «как получится». Нужны очереди, паузы и повторные попытки.

Оплата, доставка и касса: мелочей тут нет

Платёжные модули при переезде любят преподносить сюрпризы. Старый сайт мог передавать в платёжный шлюз один набор параметров, новый — другой. Где-то изменился номер заказа, где-то сумма с учётом скидки считается иначе, где-то callback-адрес остался старым. Итог простой: клиент оплатил, а заказ висит как неоплаченный. Приятного мало.

То же касается доставки. СДЭК, Boxberry, Почта России, Яндекс Доставка и другие службы зависят от веса, габаритов, адресных полей, кодов регионов, статусов и тарифных настроек. Если при миграции часть свойств товара не переехала, расчёт доставки может стать нулевым, завышенным или вовсе недоступным. А знаете что? Иногда ломается не интеграция, а привычный порядок полей в форме. Для пользователя это выглядит как «сайт не даёт оформить заказ».

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

Аналитика: когда продажи есть, а данных нет

После переезда часто выясняется, что отчёты стали «красивыми, но пустыми». Причина банальна: на новой платформе забыли перенести цели, события, dataLayer, электронную коммерцию, пиксели рекламных кабинетов, call tracking и сквозную аналитику. Google в справке по GA4 прямо пишет: данные e-commerce не отправляются автоматически, для них нужны события на сайте или в Google Tag Manager; проверять настройку можно через DebugView. Это описано в документации Google Analytics.

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

SEO: редиректы не любят спешку

При смене платформы почти всегда меняются URL. Битрикс мог формировать адреса через ЧПУ, разделы инфоблоков, фильтры и параметры. Новая CMS может собрать структуру иначе. Если не сделать карту старых и новых страниц, поисковые системы увидят пачку дублей, 404 и странных переходов.

Google рекомендует при переезде с изменением URL подготовить сопоставление старых и новых адресов, настроить постоянные серверные редиректы и не вести много старых страниц на одну нерелевантную страницу, например на главную. Подробности есть в Google Search Central. Яндекс тоже советует настраивать 301 редирект со старого адреса на новый, добавлять новые страницы в Sitemap и проверять доступность важных страниц для робота; это описано в справке Яндекс Вебмастера.

Что ломается чаще всего? Фильтры каталога, пагинация, canonical, robots.txt, sitemap.xml, хлебные крошки, микроразметка, страницы тегов и старые посадочные под рекламу. Ещё одна типичная беда — внутренние ссылки на старые адреса. Редирект вроде есть, но сайт сам гоняет пользователя по лишнему кругу. Это и медленнее, и для краулинга хуже.

Самописные модули: тот самый шкаф без подписи

В проектах на Битрикс часто живут доработки, о которых никто не помнит. Агент раз в ночь выгружает прайс партнёру. Обработчик меняет статус заказа после оплаты. Скрипт добавляет клиента в рассылку. Маленький файл в init.php чинит скидки. Всё работает годами — и потому кажется частью платформы. Но это не платформа. Это наследство.

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

Чек-лист перед сменой платформы

• Соберите карту интеграций: 1С, Битрикс24, платежи, доставка, кассы, телефония, рассылки, аналитика, фиды, маркетплейсы.
• Зафиксируйте поля данных: ID, XML_ID, артикулы, цены, остатки, статусы, UTM, client_id, номера заказов.
• Сделайте URL-карту: старый адрес, новый адрес, тип редиректа, приоритет страницы, трафик.
• Проверьте тестовые сценарии: заявка, заказ, оплата, возврат, доставка, смена статуса, письмо клиенту, лид в CRM.
• Запланируйте мониторинг: 404, ошибки API, скорость, логи обмена, падение целей, расхождение заказов между сайтом и CRM.

Главная мысль: переезжает не сайт, а бизнес-процесс

Смена платформы после Битрикс может пройти спокойно. Правда. Но только если относиться к ней не как к замене шаблона, а как к переносу живой системы. У сайта есть нервы — интеграции. Есть память — база данных. Есть голос — формы, звонки и письма. Есть репутация в поиске — URL, контент и ссылки.

Хорошая миграция начинается не с макета, а с вопроса: «Что должно продолжить работать в первый час после запуска?» Ответ обычно отрезвляет. Заказы должны уходить в 1С. Лиды — в CRM. Деньги — подтверждаться. Доставка — считаться. Аналитика — видеть путь клиента. Поиск — понимать, куда переехали страницы.

Если всё это проверено заранее, новый сайт ощущается как аккуратный ремонт, а не как переезд с потерянными коробками. И да, нервы команды тоже остаются целее.