Чек-лист перед публикацией страницы: как проверить индексируемость, canonical и sitemap

Перед публикацией страницы нужно проверить не только текст и оформление. Поисковый робот должен иметь возможность получить URL, понять, что страницу можно показывать в поиске, и связать её с правильной канонической версией. Если эти сигналы противоречат друг другу, отправка URL на переобход не исправит причину.

Ниже — практический чек-лист для редактора и технического специалиста. Он подходит для новой статьи, обновлённого материала и страницы, которая переезжает на новый URL. Проверки выполняются на опубликованном адресе или на staging-копии с теми же шаблонами и заголовками ответа.

Кратко

Перед публикацией проверьте:

1. URL отвечает без ошибки, а итоговый адрес соответствует выбранной версии страницы.
2. В HTML нет noindex, а для PDF и других файлов проверен X-Robots-Tag.
3. rel="canonical", внутренние ссылки и sitemap указывают на один и тот же URL.
4. robots.txt не блокирует обход страницы или нужных ресурсов.
5. У страницы есть понятное назначение, самостоятельный ответ на запрос и входящие ссылки из близких материалов.
6. После публикации сохранены исходный URL, дата проверки и результат каждой команды.

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

Что проверить до публикации

Не превращайте таблицу в автоматическую галочку. Например, наличие URL в sitemap помогает сообщить о странице, но не заменяет доступность, полезность и согласованные canonical-сигналы. То же самое с кодом 200: успешный ответ не означает, что страница будет выбрана для показа.

1. Доступность, статус и редиректы

Сначала зафиксируйте URL, который должен быть каноническим:

PAGE_URL='https://indexatori.ru/posts/url-prepublish-indexing-checklist/'
ORIGIN='https://indexatori.ru'
curl -I "$PAGE_URL"
curl -IL "$PAGE_URL"

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

Если ответ нестабилен, сначала исправьте сервер. Пока URL то отдаёт 200, то 5xx, проверка индексации будет смешивать техническую проблему с оценкой контента.

2. noindex, X-Robots-Tag и robots.txt

Откройте исходный HTML, а не только отрендеренный экран, и найдите noindex, nofollow и canonical. Для HTML запрет обычно задаётся мета-тегом:

<meta name="robots" content="noindex">

Для PDF, изображений и других не-HTML ресурсов нужно дополнительно проверять заголовок ответа:

curl -sI "$FILE_URL" | findstr /I "X-Robots-Tag"

robots.txt решает другую задачу: он управляет возможностью обхода, а не является надёжным способом удалить URL из индекса. Если важный URL закрыт в robots.txt, робот может не прочитать его содержимое и не увидеть мета-правило. Поэтому проверьте и доступ к обходу, и отдельные правила индексации.

Ищите правило, которое закрывает не только точный файл, но и родительский каталог. Частая ошибка — оставить в боевом файле временное Disallow для раздела, созданное на staging.

3. Canonical и дубли

Canonical — это сигнал предпочтительного URL, а не приказ поисковой системе. На странице должна быть одна понятная версия rel="canonical", а внутренние ссылки и sitemap должны поддерживать тот же выбор. Не указывайте в canonical URL с фрагментом, случайными параметрами аналитики или адрес другой статьи.

Проверьте четыре варианта:

• URL с http и https;
• версии с www и без www, если домен их различает;
• адрес со слешем и без слеша;
• параметры сортировки, фильтров и рекламной разметки.

Если две страницы отвечают на один и тот же узкий запрос, одной строки canonical может быть недостаточно. Сравните их назначение, заголовок, вступление, примеры и внутренние ссылки. Когда материалы действительно конкурируют, объедините их или разведите по разным задачам пользователя. Методика диагностики есть в разборе похожих страниц и риска каннибализации и в статье про проверку canonical URL .

Для проверки выбранного Google URL используйте URL Inspection в Search Console. Там важно сравнить пользовательский canonical с canonical, который выбрала Google, а не только увидеть, что тег присутствует в исходнике.

4. Sitemap и внутренние ссылки

В sitemap добавляйте абсолютный URL, который вы действительно хотите показывать. Не включайте туда варианты с параметрами, редиректами, noindex и ошибочными canonical. После обновления карты проверьте XML напрямую и убедитесь, что сервер отдаёт файл без авторизации и ошибки.

Sitemap помогает обнаружить новые и обновлённые адреса, но не гарантирует обход или индексацию. Поэтому новая статья должна быть доступна ещё и через обычную навигацию сайта. Добавьте две-три уместные ссылки из материалов, которые уже объясняют соседние вопросы. Ссылка должна отвечать ожиданию читателя, а не быть формальным блоком «похожие статьи».

Для этой страницы логично связать технический чек-лист с диагностикой статусов Search Console , разбором Discovered - currently not indexed и проверкой sitemap.xml . После публикации проверьте, что новые ссылки видны в HTML, а не появляются только после действия пользователя в JavaScript.

5. Содержательная готовность

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

1. Какую конкретную задачу читатель решает этой страницей?
2. Есть ли здесь инструкция, пример или критерий выбора, которого нет в соседних материалах?
3. Понимает ли читатель, что делать после прочтения?

Не добавляйте объём ради объёма. Уберите повторение определения, рекламные обещания без условий и точные проценты без источника. Если число важно, укажите источник и дату; если универсального числа нет, опишите зависимость словами. Формулировка «проверьте статус и исправьте причину» полезнее, чем обещание, что один запрос на переобход даст результат за несколько часов.

Отдельно проверьте дату и область применимости. Инструкции Search Console, лимиты API и возможности валидаторов меняются. Обычные статьи нельзя отправлять через Google Indexing API: официальная документация ограничивает его страницы с JobPosting или BroadcastEvent внутри VideoObject. Для обычной статьи используйте sitemap, внутренние ссылки и URL Inspection как диагностический инструмент, а не как гарантию.

Три сценария после публикации

Страница обнаружена, но не проиндексирована

Сначала сравните дату публикации, доступность, canonical и качество ответа. Затем проверьте, есть ли у страницы внутренние ссылки и не является ли она почти полной копией другого материала. Не отправляйте URL повторно вслепую: исправьте обнаруженную причину, сохраните изменения и только после этого запросите повторную проверку.

Подробная последовательность есть в разборе статуса Discovered - currently not indexed . Если Google уже сканировала страницу, полезнее смотреть на выбранный canonical и содержательные отличия, чем бесконечно повторять отправку.

Выбрана другая каноническая страница

Откройте URL, который показан в Search Console, и сравните его с пользовательским canonical. Если это старый дубль на вашем сайте, объедините материалы или исправьте сигналы. Если Google считает страницы слишком похожими, одной перестановки слов недостаточно: разделите поисковые намерения и добавьте самостоятельные примеры.

После исправления статус не изменился

Переоценка не происходит мгновенно. Зафиксируйте, что именно изменилось, и проверьте live-HTML повторно. Если причина связана с сервером, canonical или блокировкой, сначала дождитесь стабильного результата технической проверки. Если проблема в содержании, оцените страницу заново по задаче читателя и сравнению с соседними URL. Матрица диагностики индексации помогает не смешивать эти причины.

Минимальный протокол проверки

Сохраните в задаче или в release-заметке:

• канонический URL и дату проверки;
• результат curl -IL;
• найденные noindex, X-Robots-Tag и canonical;
• факт появления URL в sitemap;
• две-три входящие внутренние ссылки;
• скриншоты desktop и mobile;
• что изменилось после проверки и кто подтвердил публикацию.

Такой журнал полезнее обещаний «страница попадёт в индекс с первого раза»: он позволяет быстро отделить серверную ошибку от конфликтующих сигналов и от проблемы качества материала.

Вывод

Публикационная проверка должна отвечать на три разных вопроса: может ли робот получить страницу, разрешено ли её индексировать и какой URL следует считать основной версией. 200 OK, sitemap и canonical по отдельности не дают гарантии; важна согласованная цепочка сигналов плюс самостоятельная польза текста.

Если страница уже опубликована, начните с live-HTML и Search Console, затем проверьте sitemap и внутренние ссылки. Для соседних проблем используйте чек-лист индексации сайта и разбор noindex и nofollow .

Источники

• Robots meta tag и X-Robots-Tag — Google Search Central
• Canonical URL и дубли — Google Search Central
• Sitemap — Google Search Central
• Google Indexing API: область применения