Как отключить XML sitemap для отдельных типов записей в WordPress

Ситуация типовая: сайт на WordPress уже живёт, контент размечен по нескольким типам записей, а в XML sitemap попадает то, что вы не хотите показывать поисковикам. Это могут быть служебные записи, черновые CPT, страницы фильтров, архивы таксономий или контент, который должен оставаться доступным только внутри сайта. Если просто закрыть URL в robots.txt, сам sitemap от этого не очистится. А если удалить страницу из индекса через мета-тег, но оставить её в карте сайта, вы получите лишний шум в отчётах и лишние обходы.

Ниже — практический разбор, как убрать конкретные сущности из XML sitemap в WordPress, как проверить результат и где чаще всего ошибаются.

Когда это действительно нужно

Не трогайте sitemap «на всякий случай». Убирать из него стоит только то, что не должно участвовать в поисковом обходе как отдельная цель:

• служебные или технические типы записей;
• дубли контента, которые уже закрыты от индексации;
• внутренние страницы, не предназначенные для поиска;
• таксономии с пустой или слабой ценностью;
• архивы, которые создают лишние URL без пользы.

Если страница должна индексироваться и приводить трафик, удалять её из sitemap не нужно. Карта сайта — это подсказка для поисковика, а не список «всего лишнего».

Диагностика: что именно попадает в sitemap

Сначала проверьте, какой генератор карты сайта используется. В WordPress это может быть встроенный XML sitemap, SEO-плагин или код темы/плагина. От этого зависит способ исключения.

Как быстро понять источник

• Откройте /wp-sitemap.xml — это встроенный sitemap WordPress.
• Если адрес другой, например /sitemap_index.xml, скорее всего, карту генерирует SEO-плагин.
• Посмотрите исходный код страницы и найдите ссылку на sitemap в <link rel="sitemap" ...> или в футере плагина.

Дальше проверьте, какие именно URL нужно исключить. Для этого удобно открыть sitemap и найти:

• лишний post type;
• конкретную запись или страницу;
• архив таксономии;
• медиа-страницы, если они не нужны в поиске.

Пошаговое решение для встроенного XML sitemap WordPress

Если сайт использует встроенную карту сайта WordPress, можно исключить целые типы записей, таксономии или отдельные записи через фильтры. Это надёжнее, чем пытаться править sitemap вручную.

1. Убрать целый тип записей из sitemap

Для этого подходит фильтр wp_sitemaps_post_types. Он позволяет удалить нужный post type из списка, который WordPress включает в sitemap.

add_filter( 'wp_sitemaps_post_types', function( $post_types ) {
    unset( $post_types['product'] ); // пример: убрать CPT product
    unset( $post_types['event'] );   // пример: убрать CPT event

    return $post_types;
} );

Код можно добавить в мини-плагин или в functions.php дочерней темы. Для боевого сайта мини-плагин обычно безопаснее: он не исчезнет при смене темы.

2. Исключить конкретную таксономию

Если проблема не в записях, а в архивах рубрик, тегов или кастомной таксономии, используйте wp_sitemaps_taxonomies.

add_filter( 'wp_sitemaps_taxonomies', function( $taxonomies ) {
    unset( $taxonomies['post_tag'] );   // убрать теги
    unset( $taxonomies['brand'] );      // убрать кастомную таксономию

    return $taxonomies;
} );

Это полезно, если архивы таксономии существуют технически, но не несут самостоятельной SEO-ценности.

3. Исключить отдельную запись или страницу

Если нужно убрать только один URL, а не весь тип записей, используйте фильтр wp_sitemaps_posts_query_args и исключите ID.

add_filter( 'wp_sitemaps_posts_query_args', function( $args, $post_type ) {
    if ( 'post' === $post_type ) {
        $args['post__not_in'] = array( 123, 456 );
    }

    return $args;
}, 10, 2 );

Такой подход удобен для единичных служебных страниц, которые не должны попадать в sitemap, но должны оставаться доступными по прямой ссылке.

Если sitemap генерирует SEO-плагин

У SEO-плагинов логика обычно своя. В этом случае не стоит смешивать встроенный sitemap WordPress и карту плагина одновременно, иначе можно получить дублирующиеся карты или конфликтующие правила.

Что делать на практике:

• найти настройку исключения post type, таксономии или отдельной записи в интерфейсе плагина;
• если настройки нет, проверить документацию конкретного плагина;
• не править XML вручную — при следующей генерации изменения пропадут.

Проверка результата после внедрения

После изменения не ограничивайтесь визуальной проверкой в браузере. Нужно убедиться, что URL действительно исчезли из карты сайта и не возвращаются после обновления кэша.

1. Откройте sitemap по адресу /wp-sitemap.xml или /sitemap_index.xml.
2. Проверьте, что нужный раздел исчез из списка.
3. Если карта сайта кэшируется, очистите кэш плагина и серверный кэш.
4. Проверьте исходный XML через поиск по странице: нужного post type, таксономии или ID быть не должно.
5. В Search Console отправьте sitemap на повторную обработку, если изменения важны для индексации.

Для дополнительной проверки можно посмотреть заголовки ответа и убедиться, что sitemap отдаётся без старой версии из CDN или reverse proxy.

curl -I https://example.com/wp-sitemap.xml

Если в ответе виден старый Last-Modified или кэширующий слой, обновление могло не примениться на уровне доставки.

Частые ошибки и как их исправить

Удалили URL из sitemap, но он всё ещё индексируется

Это нормально: исключение из sitemap не удаляет страницу из индекса мгновенно. Если URL должен исчезнуть из поиска, дополнительно проверьте мета-robots, канонический URL и статус страницы. Для реально ненужных страниц нужен либо noindex, либо редирект, либо 404/410 — в зависимости от сценария.

Правили не тот sitemap

Часто на сайте одновременно есть встроенный sitemap WordPress и sitemap от SEO-плагина. В итоге меняют код, а поисковик продолжает видеть старую карту. Сначала определите, какой файл реально указан в Search Console и какой URL открывается в браузере.

Сломали sitemap для всех типов записей

Это обычно происходит, когда в фильтре возвращают пустой массив или удаляют не тот ключ. Перед внедрением проверьте точное имя post type или taxonomy. В WordPress это не всегда совпадает с читаемым названием в админке.

Забыли про кэш

Если sitemap отдаётся через кэш плагина, CDN или серверный кэш, изменения в коде не будут видны сразу. После правки очищайте не только кэш WordPress, но и внешний кэш на уровне хостинга.

Безопасность и производительность

С точки зрения производительности лучше исключать из sitemap лишнее, чем держать там десятки технических URL. Но не пытайтесь компенсировать это тяжёлыми запросами в каждом хите фронтенда. Фильтры sitemap вызываются при генерации карты, и это нормальное место для такой логики.

Если у вас много исключений, вынесите список ID или типов в отдельную функцию, чтобы не размазывать логику по теме. Для проекта с несколькими разработчиками это проще сопровождать и проверять в код-ревью.

function wpapi_excluded_sitemap_ids() {
    return array( 123, 456, 789 );
}

add_filter( 'wp_sitemaps_posts_query_args', function( $args, $post_type ) {
    if ( 'page' === $post_type ) {
        $args['post__not_in'] = wpapi_excluded_sitemap_ids();
    }

    return $args;
}, 10, 2 );

Если вам нужно не только чистить sitemap, но и системно убирать дубли, лишние архивы и технические страницы, имеет смысл смотреть в сторону инструментов, которые закрывают это комплексно. Например, в Clearfy Pro есть набор настроек для чистки WordPress и удаления лишних SEO-элементов: https://wpshop.ru/plugins/clearfy.

Когда лучше не использовать код

Если сайт поддерживает не разработчик, а редактор или SEO-специалист без доступа к репозиторию, удобнее вынести исключения в настройки плагина. Код даёт точный контроль, но требует дисциплины: хранить его в правильном месте, не терять при обновлении темы и не дублировать в нескольких файлах.

Код оправдан, когда нужно:

• исключить нестандартный CPT;
• убрать несколько конкретных записей;
• автоматизировать правило для проекта с понятной структурой;
• избежать зависимости от интерфейса плагина.

Если задача разовая и сайт уже ведётся через SEO-плагин, проще использовать штатные настройки плагина, а не добавлять ещё один слой логики.