Если XML-карта сайта в WordPress есть, но в Search Console появляются ошибки, это почти всегда не проблема самой карты, а несостыковка между тем, что сайт отдаёт в sitemap, и тем, что реально доступно для индексации. Типичный сценарий: в карте остаются старые записи, вложения, таксономии или страницы, которые уже удалены, закрыты от индексации или отдают 404.
Разбирать это лучше не “на глаз”, а по цепочке: сначала понять, какие URL попали в sitemap, потом проверить их ответ сервера, затем посмотреть, кто именно формирует карту — ядро WordPress, SEO-плагин или кастомный код.
Когда проблема действительно в XML-карте сайта
Не каждая ошибка в Search Console означает, что sitemap сломан. Иногда Google просто показывает URL, найденные по внутренним ссылкам или старым внешним ссылкам. Но если в отчёте по карте сайта вы видите массовые 404, перенаправления или URL, которые не должны индексироваться, это уже рабочая задача.
Признаки, что нужно лезть в sitemap
- в карте есть URL удалённых записей или страниц;
- в sitemap попадают архивы тегов, авторов, дат, хотя они закрыты noindex;
- внутри карты есть URL с редиректом на другой адрес;
- в Search Console растёт число “Не найдено (404)” именно по URL из sitemap;
- после миграции сайта карта продолжает отдавать старые домены или пути.
Диагностика: что проверить до правки кода
Сначала нужно понять, где именно генерируется карта. В WordPress это может быть:
- встроенная XML-карта ядра;
- SEO-плагин, например Yoast SEO, Rank Math или похожий;
- кастомный endpoint в теме или плагине;
- остатки старого плагина, который уже отключили, но кэш ещё отдаёт старую карту.
Проверка простая:
- Откройте
/wp-sitemap.xml— это карта ядра WordPress. - Если используется SEO-плагин, проверьте его sitemap-адрес, например
/sitemap_index.xml. - Сравните список URL в карте с реальными страницами сайта.
- Проверьте проблемные URL через браузер или
curl -I, чтобы увидеть статус ответа.
curl -I https://example.com/old-page/Если URL из sitemap отдаёт 301 или 404, это уже повод исправлять генерацию карты, а не только редиректы.
Как исправить карту сайта в WordPress: рабочие подходы
Есть три нормальных варианта: настроить плагин, исключить проблемные типы контента через код или отключить встроенную карту и оставить один источник правды. Выбор зависит от того, кто сейчас управляет sitemap и насколько сложная структура сайта.
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Настройка SEO-плагина | Если sitemap генерирует Yoast, Rank Math или аналог | Без кода, быстро | Не всегда решает кастомные исключения |
| Фильтрация через код | Если нужно убрать отдельные записи, таксономии или типы постов | Точный контроль | Нужно поддерживать код при обновлениях |
| Отключение лишнего генератора | Если на сайте два sitemap-источника одновременно | Убирает дубли и путаницу | Нужно проверить, какой sitemap останется основным |
Вариант 1: убрать лишние типы контента из встроенной карты WordPress
Если вы используете встроенный sitemap ядра, можно отключить отдельные типы записей, таксономии или авторов. Для этого подходят фильтры wp_sitemaps_post_types, wp_sitemaps_taxonomies и wp_sitemaps_users.
add_filter('wp_sitemaps_post_types', function ($post_types) {
unset($post_types['attachment']); // вложения часто не нужны в sitemap
return $post_types;
});
add_filter('wp_sitemaps_taxonomies', function ($taxonomies) {
unset($taxonomies['post_tag']); // если теги закрыты или не нужны в индексации
return $taxonomies;
});
add_filter('wp_sitemaps_users', '__return_false'); // если архивы авторов не нужныЭтот вариант полезен, когда проблема не в отдельных URL, а в целых группах страниц. Например, на новостном сайте часто не нужны вложения и архивы авторов, если они пустые или дублируют контент.
Вариант 2: исключить конкретные записи из sitemap
Если нужно убрать только отдельные страницы, удобнее использовать фильтр wp_sitemaps_posts_query_args. Он позволяет исключить записи по ID, статусу или другим параметрам запроса.
add_filter('wp_sitemaps_posts_query_args', function ($args, $post_type) {
if ($post_type === 'post') {
$args['post__not_in'] = array(123, 456); // ID страниц, которые не должны попадать в sitemap
}
return $args;
}, 10, 2);Такой способ пригодится после миграции, когда часть старых материалов уже закрыта, но ещё не удалена из базы. Важно не подменять этим noindex: карта сайта и индексация — разные механизмы.
Вариант 3: отключить встроенную карту, если её уже заменяет SEO-плагин
Если на сайте работает SEO-плагин со своей картой сайта, держать одновременно и ядро WordPress, и плагин обычно не нужно. Две карты не всегда ломают сайт, но создают путаницу при проверке индексации и могут дублировать URL в отчётах.
add_filter('wp_sitemaps_enabled', '__return_false');Перед отключением убедитесь, что SEO-плагин действительно отдаёт рабочий sitemap и он указан в robots.txt или уже отправлен в Search Console.
Проверка результата после внедрения
После правки не ограничивайтесь открытием страницы в браузере. Нужно проверить и сам XML, и HTTP-ответы, и то, как карта видна поисковику.
- Откройте sitemap в браузере и убедитесь, что в нём нет лишних URL.
- Проверьте проблемные адреса через
curl -Iили любой HTTP-клиент. - Посмотрите исходный XML: там не должно быть редиректов и 404-ссылок.
- В Search Console отправьте карту повторно и дождитесь обновления отчёта.
Полезно проверить и сам XML на уровне ответа сервера:
curl -I https://example.com/wp-sitemap.xml
curl https://example.com/wp-sitemap.xml | head -n 20Если карта отдаёт 200 OK, но внутри остались старые URL, значит проблема не в доступности файла, а в логике генерации.
Частые ошибки и как их исправить
В sitemap остаются URL после удаления записи
Это бывает, если карта кэшируется плагином, сервером или CDN. Сначала очистите кэш, потом проверьте, не хранится ли sitemap в отдельном кэширующем слое. Если URL всё равно есть, ищите источник генерации.
В карту попадают страницы с noindex
Это частая ошибка настройки SEO-плагина: страница закрыта от индексации, но всё ещё включена в sitemap. В норме такие URL лучше убрать из карты, чтобы не создавать противоречие для поисковика.
Есть два sitemap одновременно
Например, /wp-sitemap.xml и /sitemap_index.xml. Это не всегда критично, но почти всегда мешает диагностике. Оставьте один основной источник и проверьте, что именно он указан в robots.txt.
Редирект вместо прямого URL
Если в sitemap попал адрес, который уже переехал, поисковик сначала тратит обход на редирект. Для небольшого сайта это не катастрофа, но на большом проекте лучше сразу обновить карту и убрать промежуточный URL.
Чек-лист перед отправкой карты в Search Console
- в sitemap нет 404 и 301 URL;
- в карту не попадают закрытые noindex-страницы;
- нет дублей между ядром WordPress и SEO-плагином;
- после правки очищен кэш сайта и CDN;
- robots.txt ссылается только на актуальную карту;
- в Search Console отправлен именно тот sitemap, который реально используется.
Безопасность и производительность
Если sitemap генерируется динамически на большом сайте, следите за нагрузкой. Постоянные запросы к тяжёлым картам могут создавать лишнюю работу для PHP и базы данных. В таких случаях помогает нормальный кэш страницы карты или переход на более предсказуемую генерацию через SEO-плагин.
С точки зрения безопасности не стоит открывать в sitemap служебные или приватные URL только потому, что они “технически доступны”. Карта сайта — это публичный список страниц, и всё, что туда попадает, должно быть осознанно пригодно для обхода поисковиком.
Если нужен более широкий контроль над дублями, архивами и технической чисткой сайта, иногда удобнее вынести это в отдельный SEO-инструмент вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае сначала проверьте, кто именно формирует sitemap, чтобы не лечить не тот слой.
Когда карта сайта приведена в порядок, Search Console обычно начинает показывать более понятную картину: меньше мусорных URL, меньше ложных ошибок и меньше времени на разбор того, что на самом деле уже давно не существует.