Почему страница не индексируется: диагностика в Яндекс Вебмастере и Google Search Console

Сначала разделите индексирование, позиции и канонический URL

Фразой «страница не индексируется» часто называют три разные ситуации. Для каждой нужен свой маршрут.

Индексирование — это обработка и возможное включение URL в поисковую базу. Ранжирование — выбор порядка результатов для конкретного запроса. Canonical, или канонический URL, — предпочтительная версия среди одинаковых или очень похожих адресов. Указанная владельцем версия является сигналом, а не приказом: Google и Яндекс могут выбрать другой адрес, если остальные сигналы противоречат заявлению. Это прямо отражено в документации Google о нормализации URL и Яндекса о каноническом адресе.

Поэтому отсутствие конкретного адреса в индексе не всегда является ошибкой. Например, URL с рекламными параметрами может правильно передавать canonical на чистую версию. В таком случае нужно проверять участие в поиске чистого адреса, а не пытаться индексировать каждый параметрический дубль.

Обратная ситуация тоже возможна: панель сообщает, что URL индексируется, но страница не находится по одному выбранному запросу. Это не опровергает статус панели. Индексирование дает странице возможность участвовать в поиске, но не гарантирует показ, позицию, трафик, заявку или цитирование в AI-ответе.

Что зафиксировать до открытия панелей

Для меня задача «страница не индексируется» начинается не с просьбы срочно что-то изменить, а с точного URL, ожидаемого результата и доказательства из панели.

Диагностика начинается не со статуса, а с проверяемого объекта. Задача «посмотрите страницу» недостаточна: разные варианты одного адреса могут иметь разные ответы, директивы и canonical.

В карточке проверки укажите полный URL со всеми параметрами, решение об индексировании, ожидаемый canonical и конечный адрес после редиректа. Добавьте выбранные ресурсы панелей, дату существенного изменения страницы, время каждого снимка и ссылку на доказательство: экспорт, скриншот, HTML, заголовки или фрагмент серверного лога.

Проверка полного адреса особенно важна при HTTPS, www, поддоменах, языковых версиях, завершающем слеше и параметрах. Если в задаче указан https://example.ru/page?utm_source=test, а canonical ведет на https://example.ru/page, сначала нужно подтвердить, что чистая версия действительно является ожидаемым результатом. Требование проиндексировать параметрический URL в такой ситуации может быть ошибкой постановки, а не техническим дефектом.

Полезно заранее выбрать один из четырех ожидаемых исходов:

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

Такой выбор не дает команде исправлять правильное исключение из индекса как ошибку.

Где может прерваться путь страницы

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

1. Обнаружение. Поисковик узнает адрес из ссылки, Sitemap, ранее известного URL или другого источника.
2. Планирование обхода. Известный URL попадает в очередь, но момент запроса зависит от множества условий.
3. Загрузка. Робот запрашивает адрес и получает HTTP-ответ, заголовки и тело документа.
4. Рендеринг. Если основной контент зависит от JavaScript, система обрабатывает ресурсы и формирует итоговый документ.
5. Разрешение на индексирование. Система учитывает noindex, X-Robots-Tag, доступность и другие технические сигналы.
6. Выбор canonical. Похожие URL объединяются, и система выбирает представителя группы.
7. Индексирование. Страница либо ее канонический представитель может быть включен в базу.
8. Ранжирование. Уже после этого система оценивает документ для конкретных запросов.

Google описывает обработку JavaScript как последовательность сканирования, рендеринга и индексирования. Базовые условия перечислены в технических требованиях Google Search, а особенности JavaScript — в руководстве по JavaScript SEO.

Главное правило диагностики: сообщение панели определяет следующую проверку, но не всегда раскрывает корневую причину. Статус становится подтвержденной проблемой только тогда, когда его можно связать с конкретным ответом, правилом, шаблоном, содержанием или выбранным canonical.

Какой инструмент что доказывает

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

Есть еще два источника доказательств, которые не заменяют панели. Первый — текущий HTTP-ответ и HTML страницы. Второй — серверные логи, где видны реальные запросы роботов, коды и время ответа. Синтетический тест может пройти сейчас, хотя во время последнего обхода сервер возвращал 5xx. И наоборот, панель может хранить старую ошибку после уже опубликованного исправления.

Маршрут диагностики одного URL в Google Search Console

Маршрут начинается в инструменте проверки URL. Вставлять нужно полный адрес в ресурс, который его охватывает.

1. Определите, должен ли индексироваться этот адрес

До чтения статуса зафиксируйте ожидаемое поведение:

• самостоятельная страница должна быть канонической и индексируемой;
• дубль должен передавать сигналы основной версии;
• удаленная страница должна возвращать согласованный ответ;
• перенесенная страница должна вести на релевантную замену;
• закрытый документ не должен становиться публичным только ради индекса.

Если ожидается другой canonical, отсутствие проверяемого URL в индексе может быть правильным результатом.

2. Сохраните данные из индекса Google

В результате проверки URL зафиксируйте общий статус, дату и тип последнего робота, разрешения на сканирование и индексирование, результат получения страницы, заявленный и выбранный canonical. Сохраните также найденные Sitemap и ссылающуюся страницу, если поля заполнены.

Пустое поле Sitemap или ссылающейся страницы не доказывает их отсутствие: инструмент показывает доступные Google сведения, а не полный реестр всех путей обнаружения.

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

Если URL отсутствует в индексе, запишите точную причину. Формулировки Обнаружена, не проиндексирована и Страница просканирована, но пока не проиндексирована говорят о разных этапах. Первая подтверждает, что Google знает адрес, но в доступных данных еще не зафиксирован обход. Вторая подтверждает сканирование, но не сообщает автоматически, что причина в «плохом тексте». Официальные расшифровки и ограничения собраны в отчете об индексировании страниц.

3. Сравните индексную и опубликованную версии

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

Сохраните результат доступа, заголовки и HTML, скриншот отрендерованной страницы, ошибки JavaScript, текущие robots-директивы и canonical.

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

При редиректе проверка опубликованной страницы следует по перенаправлению, но не показывает полную цепочку и конечный проверенный URL. Поэтому цепочку нужно сохранять отдельно через HTTP-клиент или серверные логи, а Search Console не использовать как единственное доказательство корректности редиректа.

Успешная проверка текущей версии означает только, что инструмент смог получить страницу в момент теста. Google отдельно предупреждает, что она не гарантирует индексирование; технически допустимые страницы также не обязаны включаться в индекс.

4. Проверьте рендеринг основного содержания

Для страницы, зависящей от JavaScript, сравните три состояния:

1. исходный HTML ответа;
2. HTML после рендеринга;
3. сохраненную Google версию, если она доступна.

Проверять нужно не декоративные элементы, а основу документа: title, robots, canonical, H1, главный текст и ссылки на другие важные страницы. Если пользователь видит содержание, но его нет в отрендерованной версии инструмента, техническая доступность основного контента не подтверждена.

5. Исключите отдельные системные ограничения

Если URL технически доступен, но картина остается необъяснимой, проверьте отчеты о ручных мерах, проблемах безопасности и временных удалениях. Активное удаление может скрыть URL из результатов, но оно не заменяет постоянное удаление, noindex или корректный серверный ответ. Отсутствие сообщений в этих отчетах закрывает только соответствующие ветки и не доказывает, что страница будет проиндексирована.

6. Назначьте одно следующее действие

Действие должно следовать из доказательства: убрать конкретный запрет, открыть нужный ресурс, исправить ответ, вернуть содержание в отрендерованный HTML, согласовать canonical или добавить доступную ссылку. Правильный дубль оставляют исключенным, а неподтвержденную проблему переводят в наблюдение. Меняйте одну подтвержденную причину за раз: иначе невозможно понять, что повлияло на результат и не возник ли побочный дефект.

Маршрут диагностики одного URL в Яндекс Вебмастере

В Яндексе также нужно начать с точного адреса и выбранного сайта. Разные протоколы, хосты и неглавные адреса могут относиться к разным состояниям.

1. Проверьте адрес сайта и ожидаемый URL

Если страница относится к неглавному адресу, Яндекс может показывать состояние NOT_MAIN_MIRROR. Такой статус переводит задачу из локальной диагностики URL в проверку главного адреса или миграции. Самостоятельно «возвращать в индекс» неглавную версию не нужно, пока не определена правильная архитектура. Принципы главных и неглавных адресов описаны в справке Яндекса.

2. Откройте «Проверку страницы»

Проверьте полный URL, выберите робота и сохраните адрес, HTTP-код, доступное содержание, поисковый статус, результат мобильной проверки, если он показан, а также дату и время снимка.

Эта проверка показывает текущее состояние, но не заменяет историю последнего реального обхода или индексную версию. Их нужно сверять отдельно по «Статистике обхода», «Страницам в поиске» и, если URL добавлен туда, «Мониторингу важных страниц». Статус SEARCHABLE подтверждает участие URL в поиске на момент соответствующих данных, но не обещает показ по любому запросу.

3. Найдите URL среди страниц в поиске и исключенных страниц

В разделе «Страницы в поиске» проверьте точный адрес, вкладку исключенных URL и доступную выгрузку. Полезные поля: дата изменения, URL, HTTP-код, статус, целевой адрес, последний доступ, заголовок и событие.

Отсутствие URL в интерфейсной выборке не равно доказанному отсутствию в знаниях Яндекса. В этом случае результат проверки записывается как «в доступной выборке не найден», а затем сверяется со «Статистикой обхода», Sitemap, внутренними ссылками и серверными логами.

4. Сверьте последний обход с текущим ответом

«Статистика обхода» показывает, когда робот обращался к URL и какой код был зафиксирован. «Проверка ответа сервера» показывает текущий синтетический ответ. Эти данные отвечают на разные вопросы.

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

Яндекс относит DNS-ошибки, сбои соединения, тайм-ауты, пустые ответы и ошибки обработки к отдельным техническим состояниям. Их актуальная расшифровка находится в словаре ошибок индексирования.

5. Проверьте правила обхода и индексирования

«Анализ индексации страницы» помогает проверить влияние robots.txt и meta robots. Сохраните сработавшее правило, выбранного робота, meta robots, X-Robots-Tag и место генерации директивы: шаблон, CMS, сервер или приложение.

robots.txt управляет обходом, а noindex — индексированием доступного документа. Если робот не может загрузить страницу из-за Disallow, он может не увидеть расположенный внутри noindex. Яндекс описывает область метатегов и HTTP-заголовков в справке по управлению индексированием.

6. Разберите причину исключения без догадок

Коды Яндекса нужно использовать как начало конкретной ветки:

• HTTP_ERROR, HOST_ERROR, PARSER_ERROR ведут к проверке загрузки и обработки;
• ROBOTS_HOST_ERROR, ROBOTS_TXT_ERROR, META_NO_INDEX ведут к точному запрету;
• REDIRECT_NOTSEARCHABLE требует проверки целевого URL;
• NOT_CANONICAL требует проверить фактический rel="canonical" или HTTP-заголовок Link, поле целевого адреса и доступность этого URL;
• DUPLICATE требует поиска представителя группы похожих страниц;
• CLEAN_PARAMS требует проверки обработки GET-параметров;
• NOT_MAIN_MIRROR относится к неглавному адресу;
• LOW_DEMAND является алгоритмическим статусом с несколькими возможными основаниями и не доказывает одну причину;
• OTHER нужно трактовать в контексте конкретного раздела или выгрузки: это может быть отсутствие актуальных данных у робота либо известный роботу URL, который не участвует в поиске.

Официальная расшифровка статусов опубликована в справке «Страницы в поиске». Для LOW_DEMAND нельзя автоматически писать «санкция», «дубль» или «нет спроса». Нужны дополнительные проверки содержания, сходства, рендеринга, внутренних ссылок и ожидаемой поисковой задачи страницы. Для OTHER сначала фиксируют источник статуса, затем проверяют актуальность обхода, ответ сервера и запреты. Если этого недостаточно для причины, результат записывают как «недостаточно данных».

7. Проверьте canonical и отрендерованный документ

Сохраните canonical из исходного HTML или HTTP-заголовка, проверьте его абсолютный адрес, ответ и индексный статус. Затем сравните основное содержание проверяемого URL и выбранной альтернативы.

Если страница зависит от JavaScript, сопоставьте исходный HTML, пользовательскую версию и содержимое, доступное в инструментах Яндекса. Настройка JavaScript-рендеринга действует на сайт, но сама по себе не доказывает, что конкретный URL был успешно отрендерен. Актуальные границы описаны в документации Яндекса по индексированию JavaScript.

8. Проверьте системный фон

«Диагностика сайта» помогает увидеть ошибки, которые могут затронуть не один URL: проблемы DNS, доступности, SSL, главной страницы, robots.txt или Sitemap. Но отсутствие сообщений не закрывает локальную ветку. Для одного URL по-прежнему нужны его собственный статус, последний обход, текущий ответ, директивы и canonical.

Матрица: статус, следующая проверка и приемка

Матрица не заменяет документацию панелей. Ее задача — не дать команде перескочить от общего сообщения к случайному исправлению.

Пять технических проверок, которые нельзя смешивать

Когда в одной задаче одновременно предлагают менять robots.txt, Sitemap, текст и canonical, я сначала прошу разделить гипотезы: иначе команда не поймет, какое действие действительно повлияло на результат.

Матрица выбирает ветку, а эта таблица фиксирует минимальное доказательство по каждому механизму.

Полная настройка robots, Sitemap и canonical остается отдельной задачей: здесь проверяется только ветка, способная объяснить состояние одного URL.

Когда проблема одного URL становится проблемой шаблона

Локальная диагностика должна остановиться, если доказательство повторяется на группе страниц. Признаки системного масштаба:

• одинаковый noindex появляется на всех материалах одного типа;
• canonical каждого документа ведет на хаб или главную;
• JavaScript не отдает основной текст на целом шаблоне;
• сервер периодически возвращает 5xx группе URL;
• внутренние ссылки генерируются только после недоступного роботу действия;
• в Sitemap попадают редиректы или неканонические версии одного раздела;
• неглавный хост создает параллельные адреса;
• один и тот же статус растет после выпуска CMS или миграции.

В таком случае карточка одного URL становится воспроизводимым примером, а задача расширяется только после проверки нескольких страниц того же шаблона. Один пример еще не доказывает масштаб. Несколько одинаковых доказательств позволяют назначить исправление на компонент, шаблон, серверное правило или CMS.

Полный производственный цикл — от аудита до внедрения и приемки — раскрыт в материале о SEO-продвижении под ключ. Текущая диагностика заканчивается раньше: она устанавливает состояние конкретного URL и формирует проверяемое действие.

Когда отправлять страницу на повторный обход

Запрос повторного обхода имеет смысл после трех событий:

1. причина подтверждена;
2. исправление опубликовано;
3. текущая версия прошла проверку по согласованному критерию.

Для одного важного URL в Google можно использовать запрос индексирования после проверки опубликованной страницы. Для большого набора обновленных URL Google рекомендует актуальный Sitemap. Повторная отправка одного адреса много раз не ускоряет процесс, а запрос не гарантирует индексирование; это зафиксировано в официальной инструкции Google.

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

Фиксированный срок обещать нельзя. Дата повторной проверки назначается как рабочая контрольная точка, а не как гарантия обновления индекса.

Карточка задачи на исправление

Я считаю задачу готовой к передаче специалисту, когда в ней есть один владелец действия, одно подтвержденное состояние и понятный критерий повторной проверки.

Хорошая карточка позволяет другому специалисту воспроизвести проблему без устного пересказа. Для этого достаточно восьми полей.

Как принять исправление

Для меня хороший итог — не зеленая отметка сама по себе, а согласованная цепочка: нужный URL определен, исправление опубликовано, проверка повторена, новый статус зафиксирован.

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

Не каждое техническое исправление сразу заканчивается индексированием. Поэтому итог задачи выбирается из четырех состояний:

• исправлено. опубликованный дефект устранен, а ожидаемый статус позже подтвержден;
• неприменимо. проверяемый URL не должен индексироваться или механизм к нему не относится;
• наблюдение. исправление принято на стороне сайта, но данные поисковика еще не обновились;
• недостаточно данных. причина не доказана, назначена следующая проверка и сохранен текущий снимок.

Зеленая отметка в одном инструменте не является самостоятельным критерием качества. Хороший результат — согласованная цепочка от ожидаемого URL до проверенного состояния, которую можно повторить и передать другому участнику проекта.

Ограничения диагностики

Search Console и Яндекс Вебмастер не раскрывают все алгоритмические причины и обновляются не одновременно с сайтом. Проверка текущей версии показывает состояние в момент теста, а индексные данные могут относиться к прошлой версии. Отчет по группе URL не всегда объясняет один шаблон. Серверный ответ в момент проверки не заменяет историю реальных запросов.

Поэтому некоторые выводы должны оставаться гипотезами:

• Обнаружена, не проиндексирована не доказывает проблему crawl budget;
• Страница просканирована, но пока не проиндексирована не доказывает низкое качество;
• LOW_DEMAND не доказывает санкцию, дубль или отсутствие спроса как единственную причину;
• значение OTHER зависит от раздела или выгрузки и не устанавливает корневую причину без дополнительных данных;
• отсутствие URL в ограниченной выгрузке не доказывает, что поисковик его не знает;
• доступность для индексирования не означает фактическое включение в индекс;
• включение в индекс не гарантирует позиции и показы.

Если один URL не удается диагностировать после базового маршрута, задача не должна превращаться в список случайных изменений. Корректный промежуточный результат — пакет доказательств, статус «недостаточно данных» и следующая проверка, способная подтвердить или опровергнуть одну гипотезу.

Что делать дальше

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

Такой разбор и последующие работы можно заказать на странице SEO-продвижения Медиакода. До передачи задачи полезно подготовить полный URL, ожидаемый canonical, снимки панелей, текущий ответ и критерий приемки. Этот набор сокращает путь от сообщения «страница не индексируется» до проверяемого решения.