После обновления Битрикс не работают страницы или формы: план восстановления

01

Сначала остановите потерю заявок, затем ищите причину

Сбой после обновления 1С-Битрикс редко означает, что «сломался весь сайт». Чаще обновлённый модуль, версия PHP или кеш проявляют несовместимость в конкретном шаблоне, компоненте либо обработчике формы. Поэтому первая задача маркетолога или менеджера — не угадать причину, а ограничить ущерб и передать разработчику воспроизводимые факты.

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

Если перестала работать форма, временно обеспечьте резервный канал: заметный телефон, почту, мессенджер или короткую форму стороннего сервиса. Отметьте период инцидента в аналитике. Иначе вы не сможете отличить потерянные обращения от обычного падения спроса и не оцените последствия для рекламы.

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

03

Как отличить сбой страницы от проблемы формы

Для посетителя оба случая выглядят одинаково: страница не открылась или кнопка «Отправить» ничего не сделала. Для диагностики это разные маршруты. Страница проходит веб-сервер, PHP, ядро, компонент, шаблон и базу данных. Форма добавляет JavaScript, AJAX-запрос, проверку полей, почтовое событие, обработчики и передачу в CRM. Ошибка на любом участке может дать сообщение об успехе без новой заявки.

Проверьте форму в двух режимах: с обязательными полями и с намеренно неверным e-mail либо телефоном. В первом случае должна появиться понятная успешная реакция, во втором — валидация без отправки. Затем найдите тестовую заявку в месте назначения: почтовом ящике, списке инфоблока, веб-форме, CRM-лиде или сделке. Зафиксируйте ID сущности, дату, поля и ответственного.

Для рекламных страниц обязательно передайте тестовый URL с utm_source, utm_medium, utm_campaign и уникальным utm_content. После отправки убедитесь, что метки не пропали при редиректе, сохранились в скрытых полях или в CRM и доступны в карточке. Иначе технически работающая форма перестаёт быть источником управляемой аналитики.

04

Где искать следы ошибок Битрикс

Начните с журналов, а не с правок файлов. В административной части проверьте журнал событий и настройки главного модуля: там могут быть записи об ошибках авторизации, почтовых событиях, действиях пользователей и системных исключениях. Для разработчика также важны error_log веб-сервера и PHP, а при включённом режиме отладки — записи, связанные с конкретным запросом.

Выпишите не только фразу «Fatal error», но и путь к файлу, номер строки, класс исключения, URL и время. По этим пяти параметрам можно найти связанный запрос в access-логе и понять, один ли пользователь столкнулся с проблемой. Доступ к логам не следует пересылать в общий чат: в них могут быть пути сервера, параметры запросов и персональные данные.

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

05

Типовые причины после обновления ядра и модулей

Первая группа причин — несовместимость окружения. Новая версия модуля может требовать другой версии PHP, расширения, настроек базы или обновлённого ядра. Вторая — кастомизации: старый шаблон компонента вызывает метод с изменившейся сигнатурой, переопределяет JavaScript или использует удалённое поле. Третья — кеш и композитный режим, когда часть посетителей видит старый HTML, а часть — новый код.

Отдельно проверяйте обработчики событий: обработку отправки формы, создание заказа, синхронизацию с CRM, изменение статуса и генерацию писем. Они часто находятся вне стандартного компонента, например в local/php_interface, подключаемом модуле или агенте. Обновление не обязательно меняет этот код, но может изменить момент его вызова или структуру передаваемых данных.

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

Исправление считается готовым не после исчезновения ошибки, а после успешного прохождения бизнес-сценариев, которые сайт должен выполнять.

06

Порядок восстановления без случайных действий

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

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

После устранения первичной причины тестируйте не один URL, а цепочку. Например: рекламная посадочная с UTM → форма → обработчик → CRM → уведомление менеджеру → отчёт. Такой маршрут показывает, что вы восстановили бизнес-процесс, а не только внешний экран.

1. 1

   Зафиксируйте инцидент. Запишите время, URL, HTTP-код, браузер, действия пользователя и список последних обновлений.

2. 2

   Защитите обращения. Включите временный контактный канал и отметьте интервал сбоя для маркетинга и продаж.

3. 3

   Соберите доказательства. Сохраните логи PHP и сервера, журнал событий, ответ AJAX и данные тестовой отправки.

4. 4

   Проверьте копию. Воспроизведите ошибку на тестовом окружении и подтвердите конкретную причину.

5. 5

   Внесите исправление. Обновите несовместимый код, настройку или окружение с возможностью отката.

6. 6

   Примите результат. Пройдите страницы, формы, CRM, UTM и уведомления; проконтролируйте логи после релиза.

07

Как принять исправление со стороны маркетинга и продаж

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

Тестируйте от имени обычного посетителя, без авторизации в административной части и CRM. Иначе система может подставить данные пользователя, показать скрытые возможности или обойти ограничения, которых нет у клиента. Для контроля CRM создавайте тестовые обращения с заметной меткой, например «ТЕСТ после обновления», а после проверки удаляйте или закрывайте их по внутреннему регламенту.

Попросите показать изменения в списке файлов или через систему контроля версий, а также назвать причину и профилактическую меру. Формулировка «почистили кеш, всё работает» недостаточна, если ошибка появилась после обновления и может вернуться при следующей очистке либо обновлении.

08

Что изменить в процессе следующих обновлений

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

Ведите реестр кастомизаций: какие шаблоны компонентов изменены, где находятся обработчики, кто владелец интеграции, какие ключи API используются и какой бизнес-процесс зависит от каждого узла. Это не документация «для галочки»: при ошибках Битрикс после обновления реестр сокращает поиск с часов до понятного списка проверок.

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

09

Когда достаточно внутренней проверки, а когда нужен подрядчик

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

Подключайте подрядчика, если сайт отдаёт 500, недоступны коммерческие страницы, формы теряют заявки, не создаются сущности в CRM, нарушена оплата или нет уверенности в корректном откате. Особенно рискованна ситуация, когда исправление предлагают сделать прямо на боевом сайте без копии, логов и критериев приемки.

Перед обращением подготовьте URL, время сбоя, список изменений, доступный фрагмент ошибки и описание бизнес-последствия: «не создаются лиды из рекламы», «не проходит заказ», «недоступен каталог». Это позволит сразу определить приоритет. После восстановления не ограничивайтесь сообщением «работает»: пройдите согласованный маршрут пользователя, проверьте данные в CRM и убедитесь, что в логах не появляется новая критическая ошибка.