Как поисковик находит и индексирует страницы

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

В этой серии рассмотрим диагностику большой библиотеки. Начнём с небольшой группы адресов, чтобы научиться формулировать проблему точно. После первого урока у вас будет реестр страниц и таблица вопросов, на которые предстоит ответить. Далее подключим инструменты Google и Яндекса, исследуем отдельные URL и постепенно исправим учебный сайт.

От адреса до результата поиска

Удобно различать четыре события: обнаружение адреса, обход страницы, индексирование и показ в ответ на запрос. Обнаружение означает, что поисковая система узнала о URL. Обход — что робот обращается к серверу за содержимым. При индексировании система анализирует полученные материалы, а при показе подбирает результаты к запросу пользователя. Google описывает обнаружение внутри этапа сканирования; здесь мы выделяем его отдельно, чтобы точнее находить препятствие. Как работает Google Поиск.

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

Эти различия можно представить как цепочку вопросов:

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

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

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

Библиотека из восьми адресов

Для примеров будем использовать https://example.com и локальную папку seo-audit. Все состояния этого сайта в курсе — вымышленный учебный сценарий. Это не выгрузка отчётов ProfessorWeb и не результат проверки домена example.com. Для самостоятельной работы вы замените домен своим сайтом, к которому у вас есть разрешённый доступ.

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

Создайте таблицу адресов seo-audit/urls.csv. Первые три столбца можно заполнить так:

url_id,url,purpose
A,https://example.com/,Главная
B,https://example.com/my/LINQ/linq_xml/level7/7_1.php,Сохранённый урок
C,https://example.com/articles/markdown-guide.html,Новая статья
D,https://example.com/catalog/,Общий каталог
E,https://example.com/search/?q=xml,Служебный поиск
F,https://example.com/articles/removed-example.html,Удалённый материал
G,https://example.com/my/LINQ/linq_xml/level7/7_1.php?from=menu,Вариант адреса B
H,https://example.com/old/xml-queries.html,Прежний адрес материала B

Обратите внимание на B и G: адреса отличаются параметром from=menu, хотя по условиям примера содержимое одинаково. В реестре это две строки. Если убрать параметр ещё до исследования, исчезнет сам объект проверки. Поиск E тоже содержит параметр, но он изменяет запрос пользователя. Одинаковый знак вопроса в адресе не делает эти два случая одинаковыми.

Для каждого URL зададим назначение. A, B, C и D нужны читателям как самостоятельные страницы. E обслуживает поиск по библиотеке. F удалён и должен сообщать об отсутствии материала. H нужен для перехода с прежнего адреса на сохранённый урок. Реестр, следовательно, не является списком «всё должно индексироваться»: он описывает ожидаемое поведение разных объектов.

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

Что известно о сайте и что пока неизвестно

Начальные сведения сохраним отдельно в seo-audit/initial-observations.csv. Ниже дана сокращённая учебная таблица. Она описывает настройки и предполагаемые ответы сервера, а не результаты поисковых сервисов.

ID	Начальное состояние учебного сайта	Следующий вопрос
A	200, индексирование разрешено, ссылки на каталог	Что сообщает каждый поисковик?
B	200, разрешена индексация, есть ссылки и запись Sitemap	Какой адрес выбран каноническим?
C	200, ошибочный noindex, есть в Sitemap, нет обычных ссылок	Где возникает запрет и как обнаруживается статья?
D	200, есть ссылка с главной, ведёт к B, пока не ведёт к C	Какие материалы доступны через каталог?
E	200, установлен noindex, обход /search/ закрыт	Может ли робот прочитать указание на странице?
F	200 с текстом «Страница не найдена», осталась в Sitemap	Соответствует ли ответ отсутствию материала?
G	200, текст как у B, canonical указывает на G	Согласованы ли сигналы о предпочтительном адресе?
H	301 на промежуточный адрес, затем 302 на B	Нужна ли эта цепочка?

200 — HTTP-статус успешного ответа. noindex — указание не включать страницу в индекс. Canonical — заявленный предпочтительный адрес среди вариантов содержимого. Sitemap — отдельный список адресов, который владелец сообщает поисковым системам. Эти термины будем разбирать подробно по мере работы; сейчас важнее сохранить разные наблюдения в разных полях.

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

С E другая проблема: запрет обхода в robots.txt мешает роботу прочитать содержимое страницы, в котором расположен noindex. Поэтому разрешение обхода и разрешение индексирования следует записывать отдельно. Google не рекомендует использовать robots.txt как средство гарантированного исключения страницы из поиска; для этого предназначены другие способы. Ограничения robots.txt.

По F мы можем заметить несоответствие между удалённым материалом и успешным ответом. Но пока нельзя приписать Google или Яндексу определённую классификацию этой страницы. Для этого потребуется их отчёт. Формулировка «кандидат на мягкую ошибку 404» сохраняет различие между нашей гипотезой и установленным решением поисковика.

Таблица наблюдений

Создадим рабочий файл seo-audit/observations.csv по шаблону наблюдений курса. В нём одна строка соответствует одному источнику и одному типу проверки. Основные поля имеют следующий смысл:

Поле	Что записываем
url_id	Идентификатор A–H из реестра
checked_at	Дата и время получения наблюдения
engine	site, google или yandex
check_type	Учебные данные, HTTP-проверка, индексный отчёт либо текущая проверка
http_status	Ответ сервера, если известен
crawl_allowed / index_allowed	Разрешены ли обход и индексирование
declared_canonical / selected_canonical	Заявленный сайтом и выбранный системой адрес
index_state	Состояние в индексе, если оно получено
evidence	Источник, точная формулировка, дата обхода из отчёта
next_action	Следующий вопрос или действие

Неизвестное значение обозначим unknown. Для начальных демонстрационных строк используем engine=site, check_type=fixture и checked_at=not_measured: они заданы в условии, а не измерены. Пример одной такой строки:

url_id,checked_at,engine,check_type,http_status,crawl_allowed,index_allowed,declared_canonical,selected_canonical,index_state,evidence,next_action
C,not_measured,site,fixture,200,yes,no,https://example.com/articles/markdown-guide.html,unknown,unknown,Учебный сценарий: ошибочный noindex,Исследовать запрет индексирования

После получения данных Google добавим новую строку для C с engine=google и check_type=indexed_report. После текущей проверки добавим ещё одну с check_type=live_test. Не нужно перезаписывать начальный сценарий результатом инструмента: иначе исчезнет возможность сравнить исходное условие и последующее наблюдение.

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

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

В результате первого урока у нас есть восемь адресов, их назначения и список неизвестных величин. Можно уже назвать конкретные вопросы о C, E, F, G и H, не выдумывая ответов поисковиков. Следующий шаг — получить доступ к отчётам своего сайта в Google Search Console и сохранить этот доступ при последующих обновлениях.