Проверка Sitemap и большого каталога

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

Продолжим вымышленный учебный сценарий на https://example.com. Значения ниже относятся к нашему стенду, а не к результатам обследования действующего ProfessorWeb. На настоящем сайте мы используем знакомый принцип: старый урок сохраняет адрес, а новое оглавление ссылается на него. В этом уроке получим согласованную карту из четырёх адресов и добавим статью C в каталог D.

Что именно сравнивать

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

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

Начнём с нашего реестра A–H. В начале серии карта содержала A, B, C, D, F и H. Адрес E был исключён намеренно, G не добавлялся. После исправлений из предыдущих уроков ожидаем следующее состояние. Таблица описывает учебный результат, который в своей работе необходимо подтвердить наблюдениями.

ID	Состояние после прежних исправлений	Место в исправленной Sitemap
A	Главная, 200, индексирование разрешено, canonical на себя	Включить
B	Сохранённый урок, 200, индексирование разрешено, canonical на себя	Включить по старому адресу `.php`
C	Новая статья, 200, ошибочный `noindex` снят, canonical на себя	Оставить, добавить ссылку из D
D	Общий каталог, 200, canonical на себя	Включить
E	Служебный поиск с `noindex`, доступный роботу для чтения запрета	Не включать
F	Удалённая страница, теперь возвращает 404	Удалить из карты
G	Вариант B с параметром, заявленный canonical указывает на B	Не включать
H	Один постоянный редирект непосредственно на B	Удалить из карты, предлагать B

Обратите внимание: число записей уменьшается с шести до четырёх, но полезных материалов не становится меньше. Мы перестаём предлагать удалённый адрес F и перенаправляющий адрес H. Поэтому количество строк в Sitemap нельзя использовать как самостоятельную меру полноты библиотеки.

Для каждого материала полезно задать два разных вопроса. Первый: «Есть ли его основной адрес в карте?» Второй: «Есть ли путь к нему через страницы сайта?» В нашем примере C уже была в Sitemap, но не имела обычных внутренних ссылок. Если проверять только XML, эта проблема останется незамеченной.

Четыре основных адреса в карте

Откройте Sitemap и сравнивайте полные значения loc с реестром, а не только последние части путей. Схема https, имя домена, регистр символов в пути и завершающий слеш относятся к конкретному адресу. Для B важно сохранить /my/LINQ/linq_xml/level7/7_1.php, а не автоматически построить новый путь по названию раздела.

Google рекомендует указывать в Sitemap абсолютные адреса и выбирать предпочтительные канонические URL. Один файл ограничен 50 000 URL и 50 МБ в несжатом виде. Для будущей библиотеки из 20 тысяч страниц лимит числа URL ещё не достигнут, но размер файла также нужно учитывать. Эти требования приведены в правилах создания Sitemap.

Полный учебный XML-файл после отбора выглядит так:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
  </url>
  <url>
    <loc>https://example.com/my/LINQ/linq_xml/level7/7_1.php</loc>
  </url>
  <url>
    <loc>https://example.com/articles/markdown-guide.html</loc>
  </url>
  <url>
    <loc>https://example.com/catalog/</loc>
  </url>
</urlset>

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

Мы также не добавили lastmod: в учебных данных нет дат содержательных обновлений. Если генератор знает такие даты, их можно передавать. Подставлять сегодняшнюю дату ко всем страницам при каждой сборке не следует: Google использует lastmod, когда он последовательно соответствует существенным изменениям страницы. Значения priority и changefreq Google игнорирует. Пояснения к XML Sitemap.

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

Добавление статьи в каталог

Теперь откроем D: /catalog/. В исходном состоянии там была ссылка на B, но C отсутствовала. Добавим второй материал, сохранив прежнюю ссылку. В общем каталоге старые уроки и новые статьи могут находиться в разных тематических ветках; в нашем маленьком стенде достаточно показать обе ссылки.

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

<ul>
  <li>
    <a href="/my/LINQ/linq_xml/level7/7_1.php">Запросы LINQ to XML</a>
  </li>
  <li>
    <a href="/articles/markdown-guide.html">Статический сайт из Markdown</a>
  </li>
</ul>

Ссылка на C начинается с /, поэтому разрешается от корня сайта. Для папочного адреса D это удобно: путь не превращается случайно в /catalog/articles/markdown-guide.html. У B сохраняются исходный регистр каталогов и окончание .php.

Ожидаемый результат теперь можно сформулировать без предположений об индексе: с главной A читатель переходит в D, а из D открывает C. В нашей таблице наблюдений ссылка из каталога подтверждает доступность маршрута навигации. Поле index_state при этом остаётся unknown, пока не получен соответствующий отчёт поисковой системы.

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

При переносе ProfessorWeb нам было важно отделить адрес статьи от её положения в каталоге. Этот же приём помогает при расширении библиотеки: перенос материала в другую рубрику меняет ссылки оглавлений, но не требует нового URL для самой статьи.

Папочные адреса и продолжение списков

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

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

Google рекомендует связывать страницы пагинации обычными ссылками и давать каждой собственный URL. Для страниц с разными частями списка не следует назначать первую страницу единственным canonical всей последовательности. Google также не использует фрагменты вида #page=2 как разные адреса для такой задачи. Рекомендации по пагинации.

Рассмотрим ошибочный вариант: новый материал расположен на второй странице, но кнопка «Далее» только заменяет список JavaScript-кодом, а соответствующей ссылки в HTML нет. Визуально каталог кажется исправным. Чтобы обнаружить разрыв, проверяйте адрес перехода и наличие обычного href, а не только изменение экрана. Это полезно и для пользователя, который открывает следующую страницу в отдельной вкладке.

Страница, доступная по папочному адресу, тоже требует точной записи. Если сервер переводит /catalog на вариант со слешем, в навигации и карте используйте конечный выбранный адрес. Существование редиректа удобно для посетителя, но не повод намеренно добавлять промежуточный вариант во все внутренние ссылки.

Что подтверждает обработка карты

После размещения исправленной карты смотрите её состояние в инструментах поисковиков. В Search Console отчёт Sitemaps помогает увидеть получение файла и ошибки обработки. Принятие карты остаётся отдельным наблюдением: оно не заменяет сведения о каждом URL. Передача Sitemap Google.

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

В журнале изменений разделите две записи: удаление F и H из карты и добавление C в D. У них разные ожидаемые наблюдения. Для первой — XML содержит только A, B, C, D. Для второй — HTML каталога содержит рабочую ссылку на C. Состояние карты в инструменте и состояние статьи в индексе запишите отдельно, с собственной датой получения.

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