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

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

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

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

Отключать отдельные типы записей из XML sitemap имеет смысл, если они не несут поисковой ценности и не должны участвовать в органике. Это касается, например, внутренних логов, технических страниц, временных материалов, приватных разделов, тестовых кастомных пост-типов и некоторых архивов, которые создаются плагинами автоматически.

Если тип записей нужен пользователям, но не должен индексироваться, важно не путать задачи: карта сайта — это список рекомендуемых к обходу URL, а не механизм запрета индексации. Поэтому сначала вычищаем sitemap, затем проверяем, не осталось ли открытых ссылок на эти страницы внутри сайта.

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

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

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

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

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

<?php
add_action('init', function () {
    $types = get_post_types(['public' => true], 'objects');

    foreach ($types as $type) {
        error_log($type->name . ' | show_in_rest=' . (int) $type->show_in_rest);
    }
});

Этот фрагмент не меняет поведение сайта, а помогает понять, какие типы контента вообще участвуют в публичной части. Для боевого сайта логирование лучше включать временно и только на staging.

Как отключить тип записей из встроенного XML sitemap WordPress

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

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

    return $post_types;
});

В этом примере из sitemap исчезнут записи типа case_study и internal_note. Названия нужно подставлять реальные, те, что зарегистрированы через register_post_type().

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

Иногда post type нужен в sitemap, но отдельные записи — нет. Например, вы хотите оставить публичные статьи, но исключить записи со статусом «черновик», «внутренний материал» или материалы с определённым мета-полем. Тогда удобнее фильтровать сами URL.

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

    return $args;
}, 10, 2);

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

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

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

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

Пошаговое решение без лишнего риска

1. Определите, какой sitemap используется: встроенный WordPress или SEO-плагин.
2. Составьте список типов записей, которые не должны попадать в карту сайта.
3. Сначала отключите их в настройках плагина, если это возможно.
4. Если встроенный sitemap — добавьте фильтр wp_sitemaps_post_types.
5. Если нужно исключить только часть записей — используйте wp_sitemaps_posts_query_args.
6. Очистите кеш, если на сайте есть кеширование HTML или страниц sitemap.
7. Проверьте итоговый XML в браузере и через Search Console.

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

Как проверить, что решение сработало

Проверка должна быть не визуальной, а технической. Откройте sitemap и убедитесь, что нужного типа записей там больше нет. Затем проверьте исходный XML на наличие исключённых URL или блоков. Если карта сайта разбита на страницы, проверьте не только первую, но и все связанные подкарты.

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

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

curl -s https://example.com/wp-sitemap.xml | grep -E 'case_study|internal_note'

Пустой результат в этом случае означает, что в XML больше нет упоминаний нужного типа. Но если sitemap генерируется динамически и кешируется, всё равно проверьте страницу в браузере после сброса кеша.

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

Отключили тип записей, но URL всё ещё индексируются

Это нормально, если на них ведут внутренние ссылки или они уже были известны поисковику. Убрать их из sitemap недостаточно. Нужно проверить, не остались ли ссылки в меню, блоках, хлебных крошках, архивных страницах и в старых публикациях.

Сломали sitemap после обновления плагина

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

Скрыли не тот тип записей

Часто путают slug post type и название таксономии. Перед удалением из массива проверьте точное имя через register_post_type() или через вывод объектов в отладочный лог. Иначе можно убрать из sitemap не ту сущность и потерять полезные URL.

Не очистили кеш

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

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

Не стоит встраивать такую логику в functions.php, если сайт активно развивается и тема может меняться. Для технических правок, связанных с индексацией, безопаснее использовать mu-plugin: он не зависит от темы и не пропадает после обновления.

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

Для сайтов, где нужно одновременно чистить sitemap, убирать дубли и управлять индексированием, удобно смотреть в сторону специализированных инструментов вроде Clearfy Pro, если вам нужен набор типовых SEO- и технастроек в одном месте. Но даже в этом случае полезно понимать, что именно меняется на уровне WordPress, чтобы не лечить симптом вместо причины.

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