Сайт отдаёт 200 ОК, robots.txt не запрещает обход, мета-теги чистые — а страниц в индексе как не было, так и нет. Такая жалоба обычно всплывает на проектах, где до вас уже поработал подрядчик, и первым делом стоит проверить не то, что лежит на виду, а то, что обычно пропускают.
Индексацию можно закрыть не только в robots.txt
Первое, на что смотрят при проверке индексации — это robots.txt и мета-тег robots на странице. Но запретить обход и показ в поиске можно и на уровне сервера, минуя оба этих места:
- правилами в .htaccess — например, заголовком X-Robots-Tag: noindex, который отдаётся ботам и не виден в исходном коде страницы;
- условными редиректами или подменой ответа именно для поисковых ботов по user-agent;
- скриптом, который включается сразу после генерации страницы и меняет её содержимое или отправляет на другой адрес — при этом обычный посетитель и даже беглая проверка через «Просмотр кода страницы» ничего подозрительного не покажут.
Если в анамнезе проекта есть долг перед предыдущим подрядчиком, такие скрытые блокировки не редкость: убрать директиву можно за минуту, но её действие продолжается, пока разбирательство не завершится. Поэтому при подозрении на умышленное закрытие индексации .htaccess и серверные ответы боту проверяются в первую очередь — до разбора контента и ссылок.
Инструмент, который обычно не проверяют, но должны
Есть куда более простое и куда более частое объяснение: страница может физически не находиться в индексе, потому что её туда отправили сами — через инструмент «Удаления» в Google Search Console.
Временное удаление URL через этот инструмент блокирует показ страницы в поиске примерно на шесть месяцев. Страница при этом продолжает отдавать 200 ОК и остаётся доступной по прямой ссылке — сервис лишь скрывает её из выдачи и очищает кешированную копию. Полгода — срок, который Google даёт владельцу сайта на то, чтобы либо исправить страницу, либо оформить закрытие индексации постоянным способом (404, каноникал, серверный noindex).
Если прошлый исполнитель отправил страницы на скрытие через этот инструмент, а потом просто не вернулся к проекту, симптом будет ровно таким: 200 ОК, чистый robots.txt, чистые мета-теги — и страницы нет в поиске без всякой видимой причины. Проверка Removals в Search Console должна входить в базовый чек-лист технического аудита, а не быть запасным вариантом на случай, если ничего другое не помогло.
У этого же инструмента есть и практическая польза за пределами диагностики: он ускоряет вычистку дублей и уже настроенных редиректов из индекса, когда нужно быстро убрать старую версию URL, не дожидаясь переобхода.
Перелинковка не открывает индексацию, но меняет расписание ботов
Отдельный миф — что на большом сайте достаточно «поиграть с перелинковкой», и страницы начнут индексироваться. Само по себе изменение ссылочной структуры индексацию не запускает: если страница закрыта директивой или не устраивает поисковик по качеству, перелинковка это не изменит.
Что перелинковка действительно меняет — это частоту и маршрут обхода ботов, причём для разных систем по-разному. Для Google на это влияет в том числе поведение сервера: корректные заголовки Last-Modified в ответе помогают приоритизировать переобход изменившихся страниц. Для Яндекса ротация обхода устроена иначе и может вести себя менее предсказуемо. Рассчитывать на перелинковку как на инструмент «включения» индексации не стоит — это регулировка скорости обхода, а не переключатель видимости.
Порядок диагностики
- Проверьте .htaccess и заголовки ответа сервера ботам — ищите X-Robots-Tag и условные редиректы по user-agent.
- Откройте Google Search Console → Удаления и проверьте, не находится ли URL во временном скрытии — это самая частая и самая легко просматриваемая причина.
- Сверьте robots.txt и мета-теги — если они чистые, а первые два пункта тоже чистые, ищите причину в качестве контента или в санкциях.
- Если решаете вопрос через изменение перелинковки, воспринимайте это как способ ускорить переобход уже открытых страниц, а не как способ снять блокировку.
Внимание стоит уделять именно тем местам, которые не видны при беглом просмотре: серверным ответам конкретно для ботов и инструментам, через которые страницу можно скрыть, не трогая ни код, ни контент.
Как отличить причины по симптомам
| Симптом | Вероятная причина | Что проверить |
|---|---|---|
| Страница видна пользователю, но не открывается ботом или отдаёт ему другой контент | Условная блокировка по user-agent или директива в .htaccess | Запрос с подменой User-Agent на Googlebot/YandexBot, сверка ответа сервера |
| Страница отдаёт 200, в панели вебмастера статус «Страница является канонической, но не проиндексирована» или прямое указание на удаление | Отправлена во временное скрытие через Search Console | Раздел «Удаления» в Search Console |
| Индексация в целом идёт, но медленно, изменения подхватываются с задержкой | Низкий приоритет обхода, а не блокировка | Заголовки Last-Modified, частота изменений контента, внутренняя перелинковка |
Такое разделение экономит время: не имеет смысла переписывать контент или наращивать перелинковку, если проблема физически находится в разделе «Удаления» Search Console, — сначала снимается блокировка, и только потом имеет смысл оценивать, действительно ли странице не хватает ссылочного веса или актуальности.
Проверку раздела «Удаления» стоит сделать частью регулярного технического аудита, а не разовой мерой на случай проблем: инструментом активно пользуются и для чистки старых дублей, и для убирания уже настроенных редиректов, оставшихся от прежней структуры сайта, — и специалисты, которые проверяют его на всех проектах систематически, реже упускают подобные случаи.
