Диагностика конкретного URL

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

Рассмотрим два адреса из нашего учебного реестра: сохранённый урок B и новую статью C. Результатом будет запись, в которой отделены состояние страницы на сайте, сведения Google и сведения Яндекса. Все начальные значения для example.com здесь — условные данные курса. Они не являются результатами проверки ProfessorWeb или доступного нам аккаунта. Если вы выполняете действия, замените пример домена собственным подтверждённым сайтом.

Три разных вопроса о странице

Прежде чем открывать проверку, сформулируем вопросы. Первый: что сервер отдаёт по адресу сейчас? Второй: что поисковая система получила при последнем известном обходе? Третий: какую версию материала она использует в поиске? Ответы могут различаться без ошибки в инструментах. Между загрузкой документа и обновлением поисковых данных проходит время; кроме того, поисковая система может объединять адреса одинакового материала.

У нас уже есть начальные условия стенда:

ID	Адрес на https://example.com	Учебный HTTP-статус	Учебное разрешение индексации	Объявленный canonical	Реальное состояние в поиске
B	/my/LINQ/linq_xml/level7/7_1.php	200	Разрешена	На B	Не измерено
C	/articles/markdown-guide.html	200	Запрещена через noindex	На C	Не измерено

Последняя колонка остаётся неизвестной. Даже для исправного B мы не добавляем слово «проиндексирован»: наличие документа и отсутствие явного запрета ещё не являются данными поисковой системы. Аналогично, заданный в сценарии noindex у C не позволяет придумать дату исключения страницы из Google или Яндекса.

Для хранения сведений используйте seo-audit/observations-template.csv. В поле engine указывайте google, yandex или site; в check_type — indexed_report, live_test или http соответственно. Начальные строки из initial-observations.csv имеют тип fixture и дату not_measured: это описание задачи, которое нельзя подменять новым отчётом.

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

Сведения Google об адресе B

В Search Console выберите ресурс, охватывающий нужный адрес, и введите полный URL B в инструмент проверки URL. Протокол, имя хоста и путь имеют значение: проверка https://example.com/ не заменяет проверку вложенного урока. В первоначальном результате рассматриваются сведения из индекса Google; для обращения к опубликованной версии предусмотрена отдельная проверка. Это различие описано в справке инструмента проверки URL.

Начните с общего состояния, затем раскройте сведения об индексировании. Не ограничивайтесь цветом карточки. Запишите текст причины, доступные сведения об обходе и два канонических адреса: объявленный владельцем и выбранный Google. Последний получается из индексных данных, а проверка опубликованной страницы не показывает, какой адрес Google выберет после обработки изменений. Различие канонических сведений в инструменте.

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

Для B заполнение записи удобно начать с такой таблицы. Это шаблон полей, а не готовый отчёт:

Поле	Что записать
url_id	B
checked_at	Фактические дату и время просмотра, включая часовой пояс
engine	google
check_type	indexed_report
http_status	Значение, прямо показанное этим отчётом, иначе unknown
declared_canonical	Адрес из отчёта; если поле отсутствует, unknown
selected_canonical	Адрес, выбранный Google, если он показан
index_state	Показанный статус без самостоятельного переименования
evidence	Название инструмента, дата обхода и существенная причина

Если в результате нет выбранного canonical, не заполняйте его адресом B «по логике». Нам нужна граница между наблюдением и предположением. Она особенно полезна, когда позже проверяется изменение: мы сможем сравнить новые данные с прежними, а не с собственным ожиданием.

Сохранённый путь с .php здесь выбран осознанно. При обновлении ProfessorWeb мы оставили старые адреса материалов; переход к Markdown не требует их переименования. Однако сам факт сохранения пути не говорит о сегодняшнем состоянии конкретного урока в поиске. Этот вопрос решается именно наблюдением, которое сейчас учимся записывать.

Текущая версия и пример C

Теперь рассмотрим C. По условиям задачи в её HTML оставлен noindex. Нам необходимо выяснить, относится ли запрет к опубликованной странице и когда поисковая система могла его увидеть. Выполните проверку опубликованного URL в Search Console и сохраните её результат новой строкой с check_type=live_test. Первую строку с индексными сведениями оставьте на месте.

У текущей проверки есть самостоятельный смысл: она помогает сопоставить состояние сайта с более ранними данными. Но положительный результат не доказывает появления страницы в индексе и не проверяет все условия её участия в поиске. Не превращайте сообщение о доступности документа в отметку «индексация восстановлена». Ограничения проверки опубликованного URL.

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

Разрешение индексации проверяется по документу и HTTP-заголовкам. В HTML оно может выглядеть так:

<meta name="robots" content="noindex">

Это короткий фрагмент <head> страницы C, а не весь её исходник. Отдельно сервер может передавать X-Robots-Tag; такой заголовок не виден при чтении одного HTML-файла. Метатег и заголовок относятся к правилам обработки страницы, поэтому фиксируйте, где именно найдено указание. Способы передачи правил описаны в документации Google о robots meta и X-Robots-Tag.

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

Те же адреса в Яндекс Вебмастере

Перейдите в Яндекс Вебмастере к инструменту Индексирование → Проверка страницы и укажите полный адрес B или C. Документация на дату подготовки урока, 10 октября 2026 года, описывает выбор устройства и робота, проверку получаемого кода ответа и доступного контента. Проверка страницы в Яндекс Вебмастере.

Для сведений о присутствии в поиске рассматривайте данные версии в базе, а не только результат загрузки. В справке Яндекса указана вкладка Версия страницы в базе; поисковый статус также можно сопоставить с инструментом «Страницы в поиске». Обход страницы и её участие в поиске рассматриваются отдельно. Как проверить важные страницы.

В таблице это будут отдельные строки с engine=yandex. Не переносите выбранный Google canonical в колонку выбранного адреса Яндекса. Если конкретный результат Яндекса сообщает причину исключения, но не показывает выбранный URL, сохраните причину в index_state или evidence, а selected_canonical оставьте unknown. Одинаковое название колонки в нашей таблице не обязывает разные сервисы предоставлять одинаковый набор полей.

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

Наблюдение превращается в гипотезу

После проверки B и C должна появиться таблица, которую можно прочитать без устного пояснения автора. В ней понятны источник, время и предел каждого вывода. Начальный учебный запрет C остаётся описанием стенда; полученные на собственном сайте сведения, если вы выполняли проверку, существуют отдельно.

Для C первой рабочей гипотезой будет: «Материал предназначен для поиска, но опубликованная версия содержит запрет индексации». В next_action запишите проверку причины появления запрета в исходнике, шаблоне или настройках сервера. Не назначайте сразу исправление всего каталога: у B исходные условия другие, а его сведения служат полезной точкой сравнения.

Попробуйте самостоятельно объяснить три записи: HTTP 200 в текущей загрузке, noindex в сведениях прежнего обхода и неизвестный выбранный canonical. Из этих фактов следует необходимость сопоставить даты и текущие правила. Из них не следует, что статья уже индексируется. В следующем уроке мы разберём запрет C и противоположную задачу служебной страницы E, которую как раз не хотим включать в поиск.