Предрелизная SEO-проверка нужна не для того, чтобы повторить большой аудит перед каждым коммитом. Её задача — доказать, что обновление не нарушило поисковые контракты затронутых типов страниц. Чем точнее известна область изменения, тем меньше проверок требуется и тем выше шанс заметить реальную регрессию.
Начните с карты изменения
Запишите, какие слои затронуты: маршруты, серверные ответы, общий layout, метаданные, навигация, CMS-поля, локализация, sitemap, robots.txt, структурированные данные, CDN. Фраза «поменяли карточку» недостаточна, если карточка использует общий компонент head со всеми страницами сайта.
Свяжите каждый изменённый слой с возможным последствием. Новый роутер может создать редирект или 404; фильтрация данных — пустую страницу с 200; перенос метаданных — общий title; изменение меню — страницы-сироты; переключение окружения — случайный noindex; новый домен ресурсов — проблемы рендеринга.
Из карты получается проверяемая гипотеза риска. Она определяет выборку и критерии. Для большого релиза полезно назначить владельца каждого блока, чтобы SEO-приёмка не оставалась общей ответственностью без исполнителя.
Соберите репрезентативную выборку
Выберите по несколько URL каждого затронутого шаблона. Нужны обычное и пограничное состояние: заполненная карточка и товар без изображения, категория с результатами и пустая, первая и следующая пагинация, русская и локализованная версии, существующая и отсутствующая сущность.
Добавьте контрольные страницы из незатронутых разделов, особенно если изменялся глобальный layout, middleware или конфигурация сервера. Они показывают побочный эффект. Не выбирайте только главную: она часто имеет отдельную реализацию и не представляет внутренние маршруты.
Для каждого URL задайте ожидаемый код, конечный адрес, индексируемость, canonical, title, H1, основной текст и важные ссылки. Такая таблица превращает «посмотреть сайт» в приёмочный сценарий.
Проверьте окружение стенда
Предпродакшен следует закрывать авторизацией, VPN или сетевым правилом. Эти меры действительно ограничивают доступ и меняют возможности внешних инструментов; не снимайте их ради сканера без согласования. robots.txt управляет обходом, но не защищает стенд от посетителей и не скрывает сам адрес. Проверяйте страницу из разрешённого контура и отдельно убедитесь, что тестовые директивы не могут попасть в production вместе с конфигурацией.
Особенно опасны noindex, X-Robots-Tag, тестовый canonical, абсолютные ссылки на staging-домен и robots.txt с полным запретом. Сверьте переменные окружения с собранным артефактом и фактическим ответом: значение могло быть закэшировано на этапе сборки. Если публичный стенд использует noindex, не закрывайте ту же страницу через Disallow: робот должен загрузить ответ, чтобы прочитать директиву.
Если стенд использует сокращённые данные, отметьте непроверенные состояния. Успешная карточка одного товара не подтверждает шаблон удалённого объекта или локализацию. Ограничение тестовой среды должно быть видимым риском релиза.
Пройдите технический контракт страницы
Получите ответ без пользовательской сессии и проверьте код, Content-Type и редиректы. В исходном HTML найдите title, H1, meta robots, canonical, hreflang, основной текст и ссылки. Ожидаемую уникальность title и H1 задавайте для конкретного семейства страниц, не превращая любое повторение в блокер. Для JavaScript-сайта сравните DOM после рендеринга и проверьте сетевые ошибки.
Canonical должен вести на ожидаемую основную версию. Целями не могут служить стенд, главная или другой язык. Индексируемые URL перечисляются в sitemap; редиректы, 404, noindex и дубли из карты исключаются. Внутренние ссылки ведут сразу на конечные адреса.
Полный список технических областей можно сверить с чек-листом технического SEO, но в релизный gate включайте только объективно проверяемые условия. Нечёткое требование «SEO хорошее» невозможно автоматизировать или принять.
Выполните обход и сравнение
Запустите краулер по стенду в разрешённой области. Сравните распределение кодов, число индексируемых страниц, уникальность title/H1, canonical, глубину, внутренние ссылки и обнаруженные URL с контрольным production-обходом. Сравнивать абсолютные числа нужно с учётом новых и удалённых страниц.
Полезен структурный diff: какие URL появились, исчезли, сменили код, canonical или robots. Он быстрее обнаружит, что новая версия перестала ссылаться на раздел, чем ручной просмотр десятков экранов. Для крупных изменений задайте допустимые различия заранее.
Если находка массовая, сгруппируйте её по шаблону. Общий порядок приоритизации и исправления описан в статье о работе с SEO-ошибками; исправление одной контрольной страницы не подтверждает всю ветвь данных.
Отдельно проверьте навигацию и удаление URL
Новая страница должна иметь место в структуре: категория, меню, хлебные крошки или тематическая ссылка. Краулер должен обнаружить её из известных точек. Sitemap не заменяет внутренний путь. При пакетной публикации сравните экспорт CMS с обходом, чтобы не выпустить сироты.
Для удалённых и переименованных страниц подготовьте карту переходов. Точная замена получает постоянный прямой редирект. URL без преемника возвращает корректный статус отсутствия. Не отправляйте все старые страницы на главную. Обновите внутренние ссылки, canonical и sitemap одновременно.
Проверка правил и цепочек раскрыта в материале о редиректах. В предрелизной среде важно проверить не только конфигурационный файл, но и реальный ответ маршрутизатора.
Структурированные данные проверяйте только на тех шаблонах, где они заявлены. Сопоставьте JSON-LD с видимым содержанием: название, цена, наличие, автор, даты и хлебные крошки берутся из той же сущности, которую видит посетитель. Валидный синтаксис не спасает разметку товара, случайно оставшуюся на странице категории. После изменения компонента сравните типы и ключевые поля с production, затем прогоните контрольные URL через валидатор. Предупреждение валидатора не всегда блокирует релиз, но исчезновение обязательного поля или разметка другой сущности требуют исправления до публикации.
Установите критерии стоп-релиза
Остановить публикацию должны подтверждённые дефекты, которые делают важный шаблон недоступным или неиндексируемым, массово меняют canonical на неверную цель, создают петли редиректов, убирают основной контент, переносят staging-адреса либо разрывают критическую навигацию. Принимайте решение по области воздействия и доказательствам; общий счётчик аудита для этого слишком груб.
Некритичное различие можно выпустить с зарегистрированной задачей, владельцем и сроком. Например, единичный неоптимальный description обычно не равен запрету релиза, если изменение нужно срочно и остальной контракт сохранён. Но «исправим потом» без записи превращает известный долг в забытый.
У каждого блокирующего пункта должны быть URL, ожидаемое и фактическое состояние, способ воспроизведения. Это ускоряет исправление и повторную приёмку.
Подготовьте послерелизную проверку заранее
До публикации составьте список production-запросов: те же контрольные URL, конечные коды, метаданные, ключевые ссылки, sitemap и robots.txt. Укажите, какие кэши и фоновые генераторы могут задержать обновление. Назначьте окно наблюдения и ответственного за решение об откате.
Если сайт подключён к центру контроля reChecker, история полных аудитов сохраняет состояние production до релиза и результаты последующих проверок. Для релизного протокола отдельно запишите конкретные URL и ожидаемые значения: панель показывает историю аудитов и изменений, но не хранит ваш приёмочный сценарий.
Согласуйте также длительность проверки после выкладки. Быстрый запрос подтверждает синхронную часть, но sitemap, очистка кэша, статическая генерация и импорт могут завершаться фоновыми заданиями. Для каждого процесса нужен наблюдаемый признак окончания и допустимое время. Иначе команда примет релиз раньше, чем обновятся все публичные представления сайта.
Перед разрешением публикации в протоколе должны быть заполнены четыре поля: покрытая область изменений, результат блокирующих проверок, ограничения стенда и список production-запросов. Ответственный за выпуск подписывает этот набор и время наблюдения. Поведение живого сайта подтверждается уже после выкладки по подготовленному списку.