Шаблон SEO-контроля перед релизом сайта

Лист SEO-контроля релиза (для заполнения)

Когда использовать: Один лист на релиз: выборка критичных URL со статусом, robots, canonical и аналитикой, плюс ответственный за откат и подпись.

Лист SEO-контроля релиза

Заполняйте один лист на каждый релиз. Проверьте одну и ту же выборку на staging до деплоя и на production сразу после него.

• Релиз: [версия или номер задачи] · Окно деплоя: [дата, время, часовой пояс]
• Что изменилось: [шаблоны, маршруты, конфигурация, CMS, CDN, robots.txt]
• Хост production: [https://www.example.com] · Хост staging: [URL staging]

Выборка критичных URL

Возьмите по одному URL на каждый шаблон, который затронул релиз. Добавьте самые важные страницы и файлы, которые может сломать любой релиз.

Ответственный за откат и подпись

• Ответственный за откат: [имя, телефон или ник в мессенджере] · Может откатить без согласования: [да / нет]
• SEO-проверка: [имя] · Проверка от разработчиков: [имя]
• Условие отката: [любой критичный URL не прошёл проверку статуса, robots или canonical]
• Итог контроля: [выпускаем / выпускаем с задачей на доработку / не выпускаем] · Подпись: [имя, время]

Лист готов, когда: каждая строка заполнена и для staging, и для production, ни одна ошибка не осталась без задачи, ответственный за откат назначен, а лист сохранён вместе с заметками к релизу.

Чек-лист SEO перехода со staging в production

Когда использовать: Первый запуск со staging: снять блокировки доступа, задать основной хост для canonical, проверить редиректы, sitemap и аналитику, подписать запуск.

До переключения DNS или выкатки сборки

Обычно staging закрыт тремя способами. Каждый из них нужно снять на production, и только на production.

1. HTTP-авторизация или вход по логину: отключены на production. На staging оставьте.
2. robots.txt: на production лежит не файл со staging с Disallow: /. Если нужно начать с чистого листа, соберите новый файл в генераторе robots.txt.
3. noindex: в HTML нет <meta name="robots" content="noindex">, а сервер, CDN или настройки платформы не отдают заголовок X-Robots-Tag: noindex.

Основной хост для canonical

• Основным выбран один хост: [https://www.example.com]. Остальные версии (http, без www) ведут на него 301-редиректом за один шаг.
• Теги canonical содержат абсолютные URL и указывают на хост production, никогда на staging.
• Внутренние ссылки, hreflang и URL в Open Graph используют хост production. Поищите в HTML [имя хоста staging].

Редиректы

• Любой URL, который существовал до запуска, отдаёт 200 или один 301 на новый адрес.
• Проверьте несколько адресов в Redirect Checker: один шаг, итоговый статус 200, без зацикливания.
• Меняете много URL? Тогда вместо этой страницы используйте полный чек-лист миграции и карту редиректов.

Sitemap и Search Console

• В sitemap только URL production, которые отдают 200 и открыты для индексации.
• Sitemap указан в robots.txt и отправлен в Search Console для ресурса production.

Аналитика

• На production работает боевой ID аналитики, а не ID от staging или тестовый.
• Ключевые события срабатывают ровно один раз: [отправка формы, покупка, регистрация].
• Баннер согласия на cookie работает так же, как на staging.

Подпись запуска

• Запуск одобрил: [имя] · Время: [время]
• Staging после запуска по-прежнему закрыт: [да, проверено в браузере без входа в аккаунт]

Проверки перед релизом

Когда использовать: Что проверить на staging или preview-сборке до деплоя, чтобы настройки production были правильными с первого дня.

Проверьте это на staging до деплоя

Staging закрыт, поэтому проверяйте его с авторизацией. Вы убеждаетесь, что настройки production будут правильными, а не что staging открыт для индексации.

• Сверьте SEO-настройки: robots.txt, значения meta robots по умолчанию, базовый URL для canonical и ID аналитики берутся из переменных окружения, а не зашиты в код.
• Проверка шаблонов: каждый изменённый шаблон по-прежнему выводит один title, один meta description, один canonical и H1.
• Исходный HTML: посмотрите HTML от сервера и заголовки до выполнения JavaScript. Source Code Viewer показывает исходный код, мета-теги и HTTP-заголовки любого публичного URL.
• Рендеринг: важный контент и ссылки есть на странице после рендеринга, а не появляются только после клика.
• Маршруты: для переименованных или удалённых маршрутов редиректы выходят в том же релизе.
• Коды ответа: несуществующие страницы отдают 404, а не 200 с текстом ошибки.

Правило контроля

Если на критичном шаблоне не прошла хотя бы одна предрелизная проверка, релиз ждёт или выходит без изменений в этом шаблоне.

Смоук-тест после релиза

Когда использовать: Проверка по времени: первые 15 минут, первый час и первая неделя после деплоя.

Первые 15 минут

Прогоните всю выборку критичных URL на production. Используйте браузер без входа в аккаунт и запрос со стороны сервера: кэш и авторизация скрывают проблемы.

• Каждая строка выборки совпадает с ожидаемым статусом, robots и canonical.
• /robots.txt отдаёт 200. Ошибка 5xx на этом файле может заставить Google приостановить сканирование сайта.
• В заголовках ответа нет случайного X-Robots-Tag.
• Аналитика показывает посетителей в реальном времени на боевом ID.

Первый час

• Проверьте 2-3 ключевых URL в Search Console: инструмент «Проверка URL» (URL Inspection), кнопка «Проверить страницу на сайте» (Test live URL). Посмотрите, разрешены ли сканирование и индексирование.
• Убедитесь, что очистка кэша CDN завершилась и сервер больше не отдаёт старый HTML.

Первый день и первая неделя

• Запустите бесплатный аудит сайта, чтобы проверить коды ответа, редиректы, robots.txt, noindex и canonical на выборке страниц.
• Следите по серверным логам или «Статистике сканирования» (Crawl Stats), не выросло ли число ответов 404 или 5xx.
• В ближайшие дни проверяйте отчёт «Индексирование страниц» (Page indexing) в Search Console: не появились ли новые причины исключения, например "URL marked 'noindex'" (страница исключена тегом noindex).
• Сравнивайте органические клики с тем же днём недели на прошлой неделе, а не со вчерашним днём.

Правила отката

Когда использовать: Заранее согласованные условия: когда откатывать, когда выпускать хотфикс, когда ставить задачу, и кто принимает решение.

Договоритесь об этом до деплоя, а не во время него

Почему важна скорость

• По словам Google, страницы с noindex выпадают из индекса при повторном сканировании.
• Google обычно кэширует robots.txt до 24 часов, поэтому ошибочный файл может влиять на сканирование даже после исправления.
• URL, которые продолжают отдавать ошибки сервера, со временем удаляются из индекса.

После любого отката: снова прогоните выборку критичных URL, запишите в заметках к релизу, что сломалось, и добавьте проверку, чтобы такая ошибка больше не прошла контроль.

Контроль по типу релиза

Когда использовать: Объём проверки под масштаб изменений: от правки текста в CMS до обновления фреймворка или первого запуска.

Подберите проверку под релиз

Не каждому деплою нужен полный лист. Объём проверки зависит от типа изменений.

Где обычно прячутся SEO-настройки

• Переменные окружения с базовым URL и значениями robots по умолчанию.
• Переключатель в CMS вроде «Попросить поисковые системы не индексировать сайт» или «Скрыть из поиска».
• Правила CDN или edge-серверов, которые добавляют заголовки.
• Фича-флаги, из-за которых части пользователей показывается другой шаблон.

Заполненный пример (вымышленный сервис для бухгалтерии)

Когда использовать: Заполненный лист для выдуманного релиза SaaS, где правило заголовков со staging чуть не выкатило noindex на страницу тарифов.

Заполненный пример: редизайн тарифов Tallyfin

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

Tallyfin, вымышленная компания с сервисом для бухгалтерии, во вторник выпустила новый шаблон страницы тарифов и сравнения планов. Релиз 4.12, деплой в 10:00.

• Что поймал контроль: у нового маршрута тарифов оказалось правило заголовков, скопированное из edge-конфигурации staging. HTML выглядел нормально. noindex был виден только в заголовках ответа.
• Решение: «не выпускаем» в 09:40. После исправления правило осталось только на staging. Повторная проверка прошла в 10:25, деплой в 10:30.
• Ответственный за откат: Mara (команда платформы), с правом откатить релиз без согласования.
• После релиза: проверка страницы на сайте в «Проверке URL» (URL Inspection) для /pricing показал, что индексирование разрешено. Аудит на второй день не нашёл новых страниц с noindex.

Почему это сработало

В листе проверялись заголовки, а не только HTML, и в выборку попал тот самый шаблон, который менял релиз. Ответственного за откат назначили до 10:00, поэтому решение «не выпускаем» заняло минуты.

Следующий шаг

Вставьте критичные URL в Source Code Viewer, чтобы увидеть исходный HTML и заголовки, и проверьте старые URL в Redirect Checker. На следующий день после релиза запустите бесплатный аудит сайта.