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

Автор: Георгий Никитин | Опубликовано: 22.08.2026

Иногда карта сайта в WordPress начинает мешать, а не помогать: в sitemap попадают служебные записи, внутренние типы контента, архивы, которые не должны индексироваться, или временные материалы. Если просто закрыть такие URL через robots.txt, это не решает задачу — поисковик всё равно может увидеть адреса из внешних ссылок или внутренних переходов. Надёжнее убрать лишнее именно из XML sitemap.

Ниже разберём рабочий сценарий: как исключить отдельные типы записей из sitemap в WordPress, как проверить, что фильтр сработал, и какие ошибки чаще всего ломают индексацию после таких правок.

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

Отключать тип записи из sitemap имеет смысл не «на всякий случай», а когда у него есть понятная техническая причина не попадать в поисковую выдачу. Типичные случаи:

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

Если речь о нескольких конкретных страницах, а не о целом типе записей, лучше не трогать sitemap целиком. Для точечной задачи обычно проще управлять noindex на уровне записи или шаблона. Но когда проблема системная, фильтрация sitemap — более чистый вариант.

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

Сначала проверьте, какой генератор карты сайта у вас активен. В WordPress 5.5+ есть встроенный XML sitemap. Если установлен SEO-плагин, он может подменять стандартный вывод своим механизмом. Это важно: фильтры для ядра WordPress и фильтры плагинов работают по-разному.

Как понять источник sitemap

откройте /wp-sitemap.xml — это встроенная карта сайта WordPress;
если у вас Yoast, Rank Math или другой SEO-плагин, проверьте их собственный sitemap URL;
посмотрите, какой URL указан в robots.txt и в Search Console.

Если лишний тип записей виден именно в wp-sitemap.xml, можно работать через фильтры ядра. Если sitemap отдаёт SEO-плагин, понадобится его API или настройки.

Быстрая проверка перед правкой

Перед изменениями полезно зафиксировать текущую картину:

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

Это экономит время: часто проблема не в sitemap, а в том, что тип записи всё ещё активно используется в шаблоне и потом «выпадает» из навигации вместе с картой сайта.

Пошаговое решение через код

Для встроенной XML-карты WordPress можно отключить конкретный тип записей через фильтр wp_sitemaps_post_types. Он позволяет убрать нужный post type из списка, который WordPress включает в sitemap.

<?php
add_filter( 'wp_sitemaps_post_types', function( $post_types ) {
    // Убираем служебный тип записей из XML sitemap.
    unset( $post_types['internal_note'] );

    return $post_types;
} );

В примере internal_note — это имя типа записей. Подставьте своё значение. После этого WordPress перестанет добавлять этот тип в карту сайта.

Если нужно исключить несколько типов

Когда служебных сущностей несколько, удобнее убрать их сразу в одном месте:

<?php
add_filter( 'wp_sitemaps_post_types', function( $post_types ) {
    $exclude = array( 'internal_note', 'import_log', 'landing_temp' );

    foreach ( $exclude as $post_type ) {
        if ( isset( $post_types[ $post_type ] ) ) {
            unset( $post_types[ $post_type ] );
        }
    }

    return $post_types;
} );

Такой подход удобен, если вы ведёте несколько технических типов записей и не хотите править логику в разных местах.

Куда вставлять код

Самый безопасный вариант — дочерняя тема или небольшой mu-plugin. Не стоит вносить такую правку прямо в файлы родительской темы: при обновлении она потеряется.

дочерняя тема — подходит, если у вас уже есть кастомизация шаблонов;
mu-plugin — лучше для технических правок, которые должны жить независимо от темы;
Code Snippets — допустимо для быстрого внедрения, если вы контролируете исполнение кода и не плодите дубли.

Если sitemap отдаёт SEO-плагин

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

Подход	Когда использовать	Плюс	Минус
Фильтр ядра WordPress	Если используется `/wp-sitemap.xml`	Просто и прозрачно	Не влияет на sitemap плагинов
Настройки SEO-плагина	Если sitemap генерирует Yoast/Rank Math и т.п.	Управление из админки	Зависит от конкретного плагина
Кастомный код	Когда нужен точный контроль	Можно исключать выборочно	Требует тестирования после обновлений

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

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

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

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

Откройте /wp-sitemap.xml или sitemap SEO-плагина.
Найдите раздел с типами записей.
Убедитесь, что исключённый тип больше не присутствует в списке.
Проверьте, нет ли отдельных дочерних sitemap для этого типа.

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

Что проверить в Search Console

В Google Search Console изменения не всегда видны сразу. Но если sitemap был отправлен повторно, со временем вы увидите, что лишние URL больше не приходят из карты сайта. Это особенно полезно, когда вы чистите индекс после миграции или удаления старого контента.

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

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

Ошибка 1. Отключили тип из sitemap, но URL всё равно индексируются

Это нормально: отсутствие в sitemap не означает автоматическое удаление из индекса. Поисковик может знать URL из внутренних ссылок или старых обходов. Решение — проверить, нужен ли noindex, редирект или удаление страницы.

Ошибка 2. Использовали неправильное имя post type

В коде нужно указывать именно системный ключ типа записи, а не его заголовок в админке. Например, internal_note, а не «Заметки».

Ошибка 3. Правку внесли в родительскую тему

После обновления тема перезапишется, и исключение исчезнет. Для таких задач используйте дочернюю тему или mu-plugin.

Ошибка 4. Смешали ядро WordPress и SEO-плагин

Если sitemap генерирует плагин, фильтр wp_sitemaps_post_types может не дать ожидаемого эффекта. Сначала определите источник sitemap, потом вносите правку.

Ошибка 5. Не очистили кэш

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

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

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

используйте статический список исключений, если он редко меняется;
храните правку в mu-plugin, если она относится к технической политике сайта;
после обновлений WordPress и SEO-плагинов перепроверяйте sitemap;
не закрывайте важные страницы только через исключение из sitemap — это не замена индексационным меткам.

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

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

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

Если после правки карта сайта стала чище, но в индексе остались старые адреса, это уже отдельная задача по деиндексации. Тут важно не путать генерацию sitemap и управление индексацией: они связаны, но не взаимозаменяемы.