Ситуация типовая: страницу уже удалили, перевели в архив или закрыли от индексации, а она продолжает попадать в XML sitemap. Поисковик видит URL, обходит его снова и снова, а в отчётах Search Console висит мусор: «Просканировано, но не проиндексировано», «Дубликат, выбран другой канонический URL» или просто старые адреса в карте сайта.
Проблема чаще не в самом robots.txt, а в том, что sitemap генерируется автоматически и не учитывает ваши правила. Ниже разберём, как найти источник, убрать лишние URL и проверить, что WordPress больше не отдаёт их в карту сайта.
Когда проблема действительно в sitemap, а не в robots.txt
Если URL всё ещё есть в XML sitemap, поисковик получает прямой сигнал, что страница важна для обхода. Даже если вы поставили noindex, но оставили адрес в карте сайта, вы создаёте противоречивые сигналы. Для старых архивов, служебных страниц, результатов поиска и черновых разделов это почти всегда лишнее.
Признаки, что нужно править именно sitemap
- URL удалён из меню и внутренних ссылок, но остаётся в sitemap.
- В Search Console страница продолжает появляться как обнаруженная через sitemap.
- На сайте есть SEO-плагин, который генерирует карту сайта автоматически.
- Вы используете кастомные типы записей или таксономии, и часть из них уже не должна индексироваться.
Диагностика: откуда WordPress берёт лишние URL
Сначала нужно понять, кто именно формирует sitemap. В современных установках это обычно либо ядро WordPress, либо SEO-плагин. Если у вас включён XML sitemap в WordPress, адрес обычно выглядит как /wp-sitemap.xml. У плагинов структура может быть другой, но логика та же: они собирают публичные типы контента и таксономии.
Проверьте три вещи:
- Есть ли нужный URL в самой карте сайта.
- Не отдаёт ли он
200 OKвместо404или410 Gone. - Не ссылается ли на него канонический тег или внутренние ссылки.
Если страница уже удалена, но отвечает 200, сначала исправьте статус ответа. Если страница существует, но не должна индексироваться, тогда убирайте её из sitemap и ставьте корректные мета-указания.
Как убрать старые страницы из XML sitemap в WordPress
Есть два рабочих подхода: через настройки SEO-плагина или через код. Если задача касается нескольких типов контента, код обычно надёжнее: вы явно задаёте, что исключать, и не зависите от интерфейса плагина.
| Подход | Когда подходит | Минус |
|---|---|---|
| Настройки SEO-плагина | Нужно быстро скрыть тип записи или таксономию | Не всегда удобно для точечных URL |
| Код через фильтры WordPress | Нужно исключить конкретные записи или типы | Требует аккуратного тестирования |
| Удаление страницы и возврат 410 | Контент окончательно убран | Нужно следить за редиректами и ссылками |
Вариант 1: исключить тип записи из sitemap
Если старые страницы относятся к отдельному типу записи, проще убрать весь тип из карты сайта. Для ядра WordPress можно использовать фильтр wp_sitemaps_post_types.
add_filter( 'wp_sitemaps_post_types', function( $post_types ) {
// Убираем служебный тип записи из XML sitemap.
unset( $post_types['landing_page'] );
return $post_types;
} );Этот вариант подходит, если тип записи не должен индексироваться вообще. Если же часть записей нужна в поиске, а часть нет, лучше фильтровать точечно.
Вариант 2: исключить конкретные записи
Для точечного удаления URL из sitemap используйте фильтр wp_sitemaps_posts_query_args. Он позволяет изменить запрос, который собирает записи для карты сайта.
add_filter( 'wp_sitemaps_posts_query_args', function( $args, $post_type ) {
if ( 'post' !== $post_type ) {
return $args;
}
$args['post__not_in'] = array( 123, 456, 789 );
return $args;
}, 10, 2 );Здесь 123, 456 и 789 — ID старых записей, которые не должны попадать в sitemap. Перед внедрением проверьте, что эти ID действительно относятся к нужным URL.
Вариант 3: исключить таксономии или архивы
Если проблема в архивных страницах рубрик, тегов или пользовательских таксономий, можно убрать их из sitemap целиком. Для таксономий используется фильтр wp_sitemaps_taxonomies.
add_filter( 'wp_sitemaps_taxonomies', function( $taxonomies ) {
unset( $taxonomies['post_tag'] );
unset( $taxonomies['old_section'] );
return $taxonomies;
} );Это полезно, когда архивы не несут самостоятельной ценности и только создают дубли. Но если таксономия реально даёт поисковый трафик, не отключайте её без анализа.
Что делать, если страница должна исчезнуть совсем
Если URL больше не нужен, одного удаления из sitemap недостаточно. Поисковик может продолжать обходить адрес по старым ссылкам. В таком случае лучше вернуть корректный статус ответа и, при необходимости, настроить редирект на релевантную страницу.
Удалённый контент: 410 вместо 404
Для окончательно удалённых страниц статус 410 Gone обычно понятнее, чем обычный 404. Он говорит, что адрес удалён намеренно и не вернётся. В WordPress это можно сделать на уровне шаблона или через template_redirect.
add_action( 'template_redirect', function() {
if ( is_page( array( 321, 322 ) ) ) {
status_header( 410 );
nocache_headers();
exit;
}
} );Не ставьте 410 на живые страницы. Это решение только для адресов, которые действительно удалены и не должны открываться пользователю.
Если нужен редирект
Когда старый URL имеет очевидную замену, лучше сделать 301 на новую страницу. Но не редиректите всё подряд на главную: это ухудшает качество сигнала и часто раздражает пользователей.
Проверка результата после внедрения
После изменений важно не ограничиваться визуальной проверкой в админке. Сначала откройте sitemap в браузере и убедитесь, что нужных URL там нет. Затем проверьте ответ сервера для старой страницы.
- Карта сайта больше не содержит удалённый URL.
- Старая страница отдаёт
410,404или корректный301. - Внутренние ссылки на этот адрес удалены.
- В Search Console новая версия sitemap загружена без ошибок.
Для быстрой проверки можно использовать curl:
curl -I https://example.com/old-page/Если всё настроено правильно, вы увидите не 200 OK, а нужный статус ответа. Для sitemap полезно проверить и сам XML:
curl -s https://example.com/wp-sitemap.xml | grep -n "old-page"Если строка не находится, страница больше не попадает в карту сайта. Но этого мало: проверьте ещё и кэш, если на сайте стоит плагин кеширования или CDN.
Частые ошибки и как их исправить
Страница скрыта в SEO-плагине, но осталась в sitemap ядра
Так бывает, если плагин управляет мета-тегами, а XML sitemap отдаёт сам WordPress. В этом случае нужно править именно источник карты сайта, а не только noindex.
URL удалён, но кэш отдаёт старую карту сайта
Очистите кэш плагина, серверный кэш и CDN. Иначе вы будете видеть старый XML даже после правильной настройки.
Поставили 301 на всё подряд
Массовый редирект старых URL на главную часто создаёт мягкие 404 и ухудшает качество обхода. Редирект должен вести на близкую по смыслу страницу.
Удалили страницу, но оставили внутренние ссылки
Поисковик продолжит находить адрес через меню, блоки, хлебные крошки и старые статьи. После удаления URL проверьте, где он ещё упоминается в базе и в шаблонах.
Практические советы по безопасности и производительности
Если sitemap очень большой, не пытайтесь решать проблему через тяжёлые запросы на каждом хите. Лучше исключать ненужные типы контента на уровне конфигурации, а не через сложные выборки в рантайме. Это уменьшает нагрузку и снижает риск ошибок в генерации XML.
Для сайтов с большим количеством служебных страниц удобно вести отдельный список исключений в коде темы или небольшого mu-plugin. Так правило не потеряется после обновления темы и не исчезнет при отключении обычного плагина.
Если вам нужно одновременно убрать дубли, очистить служебные URL и навести порядок в SEO-настройках, имеет смысл посмотреть в сторону инструментов, которые умеют управлять индексацией и чисткой сайта без лишних ручных правок, например Clearfy Pro: https://wpshop.ru/plugins/clearfy.
Главный критерий простой: если URL не должен быть в поиске, он не должен одновременно присутствовать в sitemap, внутренних ссылках и в ответе 200 OK. Когда эти три точки согласованы, индексация становится предсказуемой.