WordPress Sitemap: как настроить карту сайта и проверить её обработку

В WordPress отдельный плагин для базовой XML-карты нужен не всегда. Ядро CMS поддерживает собственный механизм Sitemap начиная с WordPress 5.5 и для обычного публичного сайта формирует основной индекс по адресу /wp-sitemap.xml. В нём находятся ссылки на отдельные карты записей, страниц, таксономий и других публичных объектов сайта.

Но рабочая карта сайта — это не просто XML, который открывается в браузере. Нужно проверить три вещи: какие URL WordPress туда помещает, может ли поисковый робот стабильно получить файл и совпадает ли передаваемый набор страниц с тем, что действительно должно участвовать в поиске.

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

Начните с /wp-sitemap.xml, а не с установки ещё одного плагина

На стандартном публичном WordPress-сайте сначала стоит проверить:

https://example.com/wp-sitemap.xml

Это индекс Sitemap — файл со ссылками на более узкие карты. WordPress разбивает структуру по типам объектов, поэтому внутри могут находиться отдельные XML для записей, страниц, рубрик, меток, пользовательских типов записей или авторских архивов.

Ядро WordPress ограничивает одну такую вложенную карту 2000 URL по умолчанию. Это не ограничение протокола Sitemap, а внутренний предел WordPress, выбранный с учётом производительности. Если элементов больше, CMS создаёт следующие части автоматически.

Если на сайте установлен SEO-плагин, первым делом определите, какая карта используется фактически. Само наличие нескольких Sitemap не означает автоматическую SEO-проблему, но для диагностики должна быть понятна одна рабочая схема: какой адрес указан в robots.txt, какой отправлен в панели поисковых систем и какие URL он содержит.

Отключать встроенный механизм WordPress только ради «чистоты» тоже не требуется. Ядро предоставляет фильтр wp_sitemaps_enabled, а SEO-плагины могут заменять или расширять стандартную реализацию. Решение нужно принимать по функциональности: нужны ли исключения, специализированные типы Sitemap, удобное управление индексируемыми объектами и другие возможности.

Какие URL должны находиться в WordPress Sitemap

Главный критерий — карта должна отражать тот набор страниц, который вы считаете поисково значимым.

Проверять стоит не количество URL как таковое, а их типы.

Что обнаружили	Как оценивать
Опубликованные статьи и страницы	Обычно должны присутствовать, если предназначены для поиска
Рубрики и другие архивы	Оставлять, если это самостоятельные полезные посадочные страницы
Метки	Проверять отдельно: на некоторых проектах они полезны, на других создают слабые архивы
Авторские архивы	Нужны не каждому сайту; особенно внимательно проверять проекты с одним автором
Технические или служебные URL	Обычно им не место в поисковой карте
URL с редиректом	Лучше передавать конечный канонический адрес
Дубли одной страницы	Нужно определить предпочтительную версию и передавать её

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

Если требуется глубже разобрать формат, ограничения файла и способы его формирования, полезно отдельно пройти XML Sitemap: это уже уровень самого протокола, а не особенностей WordPress.

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

Проверяйте обработку, а не только красивый XML в браузере

То, что /wp-sitemap.xml визуально открылся, подтверждает лишь первый этап. Для технической проверки полезно пройти цепочку от ответа сервера до состояния URL в поисковой системе.

Сначала проверьте основной индекс и несколько вложенных файлов:

curl -I https://example.com/wp-sitemap.xml

Для рабочего файла ожидается обычный успешный HTTP-ответ. Отдельно убедитесь, что URL не требует авторизации, не блокируется защитой сайта для поискового робота и не попадает в цикл редиректов.

Для Яндекса это формализованное требование: Sitemap должен возвращать 200 OK; один файл может содержать не более 50 000 URL и быть не более 50 МБ в несжатом виде. Те же базовые ограничения 50 000 URL и 50 МБ действуют для Sitemap, передаваемых Google.

Следующий уровень — Google Search Console. В отчёте Sitemaps нужно отправить адрес основной карты и проверить, может ли Google получить и обработать файл. Статус успешной обработки не означает, что все перечисленные страницы будут просканированы и проиндексированы: Google отдельно указывает, что фактический обход зависит от характеристик сайта.

В Яндекс Вебмастере Sitemap можно указать в разделе файлов Sitemap или сообщить о нём через robots.txt. После добавления обработка не обязательно происходит мгновенно: документация Яндекса предупреждает, что файл может находиться в очереди до двух недель.

Если проект использует индекс из нескольких карт, полезно понимать его устройство отдельно — разбор Sitemap Index помогает отличить ошибку главного файла от проблемы одной вложенной карты.

lastmod полезен только тогда, когда дата соответствует реальному изменению

В современных версиях WordPress ядро добавляет lastmod для отдельных записей и главной страницы Sitemap. Эта возможность появилась в WordPress 6.5.

Сам тег полезен не потому, что «свежая дата улучшает SEO». Его задача — сообщить о существенном обновлении URL.

Google прямо указывает, что использует lastmod, если значение стабильно соответствует реальности. Изменение основного текста, структурированных данных или значимых ссылок можно считать существенным обновлением; изменение даты в подвале — нет. При этом значения priority и changefreq Google игнорирует.

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

Ошибка Sitemap часто находится не в Sitemap

Типичный сценарий: карта успешно открывается, Search Console показывает успешную обработку, но часть URL всё равно не индексируется.

В этом случае бессмысленно бесконечно пересоздавать XML. Для каждого проблемного URL нужно последовательно проверить:

1. страница возвращает 200 OK;
2. она доступна поисковому роботу;
3. на странице нет случайного noindex;
4. rel="canonical" указывает на ожидаемый адрес;
5. URL не является дублем другой страницы;
6. на страницу ведут нормальные внутренние ссылки;
7. сама страница содержит самостоятельный материал, оправдывающий её присутствие в поиске.

Sitemap отвечает в первую очередь на вопрос «какие URL сайта стоит обнаружить». Решение о сканировании, выборе канонической версии и индексировании поисковая система принимает отдельно.

Визуал 4. Корректный Sitemap и ложная проблема Sitemap

Если технические проблемы Sitemap регулярно сочетаются с дублями, ошибками каноникализации, слабой внутренней связностью и большим числом лишних индексируемых URL, задача выходит за рамки настройки одного XML-файла. В таком случае SEO-продвижение сайта с техническим аудитом уместно рассматривать как комплексную работу: карта сайта становится одним из проверяемых элементов наряду с обходом, индексированием и архитектурой.

Практический сценарий: после миграции в Sitemap остались неправильные URL

Представим сайт на WordPress, который перевели с HTTP на HTTPS и одновременно изменили часть структуры постоянных ссылок. Новый Sitemap открывается, но внутри выборочной проверки обнаруживаются старые адреса и страницы с переходами через редирект.

Исправлять только XML вручную здесь не стоит. Если карту генерирует WordPress или SEO-плагин, сначала нужно найти источник неправильного URL: старые настройки адреса сайта, ошибочные записи в базе, неверную каноникализацию или отдельный генератор Sitemap.

После исправления достаточно проверить небольшой репрезентативный набор:

Проверка	Нормальный результат
Главный Sitemap	200 OK
Вложенные Sitemap	открываются без авторизации и ошибок
URL внутри	сразу используют актуальный HTTPS-адрес
Редиректы	в Sitemap нет старых промежуточных URL
Canonical	совпадает с предпочтительным адресом
Search Console	Sitemap успешно получен и обработан
Яндекс Вебмастер	файл принят без критических ошибок

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

Когда стандартного WordPress Sitemap достаточно

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

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

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