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

Ситуация типовая: в WordPress карта сайта есть, но в ней оказываются записи, которые не должны попадать в поиск. Это могут быть служебные типы записей, архивы с дублями, тестовые материалы, внутренние страницы плагинов или контент, который вы уже закрыли от индексации, но он всё равно продолжает светиться в sitemap. В итоге поисковик видит лишние URL, а вы тратите краулинговый бюджет на мусор.

Задача здесь не в том, чтобы «выключить sitemap целиком», а в том, чтобы точечно убрать ненужные типы записей и проверить, что карта сайта после этого осталась валидной. Ниже — рабочие способы для WordPress без выдуманных хуков и без опасных правок ядра.

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

Не каждый лишний URL в sitemap — проблема. Но если в карте сайта появляются страницы, которые не должны индексироваться или вообще не предназначены для публичного доступа, лучше убрать их на уровне генерации sitemap, а не надеяться на robots.txt.

Типичные сценарии

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

Важно: если URL уже был в индексе, одного удаления из sitemap может быть недостаточно. Обычно нужно ещё проверить noindex, внутренние ссылки и статус страницы.

Диагностика: где именно появляется лишний тип записей

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

Что проверить в первую очередь

• какой sitemap открыт: /wp-sitemap.xml или карта от SEO-плагина;
• какой именно post type попал в список;
• есть ли у него публичность public и publicly_queryable;
• не добавляет ли его в sitemap тема или плагин через собственный фильтр;
• не кэшируется ли старая версия карты сайта на уровне сервера или CDN.

Если у вас включён WordPress core sitemap, проверьте, что URL вообще относится к нужному типу записей. Иногда проблема не в типе записей, а в таксономии или архиве автора, который вы приняли за «лишний sitemap».

Способ 1: убрать тип записей из sitemap через код

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

<?php
add_filter( 'wp_sitemaps_post_types', function( $post_types ) {
    unset( $post_types['service'] );
    unset( $post_types['portfolio'] );

    return $post_types;
} );

Здесь service и portfolio — примеры custom post type. Подставьте свои реальные ключи. После этого WordPress перестанет включать эти типы в XML sitemap, но сами записи останутся доступными на сайте, если вы их не закрывали отдельно.

Если нужно убрать только часть записей внутри типа

Иногда тип записей нужен в sitemap, но отдельные записи — нет. Тогда удобнее фильтровать список URL перед выводом. Для ядра WordPress есть фильтр wp_sitemaps_posts_query_args, через который можно исключить записи по ID, статусу или другим параметрам запроса.

<?php
add_filter( 'wp_sitemaps_posts_query_args', function( $args, $post_type ) {
    if ( 'post' !== $post_type ) {
        return $args;
    }

    $args['post__not_in'] = array( 123, 456 );

    return $args;
}, 10, 2 );

Это полезно, если у вас есть служебные записи, которые должны жить на сайте, но не должны попадать в карту сайта. Важно не путать это с удалением из индекса: поисковик может найти URL по внутренним ссылкам.

Способ 2: если sitemap отдаёт SEO-плагин

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

Если вы используете SEO-плагин, сначала проверьте его настройки sitemap: там часто можно исключить post type, отдельные таксономии или конкретные записи. Но если плагин не даёт нужной гибкости, лучше вынести логику в небольшой код в mu-plugins или в дочернюю тему.

Пошаговое решение без поломки карты сайта

1. Определите, какой sitemap сейчас активен: ядро WordPress или SEO-плагин.
2. Найдите точный ключ типа записей, который нужно убрать.
3. Добавьте фильтр в functions.php дочерней темы или в mu-plugin.
4. Очистите кэш сайта, сервера и CDN, если он есть.
5. Проверьте XML sitemap в браузере и через валидатор.
6. Убедитесь, что лишний тип записей исчез из sitemap, но нужные разделы остались.

Если вы вносите изменения в дочернюю тему, не забудьте, что при смене темы код пропадёт. Для технических исключений надёжнее использовать mu-plugins: такой код не отключится случайно после обновления темы.

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

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

Что именно проверить

• открывается ли /wp-sitemap.xml или sitemap плагина без ошибок;
• исчез ли нужный post type из списка;
• не остались ли старые URL в кеше;
• нет ли в sitemap страниц с noindex или закрытых разделов;
• обновилась ли дата последней модификации, если она используется;
• не сломались ли другие разделы карты сайта.

Если хотите проверить быстро через консоль, можно просто запросить sitemap и посмотреть, есть ли там нужный ключ. Например:

curl -s https://example.com/wp-sitemap.xml | grep -i portfolio

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

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

1. Убрали тип записей из sitemap, но он всё ещё индексируется

Это нормально, если на него ведут внутренние ссылки или он уже был в индексе. В таком случае проверьте noindex, canonical и наличие ссылок из меню, хлебных крошек, блоков похожих материалов и XML-карт сайта для изображений.

2. Правка сделана в родительской теме

После обновления темы код исчезнет. Перенесите фильтр в дочернюю тему или mu-plugin. Для технических исключений это надёжнее.

3. Изменили код, но sitemap не обновился

Часто виноват кэш. Очистите кэш плагина, серверный кэш и CDN. Если используется object cache, иногда помогает повторная генерация страницы sitemap после сброса кэша.

4. Сломали sitemap целиком

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

Практические советы по безопасности и производительности

Если вы часто правите технические настройки WordPress, держите такие изменения отдельно от бизнес-логики темы. Для этого удобны mu-plugins или небольшой собственный плагин. Так вы не потеряете настройки при обновлении темы и не смешаете SEO-логику с версткой.

Ещё один полезный момент: не пытайтесь решать проблему только через robots.txt. Если URL уже попал в sitemap, поисковик всё равно увидит его как потенциально важный. Гораздо чище убрать лишний тип записей из генерации карты сайта и отдельно проверить индексацию.

Если вам нужно регулярно чистить сайт от дублей, служебных URL и лишних технических разделов, такие задачи удобно закрывать централизованно. В экосистеме WPShop для этого есть Clearfy Pro, но использовать его имеет смысл только если вам действительно нужен набор технических SEO-настроек, а не одна точечная правка.

Короткий чек-лист перед публикацией правки

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

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