Страница не появилась в поиске: как проверить доступность и индексацию

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

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

Уточните URL, поисковую систему и вопрос

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

Затем сформулируйте жалобу точно:

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

Назовите систему, для которой проверяется состояние: Google, Яндекс или обе независимо. Если используются данные кабинета, запишите точное название отчёта и дату наблюдения.

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

Пример паспорта:

Даже опубликованный сайт Switch On AI требует отдельных наблюдений за доступностью, индексированием и поисковым результатом. Сам факт публикации не доказывает остальные состояния.

Проверьте конечный ответ и нужное содержание

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

HTTP 200 недостаточно. Сервер может вернуть с таким кодом форму входа, CAPTCHA, пустой шаблон или текст ошибки. Успешной технической проверкой нужного содержания можно считать только наблюдение, в котором по конечному адресу получена ожидаемая публичная страница. И оно всё равно описывает ответ конкретному клиенту в конкретное время, а не успешный обход Google или Яндексом.

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

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

Разделите обход, запрет индексации и заявленный canonical

Для страницы, которую хотят публиковать в поиске, сделайте отдельные записи:

Не снимайте защиту или запреты сразу со всего сайта. Сначала проверьте точный URL, конкретное правило и назначение страницы.

Если Google не может получить документ из-за robots.txt, нельзя заключить, что он прочитал актуальный noindex. В этом случае наблюдение о доступности обхода известно, а содержание текущей страницы для робота — нет. Эти состояния нельзя объединять в одну отметку «разрешено» или «запрещено».

В Google сравните индексную и живую версии

В разрешённых данных свойства сначала изучите индексную версию URL. Сохраните:

• дату последнего обхода;
• статус индексирования и указанную причину;
• Google-selected canonical;
• при необходимости — user-declared canonical известной версии.

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

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

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

В Яндексе используйте собственные данные обхода и поиска

Не переносите названия полей и результаты Google URL Inspection в Яндекс. В Яндекс Вебмастере разные задачи решают собственные разделы:

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

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

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

Не принимайте sitemap, квитанцию или site: за полный индекс

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

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

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

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

Соберите таблицу наблюдений и разберите учебный случай

Центральный материал диагностики — таблица, в которой каждое доказательство имеет время, источник и предел. Не объединяйте текущие технические условия, сохранённое индексное состояние и неизвестные данные.

Ниже — полностью синтетический учебный журнал. Это не текущие данные Google Search Console или Яндекс Вебмастера и не выполненные Switch On AI проверки. Условный адрес https://example.invalid/service/ приведён как текст и не предназначен для перехода.

Страницу хотели открыть для поиска. В условный момент T1 она содержала noindex, а в T2 запрет сняли. Все состояния заданы для объяснения.

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

Итоговая запись: «Исправление текущего технического условия подтверждено; состояние новой версии в поиске не проверено».

Есть два важных исключения:

1. Если свежий индексный отчёт показывает другой выбранный canonical, одного ожидания недостаточно. Сопоставьте назначение страниц, редиректы, заявленные canonical, внутренние ссылки и сходство содержания.
2. Если HTTP 200 возвращает форму входа или CAPTCHA, проверка нужной публичной страницы не пройдена. Сначала выясните, как получить требуемое содержание.

Назначьте действие и последующую проверку

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

адрес → датированное доказательство → техническое действие → ответственный → новый факт, подтверждающий исправление.

Например, если текущая версия содержит ошибочный noindex, техническим результатом будет публикация версии без него и повторная проверка HTML или ответа. Решение поисковой системы нужно записать отдельно после нового обхода или появления свежего отчёта. Завершённое техническое исправление не означает автоматического включения в индекс.

Если доступных данных недостаточно, запросите у владельца разрешённый датированный отчёт по точному URL. Не меняйте корректные редиректы или canonical только из-за старого сигнала: сначала выясните, к какой версии и адресу он относился.

В проекте SEO-мониторинга Switch On AI наблюдения связывают с конкретными источниками и следующими задачами. Это выполненный проект наблюдения, но не гарантия индексации, позиций или автоматического исправления страниц.

Если нужен не только разбор журнала, но и согласованные изменения, Switch On AI предлагает диагностику и исправления на сайте. Состав может включать датированный исходный срез, приоритеты, ограниченный набор технических или содержательных правок и последующую проверку затронутых адресов. Индексацию и срок появления поисковая система определяет самостоятельно.

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