Главное за минуту
- Сразу сохраните URL, время сбоя, скриншот и действия перед ошибкой.
- Проверьте страницу в инкогнито и с телефона, не очищая кеш наугад.
- Передайте доступы и логи только через защищённый канал, не в общий чат.
- Принимайте работу после проверки страниц, форм, CRM и журналов ошибок.
01
Что означает белый экран в Битрикс
Белая страница появляется, когда сервер не смог корректно выполнить PHP-код, а вывод ошибки отключён для посетителей. Частые причины: обновление модуля, конфликт шаблона, нехватка памяти, ошибка в компоненте, правах файлов или подключении к внешнему сервису.
Для маркетолога задача не в поиске строки кода. Нужно быстро понять масштаб: не работает один URL, раздел, административная часть или весь сайт; затронуты ли формы и рекламные посадочные. Это определяет срочность и порядок действий поддержки.
02
Карточка инцидента
Одна структурированная карточка сокращает переписку и время первичной диагностики.
03
Что собрать до обращения в поддержку
Не меняйте настройки и не запускайте обновления до фиксации фактов: это может стереть следы сбоя.
Сценарий
Укажите точный URL, устройство, браузер, авторизован ли пользователь и последовательность кликов. Отдельно отметьте, воспроизводится ли проблема в инкогнито.
Время и охват
Запишите время по МСК, первый известный случай и список затронутых страниц. Проверьте главную, каталог, корзину, форму и админ-раздел.
Изменения
Перечислите публикации, импорт, обновления, правки шаблона, настройку сервера и интеграции за последние сутки. Не удаляйте кеш как «лечение».
04
Какие данные нужны разработчику
Скриншот сам по себе редко показывает причину. Передайте наблюдаемые данные и попросите специалиста проверить логи сервера, PHP и Битрикс. Пароли, ключи API и резервные копии не размещайте в задаче: используйте защищённый менеджер доступа.
| Что передать | Пример | Зачем это нужно |
|---|---|---|
| URL и сценарий | /catalog/; после фильтра | Отделить сбой страницы от общего |
| Время и охват | 14:35 МСК; весь каталог | Найти запись в логах и оценить риск |
| Последние изменения | Обновили модуль доставки | Проверить вероятную точку регрессии |
| Проверка результата | Страница, форма, письмо, CRM | Не закрыть задачу после одного URL |
05
Готовая постановка задачи
Замените значения в шаблоне своими. Если сайт недоступен полностью или перестали поступать заказы, отметьте инцидент как критичный и укажите контакт для оперативного согласования.
06
Как действовать в первые 30 минут
Цель — сохранить продажи и данные для диагностики, а не самостоятельно «вылечить» сайт случайными действиями.
- 1Зафиксируйте URL, время МСК, экран и последовательность действий.
- 2Проверьте главную, ключевые посадочные, форму и админку с другого устройства.
- 3Оцените последствия: реклама, корзина, онлайн-оплата, заявки и CRM.
- 4Сообщите поддержке по шаблону и обозначьте уровень срочности.
- 5После исправления повторите сценарий и проверьте логи за период сбоя.
07
Что попросить проверить технически
Маркетологу не нужно выдавать диагноз. Достаточно обозначить зоны проверки и запросить понятный отчёт. Это защищает от исправления симптома, после которого ошибка возвращается на другой странице.
Логи и среда
Пусть исполнитель сопоставит время сбоя с error_log PHP, журналом веб-сервера и событиями Битрикс, затем проверит лимиты памяти и права.
PHP error_log + журнал событий + HTTP-ответРегрессия
Попросите назвать изменение, вызвавшее сбой, и проверить откат или исправление на копии сайта до работ в боевой среде.
причина → исправление → тест → мониторинг08
Как принять исправление
Закрывайте задачу не после слов «сайт открылся», а после согласованного сценария. Разработчик должен показать причину, внесённое изменение и отсутствие новых критичных ошибок в логах после теста.
Страница открывается у гостя и авторизованного пользователя; ключевые формы отправляют данные; тестовая заявка дошла в CRM; нет ошибок 500 и белых страниц; кеш и права не менялись без согласования; получен отчёт о причине и профилактике.
FAQ
Частые вопросы
Можно ли просто включить вывод ошибок?
На боевом сайте — только временно и для ограниченного доступа: ошибки могут раскрыть пути, настройки и данные. Безопаснее анализировать серверные логи.
Нужно ли очищать кеш при белом экране?
Только по решению исполнителя. Очистка может временно изменить симптом и осложнить поиск причины.
Почему страница белая, а статус 200?
Некоторые ошибки прерывают формирование HTML без корректного кода ответа. Это нужно проверить в логах PHP и веб-сервера.
Когда это критический инцидент?
Если недоступны главная, каталог, корзина, оплата, формы или админка; также когда сбой затрагивает рекламный трафик и заявки.