Контроль сайта после релиза начинается не с просмотра главной страницы. Нужно доказать, что изменённые страницы, ключевой путь клиента и измерение работают вместе. Иначе зелёный экран скрывает потерянную заявку, сломанную цель или закрытый от поиска раздел.
Маркетологу не нужно заменять тестировщика и разработчика. Его задача — заранее назвать критичные бизнес-сценарии, проверить результат с позиции посетителя и зафиксировать отклонение так, чтобы команда могла принять решение.
Короткий ответ. До выпуска сохраните контрольные значения и назначьте ответственных. Сразу после релиза проверьте доступность, один полный бизнес-сценарий, передачу заявки, цели Метрики и поисковые признаки. Затем наблюдайте сегменты и держите готовым критерий отката.
Что считать релизом сайта
Релизом считается любое изменение, способное повлиять на путь пользователя или измерение: новый шаблон, форма, платёжный шаг, счётчик, интеграция, перенаправление, меню, домен, система управления сайтом или правило защиты.
Масштаб проверки зависит от радиуса изменения. Новый текст в одной карточке не требует полного аудита. Замена шаблона каталога требует проверки всех его состояний, мобильного вида, форм, разметки и нескольких типовых URL. Для широкой диагностики используйте отдельный чек-лист технического аудита, а для повторяемого контроля ширин и действий — инструкцию по мониторингу мобильной версии сайта.
| Изменение | Минимальный объём проверки | Главное доказательство |
|---|---|---|
| Текст или изображение | Изменённая страница и мобильный вид | Контент виден, ссылка и сценарий не нарушены |
| Форма или интеграция | Отправка от поля до системы-получателя | Заявка сохранена, цель передана один раз |
| Шаблон раздела | Типовые URL, состояния и устройства | Статус, основной адрес страницы, контент и действия корректны |
| Домен, адреса или перенаправления | Карта старых и новых URL | Ответы сервера, цепочки и поисковые признаки |
Что подготовить до выпуска
Послерелизная проверка слаба без точки сравнения. До выпуска сохраните список изменённых URL, контрольные снимки, ожидаемые статусы, тестовую заявку и значения ключевых показателей за сопоставимый период.
- Объём: какие страницы, шаблоны, формы и интеграции изменяются.
- Критичные пути: вход, поиск, заявка, корзина, оплата или скачивание.
- Ожидание: какой результат подтверждает каждый шаг.
- Владельцы: кто проверяет интерфейс, данные, поиск и инфраструктуру.
- Откат: при каких симптомах выпуск останавливают и кто принимает решение.
Для регулярного контроля полезно заранее выбрать важные страницы сайта. Тогда после выпуска команда проверяет не случайные URL, а приоритетный набор.
Чек-лист первых 30 минут
- Откройте изменённые и критичные URL. Проверьте код ответа, содержимое и отсутствие циклических перенаправлений.
- Пройдите ключевой путь. Выполните действие как новый посетитель на настольном и мобильном экранах.
- Проверьте конечную систему. Убедитесь, что заявка, заказ или событие дошли до ожидаемого получателя.
- Проверьте измерение. Счётчик загружается, цель фиксируется один раз, источник и адрес страницы не потеряны.
- Проверьте поисковые признаки. Основной адрес страницы, правила индексирования, карта сайта и содержимое страницы соответствуют плану выпуска.
- Посмотрите ошибки браузера. Отделите критичные ошибки страницы от стороннего шума и предупреждений расширений.
- Запишите результат. URL, время, среда, ожидаемый и фактический результат, владелец и следующее действие.
Как подтвердить результат инструментами
Доступность и поисковый робот
В Яндекс Вебмастере инструмент «Проверка ответа сервера» показывает доступность страницы для роботов, код ответа и состояние сертификата. Яндекс отмечает, что ответ инструмента может отличаться от реального ответа роботу из-за другого IP-адреса. Поэтому сверяйте результат с журналами сервера.
Мониторинг важных страниц хранит сведения о последнем обходе, ответе сервера и статусе страницы в поиске. Это не мгновенная приёмка, а наблюдение после выпуска.
Цели и заявки
Официальная справка Метрики предлагает проверять цель через параметр _ym_debug=2, выполнить целевое действие и сверить событие в панели отладки. Для формы одного сообщения об успешной отправке мало: нужно убедиться, что достижение появилось и в отчёте. Подробный порядок есть в инструкции «Проверка цели».
Если изменение затронуло аналитику, сравните счётчик, цель, адрес страницы, источник и систему-получатель. Когда после выпуска осталась старая страница или остановился отчёт, пройдите отдельную диагностику обновления данных сайта. Для ежедневной работы используйте порядок мониторинга Яндекс Метрики.
Ошибки браузера и скорость
Консоль браузера показывает, среди прочего, ошибки загрузки ресурсов, JavaScript и запросов между доменами. Официальная справка по инструментам разработчика Chrome объясняет уровни сообщений и переход к сетевому запросу. Фиксируйте ошибку вместе с URL и временем, а не копируйте весь журнал.
Лабораторная проверка скорости помогает поймать регрессию до массового трафика, но не заменяет полевые данные. web.dev разделяет лабораторное и полевое измерение Web Vitals; после выпуска сравнивайте сопоставимые страницы, устройства и периоды.
Кто отвечает за каждый слой
Один человек не должен проверять всё молча. Маркетолог подтверждает путь клиента и измерение, разработчик — технический результат, аналитик — качество данных, владелец выпуска — решение продолжать, исправлять или откатывать.
Формат сообщения об ошибке: «4 августа, 09:24 МСК; /request; мобильный Chrome; после отправки форма показывает успех, но запись в системе-получателе не появилась; цель не зафиксирована; владелец — разработка; повторная проверка — после исправления».
Что наблюдать после короткой приёмки
Первые 30 минут подтверждают очевидные сценарии. Дальше нужен период наблюдения, потому что часть проблем появляется только на реальном трафике, отдельном устройстве, источнике или пользовательском состоянии.
- доступность и ответы критичных URL;
- объём подтверждённых заявок или заказов, а не только кликов по кнопке;
- достижения целей по устройствам, источникам и типам страниц;
- ошибки браузера и сервера на изменённых сценариях;
- изменения поискового обхода и статуса важных страниц;
- обращения поддержки с повторяющимся условием.
Не сравнивайте первые часы релиза с произвольным средним. Сопоставьте одинаковые дни недели, источники, устройства и страницы. Если трафик слишком мал, честный статус — «данных недостаточно», а не «всё работает».
Когда исправлять, а когда откатывать
Решение принимают по влиянию и обратимости. Визуальную неточность можно исправить без остановки выпуска. Потерю заявок, недоступность критичного пути, ошибочную запись данных или массовую блокировку страниц лучше считать стоп-сигналом.
| Ситуация | Решение | Следующий шаг |
|---|---|---|
| Незначительный визуальный дефект без влияния на действие | Исправить планово | Зафиксировать задачу и проверить мобильную версию |
| Ошибка локальна, причина известна, исправление быстрое | Точечное исправление | Повторить исходный и контрольный сценарии |
| Критичный путь не работает или данные теряются | Остановить выпуск | Откатить либо выключить изменение |
| Масштаб и причина неясны | Ограничить влияние | Собрать сегменты, журналы и решение владельца |
Короткий протокол для команды
- До выпуска: объём, контрольные значения, владельцы и критерии отката.
- Сразу после: изменённые URL, критичный путь, заявка, цель, поиск и ошибки.
- После приёмки: наблюдение по сегментам и подтверждённым бизнес-событиям.
- При отклонении: факт, влияние, владелец, действие и повторная проверка.
- В финале: зафиксированное решение и обновлённый набор постоянных проверок.
После решения оставить выпуск продолжите мониторинг сайта по базовой линии, контрольному сценарию и фактическим данным. Если доступность различается по пользователям, перейдите к диагностике частичной доступности. Когда сбой подтверждён и затрагивает критичный путь, используйте регламент реакции команды: зафиксируйте влияние, владельца, временную защиту и критерий восстановления.
Что проверить на сайте сразу после релиза?
Проверьте изменённые и критичные страницы, главный путь заявки или покупки, отправку данных в систему-получатель, цели Метрики, canonical и ответы сервера. Повторите сценарий на настольном и мобильном экранах.
Сколько времени наблюдать за сайтом после релиза?
Сразу выполните короткую приёмку, затем наблюдайте период, достаточный для обычного объёма трафика и целевых действий. Срок зависит от риска изменения и скорости накопления данных, поэтому универсального числа нет.
Когда релиз нужно откатывать?
Откат нужен, когда нарушен критичный сценарий, данные теряются, исправление не укладывается в согласованное окно или масштаб проблемы растёт. Критерии и ответственного фиксируют до выпуска.
Частые вопросы
Что проверить на сайте сразу после релиза?
Проверьте изменённые и критичные страницы, главный путь заявки или покупки, отправку данных в систему-получатель, цели Метрики, canonical и ответы сервера. Повторите сценарий на настольном и мобильном экранах.
Сколько времени наблюдать за сайтом после релиза?
Сразу выполните короткую приёмку, затем наблюдайте период, достаточный для обычного объёма трафика и целевых действий. Срок зависит от риска изменения и скорости накопления данных, поэтому универсального числа нет.
Когда релиз нужно откатывать?
Откат нужен, когда нарушен критичный сценарий, данные теряются, исправление не укладывается в согласованное окно или масштаб проблемы растёт. Критерии и ответственного фиксируют до выпуска.
Дальше по теме
