Открытые XML sitemap сами по себе не проблема. Проблема начинается, когда в индексе и в Search Console одновременно живут несколько карт сайта: от темы, от SEO-плагина, от старого плагина кэша, от мультиязычности или от тестовой среды. В итоге поисковик тратит краулинговый бюджет на мусорные URL, а вы получаете дубли и путаницу в отчетах.
Ниже — рабочий сценарий: как понять, какие sitemap реально отдаются, как убрать лишние, и как проверить, что после правки ничего не сломалось.
Когда это вообще нужно
Закрывать нужно не все sitemap подряд, а только те, которые не должны участвовать в обходе и индексации. Типичные случаи:
- на сайте остался sitemap от старого плагина, хотя сейчас работает другой генератор;
- тема или плагин отдают отдельный sitemap для вложений, авторов, тегов или кастомных типов записей, которые вы не хотите индексировать;
- в корне доступны и
/sitemap.xml, и/sitemap_index.xml, и оба ведут на разные наборы URL; - в sitemap попадают служебные страницы, тестовые записи, архивы без ценности;
- поисковик видит sitemap на staging-домене или в копии сайта.
Диагностика: что именно открыто
Сначала не правьте код вслепую. Проверьте, какие карты сайта реально доступны из браузера и по HTTP.
1. Посмотрите список sitemap вручную
Откройте в браузере адреса, которые чаще всего встречаются в WordPress:
/sitemap.xml/sitemap_index.xml/post-sitemap.xml/page-sitemap.xml/category-sitemap.xml
Если сайт использует SEO-плагин, у него может быть свой индекс sitemap. Если открывается сразу несколько вариантов, это уже повод разобраться, какой из них должен остаться.
2. Проверьте заголовки ответа
Иногда sitemap не закрыт от индексации, а просто отдает неправильный статус или редиректит не туда. Удобно проверить через curl:
curl -I https://example.com/sitemap.xmlСмотрите на три вещи: код ответа, конечный URL после редиректа и тип контента. Для XML-карты сайта обычно нужен 200 OK и XML-ответ, а не HTML-страница с ошибкой или редирект на главную.
3. Найдите источник генерации
В WordPress sitemap может генерировать:
- ядро WordPress;
- SEO-плагин;
- отдельный плагин для XML-карт;
- тема, если разработчик добавил свою реализацию;
- кастомный код в
functions.phpили mu-plugin.
Если на сайте стоит SEO-плагин, сначала проверьте его настройки. Часто лишний sitemap проще отключить в интерфейсе, чем потом ловить конфликт в коде.
Как закрыть лишние sitemap: рабочие варианты
Есть три нормальных подхода: отключить генерацию в плагине, убрать лишний endpoint кодом или закрыть конкретный sitemap через редирект/404, если он больше не нужен. Выбор зависит от того, кто именно его создает.
| Способ | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Настройки плагина | Если sitemap создает SEO-плагин | Без кода, меньше риска | Не всегда есть нужная гранулярность |
| Код в теме или mu-plugin | Если sitemap отдает тема или кастомный код | Точно контролируете поведение | Нужно аккуратно тестировать |
| Редирект/404 | Если старый sitemap уже не нужен | Быстро убирает мусорный URL | Нужно не задеть актуальный sitemap |
Вариант 1. Отключить лишнее в SEO-плагине
Если у вас Yoast SEO, Rank Math или похожий плагин, начните с настроек XML sitemap. Обычно там можно отключить:
- архивы авторов;
- теги;
- отдельные таксономии;
- медиа-вложения;
- кастомные типы записей.
Это безопаснее, чем править роутинг вручную. После сохранения настроек проверьте, что старый sitemap больше не открывается или не содержит лишние URL.
Вариант 2. Убрать sitemap, который генерирует ядро WordPress
Если вы используете собственный генератор sitemap или SEO-плагин, встроенный sitemap ядра может быть лишним. Его можно отключить фильтром wp_sitemaps_enabled. Добавьте код в functions.php дочерней темы или в отдельный mu-plugin:
<?php
add_filter( 'wp_sitemaps_enabled', '__return_false' );Этот вариант подходит, когда вы точно знаете, что другой sitemap уже работает и именно он должен остаться единственным.
Вариант 3. Закрыть конкретный sitemap через редирект
Если старый адрес уже индексировался и вы хотите мягко убрать его из обхода, можно сделать 301 на актуальный sitemap. Делайте так только если новый адрес действительно заменяет старый.
<?php
add_action( 'template_redirect', function () {
if ( isset( $_SERVER['REQUEST_URI'] ) && $_SERVER['REQUEST_URI'] === '/sitemap.xml' ) {
wp_redirect( home_url( '/sitemap_index.xml' ), 301 );
exit;
}
} );Если старый sitemap не должен существовать вообще, иногда лучше отдать 404 или 410, но это уже зависит от того, успел ли он попасть в индекс и есть ли на него внешние ссылки.
Чек-лист перед публикацией изменений
- Поняли, какой sitemap должен остаться основным.
- Проверили, кто именно его генерирует: ядро, плагин, тема, кастомный код.
- Отключили лишние типы URL в настройках, а не только спрятали их от глаз.
- Убедились, что актуальный sitemap отдает
200 OK. - Проверили, что старый sitemap либо редиректит на новый, либо закрыт корректно.
- Обновили ссылки на sitemap в Search Console, если менялся основной адрес.
Как проверить, что решение сработало
После правки не ограничивайтесь визуальной проверкой. Нужны технические признаки, что все работает как задумано.
Проверка в браузере и через curl
Откройте актуальный sitemap и убедитесь, что он показывает XML-структуру, а не HTML-страницу ошибки. Затем проверьте заголовки:
curl -I https://example.com/sitemap_index.xml
curl -I https://example.com/sitemap.xmlЕсли старый адрес должен исчезнуть, он не должен отдавать 200 с тем же содержимым, что и раньше.
Проверка в Google Search Console
В отчете по sitemap посмотрите:
- какой адрес добавлен;
- есть ли ошибки загрузки;
- не растет ли число обнаруженных URL из старых карт сайта;
- не появились ли предупреждения о недоступности файла.
Если вы закрывали лишние карты сайта, изменения не всегда видны мгновенно. Но после повторного обхода старые адреса должны постепенно исчезать из отчетов.
Проверка логов сервера
Если есть доступ к логам, посмотрите запросы к sitemap за последние дни. Это помогает понять, не ходят ли боты по старому адресу и не получают ли массово 404 или редиректы.
Частые ошибки и как их исправить
Отключили не тот sitemap
Иногда администратор отключает встроенный sitemap WordPress, а потом обнаруживает, что SEO-плагин тоже был выключен. В итоге сайт остается вообще без карты. Исправление простое: сначала проверьте, какой адрес реально используется поисковиками, и только потом отключайте лишнее.
Редирект ведет на HTML-страницу
Если /sitemap.xml редиректит на главную или на страницу с ошибкой, поисковик может считать это некорректной заменой. Редирект должен вести на действующий sitemap, а не на произвольный URL.
В sitemap остались закрытые от индексации страницы
Это частая проблема после настройки noindex. Страница может быть закрыта от индексации, но все еще попадать в sitemap. Поисковик получает противоречивый сигнал. Нужно убрать такие URL из генерации sitemap, а не только ставить мета-тег.
Старый sitemap продолжает отдаваться из кэша
После изменений очистите серверный кэш, плагин кэша и CDN, если он есть. Иначе вы будете проверять уже не текущую конфигурацию, а старую копию ответа.
Безопасность и производительность
XML sitemap — это не тяжелая часть сайта, но ошибки в ней бьют по краулингу и по диагностике. Поэтому лучше держать генерацию в одном месте и не плодить несколько решений одновременно.
- Не оставляйте одновременно ядровой sitemap и sitemap от SEO-плагина, если они дублируют друг друга.
- Не закрывайте sitemap через robots.txt, если сам файл должен быть доступен поисковику для обхода.
- Не прячьте проблему только через
noindex— лишний URL все равно может попасть в карту сайта. - Если используете кастомный код, держите его в дочерней теме или mu-plugin, а не в случайном сниппете без контроля версий.
Если нужно быстро навести порядок в дублях, служебных страницах и технических настройках WordPress, иногда удобнее использовать инструменты вроде Clearfy Pro: он помогает убрать лишние элементы и сократить количество технического мусора без ручного поиска по десяткам настроек. Но даже с плагином логику sitemap все равно стоит проверять вручную.
Короткий рабочий сценарий
- Определите основной sitemap.
- Найдите источник генерации.
- Отключите лишние типы URL в настройках или кодом.
- Старый адрес либо редиректите на новый, либо убирайте из обращения.
- Проверьте HTTP-ответ, содержимое XML и отчеты в Search Console.
Если после этого в индексе все еще остаются старые карты сайта, проблема обычно не в WordPress как таковом, а в кэше, CDN или в том, что где-то осталась вторая точка генерации. В таких случаях помогает не «еще один плагин», а точная проверка источника ответа.