Значение и границы
Сканирование, индексация и ранжирование связаны между собой, но это разные этапы. Краулер может запросить URL и не добавить его в индекс. Документ в индексе может показываться по одним запросам и не показываться по другим. Позицию в выдаче система выбирает позже, для конкретного запроса и контекста. Если считать любое отсутствие проблемой ранжирования, реальная причина останется скрытой.
Практический порядок работы
Для важного URL сначала проверьте, что он отдаёт нужный публичный контент, разрешён к сканированию, не содержит директивы noindex, использует нужный канонический URL и доступен по ссылке с открытого пути обнаружения. Включение в карту сайта помогает обнаружению, но не гарантирует индексацию. Выясните, не объясняют ли результат дубли, мягкие ошибки или недоступность страницы.
Что проверять
Указывайте точный URL и дату проверки. Отчёты «Проверка URL» и «Индексирование страниц» в Google Search Console дают полезные сигналы о том, как Google видит страницу. Браузер и выборка из скана показывают, что сайт отдаёт сейчас. Отделяйте живую проверку от старого отчёта, чтобы устаревший статус не приняли за сбой нового релиза.
Ограничения и частые ошибки
Не обещайте индексацию только потому, что URL отправили на индексацию, на него есть ссылка или он есть в карте сайта. Не блокируйте URL в robots.txt и не рассчитывайте, что noindex на заблокированном ответе будет учтён. Полезный результат — страница, которую можно объяснить: она технически подходит для индекса и не получает противоречивых сигналов.
Диагностика индекса: один URL за раз
Вместо общей метки «не проиндексировано» ведите рабочую таблицу по каждому URL. Фиксируйте запрошенный URL, итоговый ответ сервера, канонический тег, метатег robots и X-Robots-Tag, состояние контента, внутреннюю ссылку-источник, статус в карте сайта и дату наблюдения. Так видно, это проблема доступности, решение о дублях или вопрос качества контента. Кроме того, каноническая альтернатива, намеренно закрытый от индекса фильтр и неизвестный URL не попадут в один и тот же «провал».
- Запросите URL без авторизованной сессии, зафиксируйте итоговый статус и основной контент после рендеринга.
- Проверьте, разрешено ли сканирование URL и согласованы ли правила индексации и канонический URL.
- Найдите путь обнаружения по внутренним ссылкам с релевантного хаба и убедитесь, что запись в карте сайта указывает на тот же итоговый канонический URL.
- Если доступно, проверьте URL в Search Console, сохранив дату отчёта и причину, которую указал Google.
- Внесите одно точечное исправление, затем повторите живую проверку и проверку по отчётам. Не отправляйте каждый URL на индексацию снова и снова.
Пример — фильтр в категории. Если у фильтра нет отдельного ассортимента и поискового интента, он может намеренно указывать каноническим URL на родительскую категорию или получить noindex. Если у него есть свой ассортимент и понятная цель пользователя, нужны стабильный URL, согласованный канонический тег, внутренние ссылки для обнаружения и контент, который отличает фильтр от родительской категории. Правильный результат зависит от политики сайта. Цель не в том, чтобы индексировать каждый сгенерированный URL.
Проверку стоит строить на небольшой матрице маршрутов: обычная страница с контентом, версия с параметрами, удалённый URL и страница, которая намеренно исключена. Так видно, что система различает состояния. Google объясняет, что индексация идёт после сканирования и анализа, поэтому доступная страница всё равно может быть пропущена или объединена с дублем. Прямо отметьте эту неопределённость и не утверждайте, что карта сайта или запрос гарантируют включение в индекс.
Держите доказательную базу достаточно узкой, чтобы по ней можно было действовать. Датированная выборка из десяти важных URL с классификацией по живому статусу и политике индексации полезнее безликого счётчика тысяч «исключённых» страниц. После релиза проверьте ту же выборку и разбирайте только тот класс, который изменился неожиданно.
При расследовании изменения сохраняйте и старое наблюдение, и новое. Причина в отчёте может отставать от реального ответа сервера, а страница может попасть в кластер дублей, даже если её текущая загрузка в порядке. Сравнение одного и того же URL, одной политики канонических тегов и одного состояния краулера во времени помогает не принимать позднее обновление отчёта за необъяснимый технический откат.