Когда сайт не открывается, команда часто одновременно проверяет одно и то же. Разработчик смотрит сервер, маркетолог обновляет главную, владелец спрашивает о сроках, а рекламные кампании продолжают вести людей на проблемный путь. Регламент нужен, чтобы быстро превратить сигнал в проверяемый факт и одно решение.
Этот материал не заменяет техническую диагностику. Он задаёт порядок работы между маркетингом, разработкой и владельцем бизнеса. Для постоянного контроля используйте отдельный гайд по мониторингу сайта и рекламы.
Короткий ответ. Сначала подтвердите сбой из независимой точки и определите затронутый бизнес-сценарий. Назначьте одного координатора, ограничьте новые потери, передайте техническую проверку владельцу системы и заранее назовите условия восстановления. Каждое решение запишите со временем и доказательством.
Что считать сбоем сайта
Сбой — это подтверждённое нарушение доступности или ключевого действия. Главная страница может отвечать, пока не работает корзина, форма, вход или оплата. И наоборот: единичная жалоба может быть связана с сетью, регионом, устройством или настройками браузера.
Поэтому первый вопрос звучит не «сайт работает?», а «кто, где и какое действие не может выполнить?». Если проблема проявляется только у части аудитории, переходите к диагностике частичной доступности. Если страница отвечает медленно, но открывается, отдельно проверьте время загрузки и влияние на путь клиента.
| Сигнал | Что подтвердить | Первое решение |
|---|---|---|
| Не открывается весь сайт | Другой канал связи, главная и критичный URL, код ответа | Ограничить трафик и эскалировать техническому владельцу |
| Не работает форма или оплата | Полный путь до системы-получателя | Остановить источник потерь или дать безопасный обходной путь |
| Сбой только у части пользователей | Регион, сеть, устройство, браузер, авторизация | Не объявлять общий отказ до проверки сегмента |
| Сработало автоматическое уведомление | Фактическую страницу и пользовательское действие | Исключить ложное срабатывание и только затем менять кампании |
Первые проверки без предположений
- Запишите время сигнала. Оно понадобится для журналов сервера, Метрики, рекламной статистики и проверки изменений.
- Повторите действие из другой точки. Используйте другое подключение или устройство, а не только обновление той же вкладки.
- Проверьте затронутый путь. Главная, целевая страница и действие заявки или покупки дают разные доказательства.
- Снимите минимальные факты. URL, код ответа, текст ошибки, среда, ожидаемый и фактический результат.
- Проверьте последние изменения. Выпуск, настройки домена, сертификат, защита, интеграция и реклама — список гипотез, а не готовая причина. Для двух первых причин используйте отдельную проверку срока домена и SSL-сертификата.
В Яндекс Вебмастере инструмент «Проверка ответа сервера» показывает код ответа, доступность для роботов и состояние сертификата. Яндекс предупреждает, что ответ инструмента может отличаться от ответа реальному роботу из-за другого IP-адреса. Для окончательного вывода нужны журналы сервера и пользовательская проверка.
Как определить приоритет
Приоритет зависит не от громкости сообщения, а от влияния. Критичный сбой блокирует оплату, заявку, вход или значительную часть сайта. Высокий приоритет получают проблемы без безопасного обходного пути. Ограниченный приоритет — ошибки отдельного сегмента или второстепенной функции, когда основной путь работает.
Не привязывайте приоритет к универсальному сроку из чужого шаблона. Зафиксируйте собственные критерии: какие действия критичны, кто может остановить рекламу, кто принимает решение об откате и какое доказательство достаточно для восстановления.
Роли: кто за что отвечает
Один координатор собирает статус и принимает входящие сигналы. Это не обязательно руководитель и не обязательно разработчик. Координатор следит, чтобы одновременно существовали владелец исправления, решение по трафику и время следующей проверки.
- Технический владелец ищет причину, меняет систему и показывает журналы или результаты проверки.
- Маркетинг оценивает целевой путь, платный трафик, формы и риск новых потерь.
- Коммуникация сообщает только подтверждённое: масштаб, обходной путь и время следующего статуса.
- Владелец решения выбирает восстановление, временное ограничение или откат, если варианты конфликтуют.
Что делать с рекламой во время сбоя
Платный трафик ограничивают, когда подтверждено, что целевая страница или ключевое действие недоступны. Решение должно учитывать не только главную страницу. Если каталог открывается, но заказ не оформляется, доступность главной не защищает бюджет.
В справке Яндекс Директа указано, что мониторинг сайта запрашивает главную страницу и автоматически приостанавливает показы, если сайт недоступен более 15 минут. После восстановления показы возобновляются. Есть ограничения: страница хостинга вместо ошибки может считаться рабочей, а защита сервера способна вызвать ложное срабатывание. Поэтому статус Директа нужно сверять с фактическим бизнес-путём.
Практическое правило. Если реклама ведёт на недоступную страницу или действие, ограничьте показы по согласованному полномочию. Если масштаб неясен, сначала остановите самый рискованный поток, сохраните настройки и назначьте время повторной проверки.
Как использовать Метрику и Вебмастер
Отчёты Яндекс Метрики помогают проверить косвенные признаки: провал просмотров по минутам, изменение времени загрузки и отличие сегментов. Официальная справка отмечает, что работа раздела «Мониторинг» не гарантируется для сайтов с посещаемостью менее 100 просмотров страниц в неделю. Отсутствие резкого провала на малом объёме не доказывает исправность.
Яндекс Вебмастер полезен для доступности страниц поисковому роботу и диагностики поисковых проблем. По справке Яндекса, сведения в диагностике могут обновляться несколько дней. Это инструмент подтверждения поискового состояния, а не замена немедленной пользовательской проверке.
Источники проверены 8 августа 2026 года. Интерфейсы и правила Яндекса могут измениться, поэтому перед обновлением регламента сверяйте актуальную справку Директа, Метрики и Вебмастера.
Как доказать восстановление
Один ответ 200 не закрывает инцидент. Восстановление подтверждают на том уровне, где проявился сбой. Для общей недоступности нужны код ответа, содержимое и проверка из независимой точки. Для формы — успешная отправка и запись в системе-получателе. Для оплаты — полный безопасный тестовый путь. Для частичного сбоя — повторная проверка затронутого сегмента.
- Повторите исходный проблемный сценарий.
- Проверьте критичные соседние страницы и действия.
- Убедитесь, что данные дошли до нужной системы один раз.
- Сверьте рекламу, перенаправления, измерение и поисковые признаки.
- Запишите время восстановления и период наблюдения.
Для интернет-магазина список проверок шире: каталог, карточка, корзина, оплата и подтверждение заказа. Подробный набор есть в статье о мониторинге интернет-магазина.
Журнал решений без лишнего отчёта
Журнал нужен не для поиска виноватого. Он сохраняет факты, чтобы команда не повторяла проверки и могла объяснить решение. Достаточно одной строки на значимое изменение статуса.
| Поле | Что записать |
|---|---|
| Время | Когда пришёл сигнал, когда выполнена проверка и когда изменился статус |
| Симптом и масштаб | URL, действие, сегмент и подтверждённое влияние |
| Доказательство | Код ответа, журнал, снимок, тестовая заявка или отчёт |
| Решение и владелец | Что делаем, кто отвечает и какие изменения временно остановлены |
| Следующая проверка | Время, критерий и человек, который вернётся к вопросу |
Для постоянной истории не создавайте отдельный документ на каждый сбой. Используйте единый журнал инцидентов сайта: он помогает группировать повторения, проверять владельцев и менять саму систему контроля. Если передача регулярно теряет контекст или ответственного, пройдите отдельные семь проверок маршрута эскалации.
Короткий регламент для команды
- Подтвердить сигнал из другой точки и назвать затронутый бизнес-сценарий.
- Назначить координатора, технического владельца и владельца решения по трафику.
- Ограничить новые потери без несогласованных изменений сразу в нескольких системах.
- Исправить причину и повторить исходный сценарий.
- Проверить данные, рекламу и затронутые сегменты.
- Зафиксировать восстановление, доказательство и следующую контрольную точку.
Постоянный контур снижает зависимость от ручной проверки: STRIX ежедневно проверяет подключённые данные Метрики и Директа, показывает события и рекомендации в рабочем кабинете. Это помогает заметить изменение и начать разбор, но не заменяет владельца инцидента и техническое доказательство. Подключение начинается на странице STRIX.
Что делать первым при сбое сайта?
Подтвердите сбой из другого подключения, проверьте затронутые страницы и одно ключевое действие. Затем зафиксируйте время, масштаб и назначьте одного координатора.
Когда при сбое сайта останавливать рекламу?
Остановите или ограничьте кампании, если целевая страница либо ключевое действие недоступны и трафик создаёт потери. Не полагайтесь только на доступность главной страницы.
Как понять, что сайт восстановлен?
Нужен не один код 200, а успешный ключевой сценарий, корректная передача данных и проверка из затронутого сегмента. Результат запишите со временем и ссылкой на доказательство.
Частые вопросы
Что делать первым при сбое сайта?
Подтвердите сбой из другого подключения, проверьте затронутые страницы и одно ключевое действие. Затем зафиксируйте время, масштаб и назначьте одного координатора.
Когда при сбое сайта останавливать рекламу?
Остановите или ограничьте кампании, если целевая страница либо ключевое действие недоступны и трафик создаёт потери. Не полагайтесь только на доступность главной страницы.
Как понять, что сайт восстановлен?
Нужен не один код 200, а успешный ключевой сценарий, корректная передача данных и проверка из затронутого сегмента. Результат запишите со временем и ссылкой на доказательство.
Дальше по теме
