Подключение Яндекс Вебмастера и чтение первых отчётов

После подключения Google Search Console у нас появилась одна точка наблюдения за библиотекой. Теперь добавим Яндекс Вебмастер. Важные страницы будем искать по тому же реестру A–H, но сведения Яндекса сохраним отдельно: решение одной поисковой системы не описывает состояние другой.

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

Адрес сайта и права доступа

Войдите в Яндекс Вебмастер со своим Яндекс ID. При добавлении сайта укажите адрес с выбранным протоколом и вариантом www: например, https://example.com. В нашей серии этот домен служит только вымышленным учебным примером. Для подключения нужен собственный сайт. Добавление в сервис само по себе не гарантирует появления в поиске. Быстрый старт в Яндекс Вебмастере.

Сравните адрес с записью из предыдущего урока. Если реальная библиотека находится на HTTPS без www, начните с этого же варианта. Сохранённый урок B, новая статья C и каталог D должны относиться к исследуемому сайту. Не выбирайте другой вариант адреса только потому, что он первым попался в истории браузера: это усложнит сопоставление наблюдений.

Не переносите модель доменного ресурса Google в интерфейс Яндекса автоматически. Здесь важно сохранить точный адрес добавленного сайта. В рабочей заметке seo-audit/access-notes.md добавим второй блок. Показанные значения — пример структуры, а фактический статус заполните по результату своей работы:

## Яндекс Вебмастер

- Сайт: https://example.com
- Назначение: диагностика тех же A–H
- Способ подтверждения: пока не выбран
- Источник подтверждения в проекте: пока не определён
- Статус доступа: пока не подтверждён

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

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

Сохранение подтверждения в проекте

Яндекс позволяет подтвердить сайт HTML-файлом в корне, метатегом в head главной страницы или TXT-записью DNS. Имя файла и содержимое, строку метатега либо значение записи берите из своей страницы подтверждения. Файл должен содержать выданный код без дополнительного оформления. Сервис периодически повторно проверяет подтверждение; если оно исчезнет, права могут стать неподтверждёнными. Подтверждение прав на сайт.

Продолжим вариант с файлом из предыдущего урока. Пусть Яндекс выдал условное имя yandex_1234567890abcdef.html. Добавим файл в источник статических ресурсов рядом с файлом Google. Здесь показано расположение; учебные имена не заменяют выданные вам файлы:

site-project/
├── public/
│   ├── google1234567890abcdef.html
│   └── yandex_1234567890abcdef.html
└── dist/
    ├── google1234567890abcdef.html
    └── yandex_1234567890abcdef.html

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

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

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

<head>
  <meta charset="utf-8">
  <meta name="google-site-verification" content="YOUR_GOOGLE_TOKEN">
  <meta name="yandex-verification" content="YOUR_YANDEX_TOKEN">
  <title>Учебная библиотека</title>
</head>

Это фрагмент для объяснения. Скопируйте действительные метатеги каждого сервиса, а затем посмотрите исходный HTML опубликованной главной страницы. Поиск текста в Markdown-файле не доказывает правильное расположение тега в итоговом документе. Точно так же просмотр красивой страницы в браузере не показывает невидимые метаданные.

DNS-вариант зависит от зоны домена, а не от папки dist. В рабочей заметке сохраните место управления зоной и назначение записи. При смене хостинга, генератора или DNS-провайдера эти зависимости затрагиваются по-разному: новые шаблоны должны сохранять метатеги, новые правила публикации — файлы, а новая зона — нужные записи. Поэтому запись «подтверждено» полезно дополнить объяснением, за счёт чего именно действует подтверждение.

Если подключение не удаётся, сопоставьте выбранный адрес, опубликованный результат и аккаунт. Например, файл присутствует в локальной сборке, но на сервер отправлена предыдущая версия. Или метатег добавлен на страницу другого поддомена. Если сайт использует IPv4 и IPv6, оба направления тоже должны отдавать корректный результат — это отдельно отмечено в инструкции Яндекса. Проверка подтверждения.

Отчёты об обходе и участии в поиске

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

«Статистика обхода» сообщает об обращениях робота: адресе страницы, дате обхода и полученном HTTP-коде. Эти сведения позволяют найти неудачные загрузки и сравнивать ответы при посещениях. В документации описана возможность выгрузки с учётом фильтров в CSV или XLS. Статистика обхода.

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

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

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

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

Текущая проверка и даты

Для исследования URL документация Яндекса описывает «Проверку страницы». В ней рассматриваются ответ, содержимое для робота и состояние страницы; для страниц с JavaScript упомянут отдельный инструмент рендеринга. Читайте назначение выбранного результата, а не только заголовок экрана: сведения о поисковом состоянии и текущей загрузке могут относиться к разным событиям. Проверка страницы.

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

Рассмотрим, как сохранить эти данные в seo-audit/observations.csv. Используем уже заданные поля: url_id, checked_at, engine, check_type, HTTP-код, разрешения, канонические сведения, состояние, доказательство и следующее действие. Для Яндекса engine всегда равен yandex. Дальше тип записи определяется фактическим источником:

Полученное сведение	check_type	Что сохранить в evidence
Запись из истории обхода	indexed_report	Название отчёта, дата обхода, полученный код
Состояние из «Страниц в поиске»	indexed_report	Статус и даты, показанные сервисом
Результат текущего запроса инструмента	live_test	Название инструмента, робот и наблюдаемый ответ

Здесь indexed_report — общее название группы сохранённых отчётных данных в таблице курса. Оно не означает, что всякая строка этой группы подтверждает включение страницы в индекс. Для истории обхода поле index_state останется unknown, если источник не содержит сведений об участии в поиске.

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

То же правило применим к каноническим адресам. declared_canonical описывает указание сайта. selected_canonical заполняем только когда источник явно сообщает выбранный адрес и позволяет понять его значение. Не нужно копировать в это поле наш тег canonical ради заполненной таблицы. Если интерфейс Яндекса не показывает выбранный канонический адрес, как Google Search Console, оставьте unknown и сохраните доступную формулировку состояния.

Один реестр, два независимых источника

Теперь для B и C можно собирать сведения каждого поисковика, не меняя учебные адреса и их назначение. Вопросы совпадают, но источники, даты и решения будут отдельными. Если Google сообщает одно состояние, а Яндекс другое, начните с дат, вариантов адреса и типа проверки. Не усредняйте два состояния и не выбирайте удобное сообщение как окончательный результат.

В рабочей заметке должны появиться фактический статус доступа к Яндексу и место хранения подтверждения. В таблице наблюдений — только полученные сведения. Фикстуры A–H сохраняются отдельно, данные поисковиков не подставляются вместо них.

Такой результат позволяет перейти от общего знакомства с панелями к предметной диагностике. Далее возьмём исправный по условиям сценария старый урок B и проблемную новую статью C, разберём их отчёты и отдельно сопоставим их с текущим состоянием страниц.