Почему страницы не индексируются в Яндексе и Google: порядок диагностики

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

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

Четыре этапа: от адреса до выдачи

Поисковик сначала узнаёт о существовании адреса: по ссылке с другой страницы, из sitemap, из внешних источников. Потом робот запрашивает URL и получает ответ сервера. Затем страница обрабатывается: разбирается HTML, при необходимости выполняется JavaScript, определяется канонический адрес. И только после этого система решает, будет ли страница участвовать в поиске.

У Яндекса последовательность похожая: обход, загрузка и обработка, формирование базы участников поиска и уже потом ранжирование. Закрытые от индексирования страницы и дубли в базу участников поиска не попадают.

Статусы в панелях подсказывают, на каком этапе остановилась страница. В Search Console «Обнаружена, не проиндексирована» означает, что адрес известен, но робот его ещё не обошёл. «Страница просканирована, но пока не проиндексирована» означает, что обход был, а решение о включении пока отрицательное. В Яндекс Вебмастере в разделе «Страницы в поиске» у исключённых адресов указана причина: дубль, редирект, запрет, ошибка HTTP, малоценная или маловостребованная страница.

Соберите выборку, а не один адрес

Одна страница почти ничего не говорит о причине. Возьмите 10-20 проблемных адресов и столько же работающих страниц того же типа: карточки товаров с карточками, статьи со статьями. Если из сорока карточек в индексе тридцать пять, ищите отличие пяти оставшихся. Если не индексируется почти весь шаблон, проблема скорее в шаблоне или правилах сайта.

Для каждого адреса зафиксируйте в таблице:

• URL и тип шаблона, дату публикации или последнего изменения;
• статус в Search Console и Вебмастере, дату последнего обхода и дату вашей проверки;
• HTTP-код и цепочку редиректов, если она есть;
• canonical из исходного HTML и после выполнения JavaScript;
• есть ли адрес в sitemap и сколько внутренних ссылок на него ведёт;
• meta robots и заголовок X-Robots-Tag.

Такая таблица экономит время и вам, и подрядчику. Без неё диагностика начинается с вопроса «а какие именно страницы?», и первая неделя уходит на сбор того, что можно было выгрузить за час.

Шаг 1. Ответ сервера и редиректы

Робот должен получить код 200 прямо по адресу страницы, без цепочки переходов. Проверить ответ можно инструментом «Проверка ответа сервера» в Вебмастере, живой проверкой URL в Search Console или командой curl с заголовком нужного робота.

Частые находки на этом шаге: цепочка из двух-трёх редиректов из-за слеша и протокола; редирект на главную вместо страницы; код 200 на странице с текстом «ничего не найдено» (поисковик сочтёт её мягкой 404); ошибки 5xx под нагрузкой, которые не воспроизводятся днём из офиса. Отдельная история с защитой от ботов. CDN или WAF иногда отдают роботу страницу-проверку или 403, хотя человек в браузере видит нормальный сайт. Это видно только в логах сервера или в проверке со стороны поисковика.

Шаг 2. Запреты: robots.txt, meta robots, X-Robots-Tag

robots.txt управляет обходом, а noindex управляет попаданием в индекс. Это разные инструменты, и подменять один другим опасно.

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

Про X-Robots-Tag вспоминают реже всего. Этот заголовок задаётся на сервере, в HTML его не видно. Его ставят на тестовый домен или на PDF и потом переносят конфигурацию на рабочий сайт. Заголовки ответа видны в той же проверке ответа сервера или во вкладке Network в браузере.

Ещё одна ловушка: noindex в исходном HTML, который JavaScript убирает после загрузки. Встретив noindex, Google может вообще не выполнять рендеринг и JavaScript страницы. Снятие запрета скриптом в таком случае не сработает.

Шаг 3. Что робот видит после JavaScript

Сравните исходный HTML страницы (то, что сервер отдаёт до выполнения скриптов) с тем, что показывает проверка URL в Search Console. Если основной текст, ссылки или canonical появляются только после работы скрипта, страница зависит от рендеринга. Google рендерит JavaScript, но это отдельный этап, и ошибка API или таймаут на нём дают пустую страницу.

У Яндекса рендеринг включается настройкой «Рендеринг страниц JavaScript» в разделе «Индексирование» Вебмастера. Функция помечена как бета-версия, по умолчанию робот сам решает, выполнять ли скрипты. Подробнее о проверке шаблонов мы писали в материале о JavaScript SEO и SSR.

Шаг 4. Canonical, sitemap и ссылки спорят друг с другом

Для Google rel="canonical" и редирект сильные сигналы канонизации, а sitemap слабый. Это подсказки, а не приказы: если сигналы противоречат друг другу, поисковик выберет основной адрес сам.

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

Проверьте и входящие ссылки. Страница, которая есть в sitemap, но на которую не ведёт ни одна ссылка внутри сайта, формально обнаружена. Но для поисковика это слабый сигнал её важности. Как выстроить связи между страницами, разобрано в статье о внутренней перелинковке.

Шаг 5. Дубли и самостоятельная ценность

Бывает, что техника в порядке: 200, нет запретов, canonical на себя, ссылки есть. А статус всё равно «просканирована, но не проиндексирована» или «малоценная или маловостребованная». Тогда вопрос уже не технический. Страница повторяет другую, мало добавляет к тому, что уже есть в индексе, или отвечает на запрос, который почти никто не задаёт.

Типичные кандидаты: страницы городов, где меняется только название; теги блога с двумя статьями; категории с одним товаром; варианты товара, отличающиеся цветом в заголовке. Даже страница с оригинальным текстом может не попасть в базу Яндекса из-за низкого спроса или высокой конкуренции, и ошибкой сайта это не считается. Решений три: добавить странице собственное содержание, объединить её с более сильной или сознательно закрыть. Как выбирать между ними, мы разобрали в материале о каннибализации запросов, а как избегать таких страниц на этапе проектирования, в статье о структуре сайта под спрос.

Условный пример: страница услуги, которой нет в Яндексе

Пример учебный. Компания по монтажу вентиляции опубликовала страницу «Вентиляция для ресторанов». Через пять недель она есть в Google, но отсутствует в Яндексе.

1. Проверка статуса URL в Вебмастере показывает: страница исключена как дубль общей страницы «Монтаж вентиляции».
2. Ответ сервера 200, запретов нет, canonical указывает на саму страницу. Технически к адресу претензий нет.
3. Сравнение текстов показывает, что большая часть совпадает: та же схема работ, те же преимущества, отличаются заголовок и первый абзац.
4. Гипотеза: Яндекс не видит у страницы самостоятельного ответа. Действие: добавить то, что важно именно ресторану. Требования к вытяжке над кухней, монтаж без остановки работы зала, согласования, фото выполненных объектов, отдельные вопросы и ответы.
5. Поставить ссылку на новую страницу с общей страницы услуги и из раздела проектов, затем отправить адрес на переобход.
6. После следующего обхода сверить статус. Если страница снова признана дублем уже с новым содержанием, гипотеза не подтвердилась. Тогда разумнее сделать ресторанный сценарий разделом общей страницы, чем бороться за отдельный URL.

После исправления: переобход и чтение результата

Отправляйте на переобход только исправленные адреса: через «Проверку URL» в Search Console и «Переобход страниц» в Вебмастере. У обоих инструментов есть лимиты, и ежедневная повторная отправка одних и тех же URL не ускоряет обработку. Для большого количества страниц надёжнее обновить sitemap с корректной датой изменения.

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