Иногда sitemap в WordPress начинает мешать, а не помогать: в него попадают служебные записи, дубли архивов, тестовые CPT или контент, который не должен индексироваться. Если оставить всё как есть, поисковик будет тратить краулинговый бюджет на мусорные URL, а в отчётах появятся страницы, которые вы не хотите видеть в индексе.
Ниже разберём, как точечно убрать отдельные типы записей из XML Sitemap без поломки сайта и как проверить, что изменения реально сработали.
Когда это нужно и как выглядит проблема
Типичный сценарий: на сайте есть кастомный тип записей для внутренних материалов, документации, черновых страниц или временного контента. Он доступен на фронтенде, но не должен попадать в sitemap. Ещё один частый случай — в sitemap уже есть страницы, которые закрыты от индексации через noindex, но продолжают светиться в карте сайта.
Проверять нужно не «на глаз», а по факту. Откройте sitemap в браузере и посмотрите, какие URL туда попали. Если у вас SEO-плагин, проверьте именно его sitemap, а не только стандартный WordPress XML Sitemap.
Что обычно идёт не так
- Тип записи отключили от индексации, но не убрали из sitemap.
- В sitemap попадают записи с
noindex, что создаёт противоречивые сигналы. - После правки кода кэш не обновился, и старый sitemap продолжает отдаваться.
- Фильтр применили не к тому плагину: у Yoast, Rank Math и WordPress Core разные точки вмешательства.
Сначала выберите способ: плагин, фильтр или настройка CPT
Если задача разовая и у вас уже стоит SEO-плагин, проще всего убрать тип записей через его настройки. Если нужен точечный контроль или вы ведёте собственную тему/плагин, надёжнее использовать фильтр. А если тип записей создаёте вы сами, лучше сразу задать правильные параметры при регистрации.
| Способ | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Настройка в SEO-плагине | Нужно быстро убрать CPT из sitemap | Без кода | Зависит от конкретного плагина |
| Фильтр в теме или мини-плагине | Нужен точный контроль | Работает предсказуемо | Нужно править код |
Параметры register_post_type() | Вы создаёте CPT сами | Правильная архитектура | Не поможет для уже существующего типа |
Пошаговое решение через код WordPress
Если вы управляете собственным типом записей, начните с регистрации CPT. Для него можно сразу отключить публичную индексацию и исключить из sitemap на уровне логики сайта. Сам по себе WordPress не знает, что именно вы хотите скрыть от поисковиков, поэтому важно задать параметры явно.
add_action('init', function () {
register_post_type('internal_note', [
'label' => 'Internal notes',
'public' => false,
'publicly_queryable' => false,
'show_ui' => true,
'show_in_menu' => true,
'exclude_from_search' => true,
'has_archive' => false,
'rewrite' => false,
'show_in_rest' => false,
'supports' => ['title', 'editor'],
]);
});Этот вариант подходит, если записи не должны быть доступны на фронтенде. Но если CPT нужен на сайте, а из sitemap его надо убрать, используйте фильтр sitemap. В WordPress Core для этого есть wp_sitemaps_post_types.
add_filter('wp_sitemaps_post_types', function ($post_types) {
unset($post_types['internal_note']);
unset($post_types['event_log']);
return $post_types;
});После этого WordPress перестанет добавлять указанные типы записей в XML Sitemap, но сами записи останутся доступными там, где вы их уже используете. Это полезно, если контент нужен пользователям или админам, но не нужен поисковым роботам.
Если sitemap отдаёт SEO-плагин
У SEO-плагинов свои механизмы генерации карты сайта. В Yoast и Rank Math логика отличается, поэтому не стоит пытаться решать всё одним универсальным фильтром WordPress Core. Сначала проверьте настройки самого плагина: часто там можно отключить отдельный post type для sitemap без кода.
Если в интерфейсе нет нужной опции, ищите фильтры именно в документации вашего плагина. Важно не гадать по названию хука, а сверяться с официальной документацией: у SEO-плагинов API меняется, а неверный фильтр просто не сработает.
Как убрать только отдельные записи, а не весь тип
Иногда проблема не в типе записей, а в нескольких конкретных страницах: тестовые записи, дубли, материалы для внутренней проверки. В таком случае отключать весь CPT не нужно. Проще исключить записи по ID из sitemap через фильтр wp_sitemaps_posts_query_args.
add_filter('wp_sitemaps_posts_query_args', function ($args, $post_type) {
if ($post_type === 'post') {
$args['post__not_in'] = [123, 456, 789];
}
return $args;
}, 10, 2);Такой подход полезен, когда нужно оставить тип записей в sitemap, но убрать несколько проблемных URL. Например, это может быть временная публикация, дубль статьи или запись, которую вы уже закрыли от индексации и хотите убрать из карты сайта.
Проверка после внедрения
После правки не ограничивайтесь просмотром кода. Проверьте результат в нескольких местах:
- откройте sitemap в браузере и убедитесь, что нужных URL там больше нет;
- очистите кэш сайта, если используется плагин кэширования или серверный кэш;
- проверьте ответ sitemap через
curlили DevTools; - посмотрите, не остались ли старые URL в Google Search Console;
- убедитесь, что записи по-прежнему открываются там, где это нужно.
Простой способ проверить ответ сервера:
curl -I https://example.com/wp-sitemap-posts-post-1.xmlЕсли вы меняли sitemap через код, полезно также открыть исходный XML и проверить, что нужный post type или конкретные записи действительно исчезли. Если URL всё ещё есть, чаще всего виноват кэш или фильтр, который подключён слишком поздно.
Частые ошибки и как их исправить
Скрыли запись от индексации, но не убрали из sitemap
Это самая частая несогласованность. Если страница закрыта через noindex, но остаётся в sitemap, поисковик получает противоречивый сигнал. Исправление простое: либо убирайте URL из sitemap, либо пересматривайте стратегию индексации.
Правка сделана в теме, а не в плагине
Если код лежит в теме, при смене темы настройка исчезнет. Для технических правил, связанных с индексацией, лучше использовать мини-плагин или mu-plugin. Это надёжнее и проще сопровождать.
Не сброшен кэш
После изменения sitemap старый XML может продолжать отдаваться из кэша. Очистите кэш плагина, серверный кэш и, если есть, CDN. Без этого вы будете проверять уже неактуальный ответ.
Использован не тот фильтр
WordPress Core и SEO-плагины не всегда используют одинаковые точки расширения. Если фильтр не сработал, проверьте, кто именно генерирует sitemap на сайте: ядро WordPress, Yoast, Rank Math или другой плагин.
Безопасность и производительность
С точки зрения производительности лучше не держать в sitemap лишние URL. Это не ускорит сайт напрямую, но уменьшит шум для поисковых систем и упростит контроль индексации. Для безопасности важнее другое: не скрывайте через sitemap то, что должно быть закрыто на уровне доступа. Если контент действительно служебный, ограничьте доступ, а не только убирайте его из XML.
Если вы работаете с большим сайтом и регулярно чистите дубли, служебные записи и SEO-артефакты, удобно держать такие настройки в одном месте. В этом сценарии может помочь Clearfy Pro: у него есть инструменты для технической чистки и удаления лишних дублей, но использовать его стоит только там, где он реально закрывает вашу задачу, а не вместо понимания логики индексации.
Что проверить после публикации изменений
- Нужный тип записей исчез из sitemap.
- Конкретные исключённые записи больше не отдаются в XML.
- Сайт не потерял доступ к нужным публичным страницам.
- В Search Console не появилось новых ошибок sitemap.
- Кэш и CDN обновили ответ.
Если после всех проверок URL всё ещё видны в карте сайта, не пытайтесь лечить это повторной установкой плагина. Сначала выясните, кто именно генерирует sitemap, и только потом вносите точечную правку. В WordPress это почти всегда быстрее, чем искать «универсальное решение» наугад.
}