Как закрыть XML sitemap от индексации в WordPress без поломки SEO

Ситуация выглядит странно: карта сайта есть, поисковики её читают, а в выдаче внезапно появляется сама XML-страница sitemap. Обычно это не катастрофа, но сигнал, что настройки индексации, robots.txt или SEO-плагина собраны неаккуратно. В WordPress такое чаще всего всплывает после смены плагина, переноса сайта или ручных правок в robots.txt.

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

Когда sitemap попадает в индекс и почему это вообще проблема

XML-карта сайта сама по себе не должна быть “контентной” страницей. Но поисковик может показать её в выдаче, если:

• карта доступна по обычному URL и не закрыта от индексации;
• в robots.txt нет явного запрета на сам файл sitemap;
• SEO-плагин генерирует карту, но не управляет мета-robots для служебных URL;
• на сайте есть несколько карт сайта от разных плагинов одновременно;
• в индексе остались старые URL после миграции.

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

Диагностика: что именно индексируется

Сначала нужно понять, речь идёт о самой карте сайта или о страницах, которые в неё входят. Это разные задачи.

Проверка в поиске

Вбейте в поиск:

site:example.com sitemap

Если в выдаче есть URL вида /sitemap.xml, /sitemap_index.xml или похожий, поисковик видит карту как отдельную страницу. Это не всегда ошибка, но повод проверить настройки.

Проверка заголовков и robots

Посмотрите ответ сервера для sitemap:

curl -I https://example.com/sitemap_index.xml

Ищите:

• 200 OK — карта доступна;
• X-Robots-Tag — если есть noindex, это уже явный запрет;
• редиректы на другой адрес — иногда sitemap уходит на старый домен или на HTTP-версию.

Параллельно откройте robots.txt:

curl https://example.com/robots.txt

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

Что делать: рабочая схема без лишних рисков

Есть три уровня решения: через SEO-плагин, через robots.txt и через код. Обычно достаточно первых двух. Код нужен, когда плагин не даёт нужного контроля или на сайте несколько источников sitemap.

Вариант 1: настроить карту сайта в SEO-плагине

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

Что проверить:

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

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

Вариант 2: явно указать sitemap в robots.txt

Это полезно, когда нужно привести сайт к нормальной базовой конфигурации. В robots.txt можно добавить строку с адресом карты сайта:

User-agent: *
Disallow:
Sitemap: https://example.com/sitemap_index.xml

Если у вас не индексируется именно служебная страница карты, а не весь сайт, этого часто достаточно для нормальной обработки. Главное — не писать туда лишние запреты вроде Disallow: / или блокировки папок, где лежат важные URL.

Вариант 3: задать noindex для служебного sitemap через код

Если карта генерируется не тем плагином, который умеет управлять мета-robots, можно добавить заголовок X-Robots-Tag: noindex, follow для конкретного URL. Это уже точечная мера, и применять её стоит только к служебной странице, а не ко всем XML-файлам подряд.

add_action('template_redirect', function () {
    if (is_admin()) {
        return;
    }

    $uri = $_SERVER['REQUEST_URI'] ?? '';

    if (strpos($uri, 'sitemap.xml') !== false || strpos($uri, 'sitemap_index.xml') !== false) {
        header('X-Robots-Tag: noindex, follow', true);
    }
});

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

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

1. Определите, кто генерирует sitemap: ядро WordPress, SEO-плагин или отдельный модуль.
2. Проверьте, нет ли двух активных карт сайта одновременно.
3. Откройте sitemap в браузере и убедитесь, что он отдаёт 200 OK, а не редирект на старый адрес.
4. Добавьте явную строку Sitemap: в robots.txt.
5. Если sitemap уже в индексе, обновите его через Google Search Console и дождитесь переобхода.
6. Если служебный URL всё равно индексируется как страница, примените точечный X-Robots-Tag или штатную настройку плагина.

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

Проверка должна быть не только визуальной. Нужны минимум три сигнала.

• URL sitemap открывается без редиректов на старый домен или HTTP.
• В robots.txt указан актуальный адрес карты сайта.
• В ответе сервера для sitemap нет случайного noindex на весь XML-раздел.
• В поиске по site:example.com sitemap служебная страница постепенно исчезает или перестаёт показываться как обычный результат.
• В Search Console карта сайта отправляется без ошибок чтения.

Если вы меняли заголовки через код, проверьте ответ через curl -I. Если правили robots.txt, проверьте его именно с домена сайта, а не локальную копию. Если использовали SEO-плагин, убедитесь, что он не перезаписал ваши ручные изменения после обновления.

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

Закрывают весь сайт вместо одной служебной страницы

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

Оставляют две карты сайта одновременно

После миграции на новый SEO-плагин часто остаётся и core sitemap WordPress, и sitemap от плагина. Это создаёт дубли и путаницу в Search Console. Решение: оставить один источник карты сайта и отключить второй.

Меняют URL, но не обновляют внутренние ссылки и Search Console

Если sitemap переехал с /sitemap.xml на /sitemap_index.xml, старый адрес может ещё долго висеть в индексе. Нужно обновить отправленный sitemap в Search Console и дождаться переобхода.

Ставят noindex на все XML-ответы подряд

Это ломает не только sitemap, но и другие служебные XML-эндпоинты, если они есть. Точечная проверка по конкретному URL безопаснее, чем глобальное правило по расширению.

Когда лучше не трогать sitemap кодом

Если у вас обычный сайт на одном SEO-плагине, без кастомных эндпоинтов и без конфликтов с core sitemap, код чаще лишний. В таких случаях проще и надёжнее решить задачу в настройках плагина и robots.txt. Чем меньше самописной логики вокруг индексации, тем проще сопровождать сайт после обновлений.

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

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