Признаки SEO-регрессии проявляются в разное время. Ошибочный редирект виден сразу, изменение обхода — после визитов робота, выбор канонической страницы — после повторной обработки, а падение кликов — ещё позднее. Если ждать один итоговый график, связь с релизом размывается. Поэтому после выкладки полезна временная шкала с разными источниками и сроками.
До релиза: карточка ожидаемого изменения
Запишите версию и точное время выпуска, затронутые шаблоны, новые и удаляемые URL, включённые feature flags. Рядом перечислите признаки, которые обязаны сохраниться. Для нового роутинга это матрица старого и нового адреса; для шаблона — <title>, canonical, директивы индексации и основной контент; для фронтенда — содержимое исходного и отрендеренного HTML.
Выборка должна представлять разные реализации. Главная, категория, карточка, статья, страница с параметрами и языковая версия часто формируются разными правилами. Десять карточек одного шаблона дают меньше информации, чем по одному адресу каждого технического типа.
Карточка может состоять из четырёх строк:
| Сегмент | Ожидаемое изменение | Что сохраняется | Первый тест |
|---|---|---|---|
| Старые карточки | 301 на новый путь | Соответствие товара | Цепочка редиректа |
| Новые карточки | Новый дизайн | canonical на себя | Исходный HTML |
| Категории | Без изменений | 200, H1, ссылки | Сравнение эталона |
| Sitemap | Новые адреса | Только канонические URL | XML и выборка строк |
Этот документ задаёт область проверки. Общий всплеск 404 от сканирования случайных адресов не относится к релизу, если изменённый сегмент отвечает штатно.
Первые 15 минут: HTTP и маршруты
Сразу после переключения проверьте статусы затронутых и контрольных URL, конечные адреса, цепочки переходов, время ответа, robots.txt и sitemap. Ошибки 5xx, циклы, массовый редирект на главную и закрытие всего сайта дают ранний технический сигнал.
Пройдите переходы до конца. Старый URL может вернуть ожидаемый 301, а новый — 404 или вести на другой домен. Отдельно проверьте HTTP, www, домен без www и локали, если релиз затрагивал их правила. Методика проверки приведена в статье об анализе редиректов.
Зафиксируйте результат запросом и приложите браузерный экран как дополнительный артефакт. Нужны исходный URL, каждый статус, Location, конечный адрес и время. Сигнал привязывают к версии, когда он начинается после выпуска, воспроизводится и относится к изменённому пути.
При серьёзной ошибке сохраните ответы перед откатом. После восстановления повторите тот же набор: это покажет, что изменился именно наблюдаемый признак.
Первые часы: серверный HTML и DOM
Код 200 не подтверждает пригодность страницы для поиска. В исходном ответе могут исчезнуть основной текст, ссылки или <title>, появиться meta robots со значением noindex, а rel="canonical" — указывать на другой раздел. Проверьте также X-Robots-Tag в HTTP-заголовках: его не видно среди тегов страницы.
Сравните исходный HTML и DOM после выполнения JavaScript. Если ключевой контент загружается клиентским запросом, ошибка API или гидратации оставит пустой каркас. Различия серверного и клиентского рендеринга рассмотрены в статье SSR и CSR для SEO.
На уровне шаблона изучайте распределение значений по нескольким страницам. Полезные сигналы: доля пустых <title>, одно массовое значение description, canonical на чужой хост, исчезновение H1 и резкое уменьшение исходного HTML. Проверка нескольких представителей подтверждает, что дефект системный.
Разделяйте автоматический факт и смысловую оценку. Скрипт точно покажет смену canonical; решение о корректности зависит от плана миграции и других сигналов.
Первые сутки: запросы подтверждённых роботов
Серверные access-логи появляются раньше отчётов поисковых кабинетов. Сравните, посещают ли роботы затронутые разделы, какие статусы получают и не сместился ли обход на фильтры, параметры или бесконечные календарные страницы.
Строка User-Agent: Googlebot или YandexBot не доказывает личность робота: этот заголовок копируется любым клиентом. Для Google используйте обратное DNS-разрешение с последующей прямой проверкой либо официальные диапазоны IP согласно инструкции Google. Yandex также описывает обратную и прямую DNS-проверку в справке для вебмастеров.
После верификации группируйте запросы по шаблону, статусу и периоду. Резкое исчезновение обхода само по себе не доказывает проблему: частота меняется естественно. Диагностическая цепочка сильнее: после релиза подтверждённый робот получает запрет или серию 5xx на изменённых URL, затем успешные визиты прекращаются.
В sitemap проверьте синтаксис, абсолютные URL, протокол, домен и отсутствие заведомо неиндексируемых страниц. Сопоставьте дату изменения файла с релизом.
Первые дни: индексирование и canonical
В Search Console и Яндекс Вебмастере с задержкой появятся ошибки сервера, запреты, дубли и альтернативные канонические страницы. Сначала смотрите сегмент изменённого шаблона, затем выборочно инспектируйте конкретные URL. Общий счётчик по домену может скрыть небольшую, но коммерчески важную категорию.
Canonical служит подсказкой поисковой системе. Указанный в HTML адрес и выбранный поисковиком могут расходиться, если редиректы, внутренние ссылки и sitemap ведут на разные версии. Сценарии таких конфликтов собраны в руководстве по canonical.
Зафиксируйте четыре источника для одного примера: canonical в серверном HTML, конечный URL после редиректа, адрес в sitemap и результат инспекции. Оператор site: не подходит в качестве точного счётчика индекса; он годится только для грубого поиска примеров.
Назначайте срок проверки с учётом задержки кабинета. При отсутствии свежих данных поставьте статус «источник ещё не обновился»; проверка останется незавершённой до следующего окна.
Через несколько дней: показы, CTR и производительность
Показы часто реагируют раньше кликов. Сравнивайте одинаковые дни недели и завершённые периоды, разделяя данные по шаблонам, запросам, странам и устройствам. Просадка одного каталога при стабильном блоге направляет к шаблону или спросу этого каталога. Общий процент по домену такого различия не покажет.
Стабильная позиция при снижении CTR может быть связана со сниппетом, изменённым <title> или составом выдачи. Одновременное падение показов и рост ошибок обхода возвращает расследование к техническому слою. Это рабочая гипотеза, пока не сопоставлены URL и временные интервалы.
Производительность рассматривайте рядом, но отдельно. Новый скрипт может одновременно увеличить время загрузки и сломать рендеринг, однако один нестабильный лабораторный запуск причинность не подтверждает. Сравните одинаковые страницы и условия, затем дождитесь достаточного окна полевых данных. Методика есть в руководстве по Core Web Vitals.
Таблица решения: откат, исправление или наблюдение
Для каждой находки заполните четыре поля: факт, затронутый сегмент, связь с релизом и следующее действие.
| Факт | Связь | Решение |
|---|---|---|
На всех новых карточках появился noindex | Воспроизводится только в новой версии | Сохранить доказательство и откатить или срочно исправить |
| Один лабораторный запуск стал медленнее | Пока слабая | Повторить в тех же условиях |
| Старые URL ведут цепочкой на 404 | Началось после нового роутинга | Исправить карту переходов |
| Сегодня меньше показов, отчёт неполный | Данных мало | Дождаться завершённого периода |
У наблюдения должны быть дата повторной оценки и критерий эскалации. Для отката заранее проверьте совместимость миграций и данных. После любого действия повторите тот тест, который обнаружил отклонение.
Распределите источники по времени
SEO-монитор может сохранить изменение HTTP-статуса и нескольких полей исходного HTML на контрольном URL. meta robots, X-Robots-Tag, отрендеренный DOM, логи роботов и поисковые кабинеты он не охватывает. Поэтому назначьте этим источникам отдельные строки и сроки вместо одного общего статуса «SEO проверено».
Скопируйте таблицу решения в релизную задачу и назначьте время для каждого источника: 15 минут, несколько часов, сутки и несколько дней. При срабатывании добавляйте URL и сохранённый ответ. Так у команды остаётся проверяемая последовательность от версии до первого изменившегося слоя.