Мониторинг и регресс: чтобы починенное не разъехалось обратно

Highlights

Техничка не бывает «сделанной». Она бывает в текущем состоянии, и состояние ухудшается само: каждый релиз, каждый новый плагин и каждая правка шаблона способны сломать то, что вы чинили полгода назад.
Самая частая техническая катастрофа, которую я видел, — строчка Disallow: /, приехавшая со стейджинга. Она же самая быстро исправимая, если заметить её в день выката, а не через месяц.
Мониторинг — это четыре разные периодичности, а не одна. После каждого релиза, раз в неделю, раз в месяц, раз в квартал. Смешивать их в один ритуал бессмысленно.
Ценность обхода краулером не в самом обходе, а в сравнении с предыдущим. Один отчёт показывает состояние, два подряд показывают направление.
Search Console отстаёт от реальности на несколько дней. Это инструмент наблюдения за трендом, а не сигнализация: о том, что сайт лежит прямо сейчас, вам должен сообщить внешний мониторинг.
Полевые данные по скорости обновляются по 28-дневному окну. Улучшили что-то сегодня — увидите это в отчёте не раньше чем через несколько недель, и это не повод откатывать правку.
Прежде чем искать причину падения в алгоритмах Google, проверьте, не сломали ли вы что-нибудь сами. В моей практике это соотношение примерно девять к одному в пользу собственных релизов.
История в отчётах конечна, поэтому важные срезы стоит выгружать и хранить у себя. В момент, когда понадобится сравнить с «как было год назад», данных может уже не быть.

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

Технический долг возвращается сам. Единственное, что этому противостоит, — регулярная проверка с понятным ритмом.

Четыре ритма наблюдения

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

Проверка после каждого релиза

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

robots.txt. Откройте его и посмотрите глазами. Файл со стейджинга, где закрыто всё, — классика жанра, и обнаруживается она обычно через недели, когда страницы уже вылетели.

Мета-теги роботов на главных шаблонах. Тот же риск, но на уровне шаблона: noindex, приехавший с тестового окружения на прод.

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

Наличие текста в исходном коде. Откройте view-source на карточке и найдите основной текст. Если после релиза контент стал дорисовываться скриптами, вы узнаете об этом сейчас, а не через месяц по просевшему трафику. Подробности — в статье про JavaScript SEO.

Что смотреть в Search Console

Индексирование страниц. Главный отчёт. Смотреть надо не на абсолютные числа, а на динамику категорий: резкий рост «Страница является копией», «Обнаружена, но не проиндексирована» или «Заблокировано в robots.txt» — это всегда след чего-то, что произошло на сайте.

Эффективность. Клики и показы. Полезно не столько итоговым графиком, сколько в разрезе страниц и запросов: падение по сайту в целом может быть сезонностью, а падение конкретного раздела почти всегда означает конкретную поломку.

Статистика сканирования (в настройках ресурса). Показывает, сколько запросов делает робот, среднее время ответа и распределение по кодам. Всплеск ошибок или рост времени ответа здесь виден раньше, чем последствия в индексе. Как это связано с обходом — в статье про краулинговый бюджет.

Core Web Vitals. Отдельно мобильные и десктопные группы URL. Держите в голове 28-дневное окно полевых данных: улучшения проявляются постепенно и с задержкой.

Письма. Search Console сама пишет о критичном — ручных санкциях, всплесках ошибок, проблемах с безопасностью. Проверьте, что адрес актуален и письма не падают в спам, потому что это единственный канал, где Google обращается к вам первым.

Важная оговорка про весь инструмент целиком: данные приходят с задержкой в несколько дней. Search Console отвечает на вопрос «что происходило», а не «что происходит прямо сейчас».

Обход краулером и сравнение

Один обход показывает состояние. Смысл появляется, когда обходов два и вы сравниваете.

Что сравниваю от раза к разу: общее число найденных URL (внезапный рост — обычно новые дубли, падение — оборванная перелинковка), распределение кодов ответа, канонические адреса, тайтлы и описания (массовое изменение — след правки шаблона), глубину вложенности, число страниц-сирот.

Screaming Frog и Netpeak Spider оба умеют сравнивать обходы. Приём, который советую: сохраняйте выгрузки с датой в имени файла и держите их хотя бы год. Когда через полгода понадобится ответить на вопрос «когда у нас появились эти двадцать тысяч страниц», ответ найдётся за минуту.

Ещё полезно обходить сайт мобильным user-agent — после перехода на mobile-first это ближе к тому, что видит Google.

Внешний мониторинг доступности

Отдельный слой, который не заменяется ничем из перечисленного. Задача простая: узнать, что сайт лёг, от системы, а не от клиента в мессенджере.

Минимум — проверка главной раз в несколько минут с уведомлением при недоступности. Лучше — несколько ключевых страниц, включая тяжёлую (категория с фильтрами) и функциональную (форма заявки), плюс контроль срока действия сертификата. Истёкший сертификат кладёт трафик мгновенно и полностью, а предупреждение о нём приходит заранее и обычно теряется в почте.

Затяжные 5xx — самое дорогое, что бывает: сначала Google снижает частоту обхода, потом начинает выбрасывать страницы. Про реакцию поисковика на коды ответа — в отдельной статье.

Как отличить свою поломку от апдейта Google

Трафик упал — первая мысль обычно «наверное, апдейт». Это удобная мысль, потому что снимает ответственность. По моему опыту в девяти случаях из десяти дело в чём-то, что сделали на сайте.

Порядок разбора я держу такой:

Дата. Совпадает ли падение с датой релиза? Посмотрите историю выкатов раньше, чем историю апдейтов Google.
Форма падения. Обвал в один день — почти наверняка техническая поломка или санкция. Плавное сползание за неделю-две — больше похоже на алгоритмическое.
Охват. Просел весь сайт или конкретный раздел, шаблон, тип страниц? Локальное падение указывает на конкретное изменение.
Показы или позиции. Если рухнули показы, а не CTR, — страницы перестали показывать. Проверяйте индексацию, а не тексты.
Индекс. Сколько страниц в индексе было и стало. Выпадение — техническая история.
И только потом смотрите, был ли в эти даты подтверждённый апдейт.

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

Что автоматизировать

Ручное наблюдение проигрывает не потому, что хуже, а потому, что его перестают делать. Поэтому всё, что можно снять с человека, лучше снять.

Реалистичный минимум: внешний мониторинг доступности с уведомлениями, оповещение об изменении robots.txt, регулярный обход по расписанию с сохранением выгрузки, письма Search Console на живой адрес, который читают. Этого хватает, чтобы про крупные аварии узнавать в тот же день.

Что автоматизировать сложнее и обычно не стоит: смысловые проверки вроде «а не стал ли текст на карточках мусорным» и «удобно ли пройти путь до заявки». Их надёжнее делать руками раз в квартал.

Чек-лист

Глубже по теме

Обзор слоя: техническая оптимизация.
Сканирование и индексация — что означают категории отчёта об индексировании.
Дубли и канонизация — куда смотреть при внезапном росте числа страниц.
Краулинговый бюджет и анализ логов — как читать поведение робота по логам.
Коды состояния HTTP — чем опасны затяжные ошибки сервера.
Сервер, TTFB и кеширование — если растёт время ответа.
Мобильная версия и mobile-first — почему обходить стоит мобильным агентом.
Netpeak Spider vs Screaming Frog — чем обходить сайт.
Назад к карте цикла: продвижение сайта.