Ситуация типовая: сайт уже давно живёт, контент менялся, часть записей удалили, часть перевели в черновики, а в XML-карте сайта по-прежнему торчат старые URL. Поисковик их видит, переходит по ним, получает 404 или редирект, а в отчётах растёт мусор. Проблема не в самой карте сайта, а в том, что WordPress и плагины SEO часто продолжают отдавать туда объекты, которые уже не должны участвовать в обходе.
Ниже разберём, как найти источник старых URL, чем отличаются варианты решения и как убрать лишнее без побочных эффектов для индексации нормальных страниц.
Когда это действительно проблема
Не каждый старый адрес в sitemap нужно срочно вычищать. Но есть несколько сценариев, где это уже технический долг:
- в sitemap попадают записи со статусом
draft,privateили удалённые страницы; - в карте остаются вложения изображений, которые не нужны в поиске;
- после массового удаления контента поисковик продолжает обходить старые URL из sitemap;
- в карте видны архивы или служебные страницы, которые вы уже закрыли от индексации, но они всё ещё отдаются в XML;
- плагин SEO кэширует sitemap и не обновляет его после изменений в контенте.
Как быстро понять, откуда берутся лишние URL
Сначала откройте sitemap в браузере и посмотрите, какие именно адреса там остались. В WordPress с современными SEO-плагинами это обычно не один файл, а индекс sitemap и набор вложенных карт. Если лишние URL идут из конкретного типа записей, причина почти всегда в настройках плагина или в фильтре, который добавляет объекты в карту сайта.
Полезно проверить и саму страницу объекта: если запись уже удалена, но в sitemap она ещё есть, значит проблема не в редиректе, а в генерации карты. Если URL живой, но не должен индексироваться, тогда нужно сначала убрать его из sitemap, а уже потом решать вопрос с noindex или редиректом.
Что делать: сравнение подходов
| Подход | Когда подходит | Минус |
|---|---|---|
| Настройки SEO-плагина | Нужно исключить целый тип контента или медиафайлы | Не всегда хватает точности |
| Фильтр в functions.php | Нужно убрать конкретные записи или вложения по логике проекта | Требует аккуратности и теста после обновлений |
| Редирект и очистка базы | URL уже удалён, но ещё всплывает в обходе | Не решает источник проблемы, только последствия |
Если задача простая, начинайте с настроек плагина. Если нужен контроль на уровне проекта, лучше использовать фильтр. Редиректы полезны, но они не заменяют корректную генерацию sitemap.
Пошаговое решение через код
Ниже пример для случаев, когда нужно убрать из XML-карты сайта отдельные записи по ID. Это рабочий вариант, если вы точно знаете, какие объекты не должны попадать в sitemap. Код можно добавить в functions.php дочерней темы или в небольшой mu-plugin.
<?php
add_filter( 'wp_sitemaps_posts_query_args', function( $args, $post_type ) {
if ( 'post' === $post_type ) {
$args['post__not_in'] = array( 123, 456, 789 );
}
if ( 'page' === $post_type ) {
$args['post__not_in'] = array( 321 );
}
return $args;
}, 10, 2 );Что делает этот код: он не ломает sitemap целиком, а только исключает конкретные записи из выборки WordPress Sitemap API. Это лучше, чем удалять URL вручную из базы или пытаться закрывать их через robots.txt.
Если нужно убрать из sitemap вложения изображений, которые не должны индексироваться как отдельные страницы, можно отключить их вывод на уровне типа записей:
<?php
add_filter( 'wp_sitemaps_post_types', function( $post_types ) {
if ( isset( $post_types['attachment'] ) ) {
unset( $post_types['attachment'] );
}
return $post_types;
} );Этот вариант уместен, если сайт не получает пользы от индексации attachment-страниц. На многих проектах они только создают шум в отчётах и дублируют основной контент.
Если sitemap генерирует SEO-плагин
У Yoast SEO, Rank Math и похожих решений логика может отличаться от нативного Sitemap API WordPress. Тогда сначала проверьте настройки самого плагина: исключение типов записей, медиа, таксономий, архивов и отдельных URL. Если плагин даёт нужную настройку — это предпочтительнее, чем писать код.
Но если плагин не даёт точечного управления, ищите его фильтры в документации. Не стоит вставлять случайные сниппеты из интернета: у SEO-плагинов часто меняются названия фильтров и структура данных.
Диагностика после изменений
После правки не ограничивайтесь визуальной проверкой в браузере. Нужно убедиться, что sitemap реально обновился и больше не отдаёт старые адреса.
- откройте sitemap в режиме инкогнито и проверьте список URL;
- сравните ответ сервера до и после изменения;
- очистите кеш плагина, сервера и CDN, если они есть;
- проверьте, не кэшируется ли XML отдельным правилом на уровне nginx или Cloudflare;
- посмотрите, не остались ли старые URL в индексе через отчёты поисковой системы.
Если сайт использует объектный кеш или page cache, изменения в sitemap могут не появиться сразу. Это частая причина ложной тревоги: код уже работает, но вы видите старую версию из кеша.
Частые ошибки и как их исправить
Удалили URL из sitemap, но забыли про редирект
Если страница уже удалена, а на неё есть внешние ссылки или внутренние переходы, одного исключения из sitemap мало. Нужен редирект на ближайшую релевантную страницу или на родительский раздел. Иначе поисковик всё равно будет тратить краулинговый бюджет на 404.
Закрыли страницу в robots.txt и думают, что проблема решена
robots.txt не удаляет URL из индекса и не гарантирует исчезновение из sitemap. Если адрес уже попал в карту сайта, его нужно убрать именно из генерации карты, а не только запретить обход.
Скрыли URL через noindex, но оставили его в sitemap
Это рабочая, но неаккуратная комбинация. Поисковик получает противоречивые сигналы: вы одновременно просите не индексировать страницу и продолжаете её рекламировать через sitemap. Лучше привести сигналы к одному сценарию.
Правят не тот источник
На проекте может быть несколько карт: нативная WordPress, карта от SEO-плагина, карта от отдельного плагина для изображений. Если вы меняете код в теме, а sitemap всё равно не меняется, сначала выясните, кто именно его генерирует.
Как проверить, что решение сработало
Проверка должна быть простой и повторяемой:
- откройте XML-карту сайта и убедитесь, что старого URL там нет;
- проверьте HTTP-ответ sitemap — он должен отдавать актуальную версию, а не кеш;
- найдите удалённый URL через поиск по sitemap-файлам и убедитесь, что он не встречается ни в одном из них;
- если URL был в индексе, отправьте его на повторную проверку в панели вебмастера и посмотрите, как меняется статус;
- через несколько дней проверьте, не вернулся ли адрес после очистки кеша или обновления плагина.
Если URL исчез из sitemap, но продолжает появляться в отчётах, значит источник уже не в карте сайта. Тогда ищите внутренние ссылки, старые редиректы, кэш или внешние страницы, которые продолжают на него ссылаться.
Что делать для безопасности и производительности
Не храните список исключений в случайном сниппете без комментариев. Через полгода никто не вспомнит, почему ID 123 и 456 были убраны из sitemap. Лучше оставить короткую пометку рядом с кодом или вынести список в отдельный массив с понятным названием.
Если исключений много, не плодите десятки фильтров в functions.php. Для проекта с постоянной поддержкой удобнее вынести логику в mu-plugin: так код не потеряется при смене темы и не зависит от редакции шаблона.
Для сайтов, где важна техническая чистота, иногда проще использовать инструменты вроде Clearfy Pro для удаления дублей и лишних страниц из SEO-контуров, но только если его настройки реально закрывают ваш сценарий. Если нужен точечный контроль по ID и типам записей, код всё равно остаётся надёжнее.
Главная мысль простая: sitemap должен показывать только те URL, которые вы действительно хотите отдавать поисковику. Всё остальное — либо исключаем на уровне генерации, либо удаляем из индекса через отдельный, понятный сценарий.