Как закрыть открытые XML sitemap и robots.txt в WordPress без потери индексации

Если в WordPress sitemap или robots.txt ведут себя странно, проблема обычно не в поисковике, а в конфигурации сайта: дублируются адреса, подключены лишние SEO-плагины, сервер отдает не тот тип ответа или кэширует служебные файлы как обычные страницы. В итоге в индексе появляются лишние версии, а в Search Console — предупреждения о недоступности sitemap или ошибках сканирования.

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

Когда это действительно проблема

Служебные файлы WordPress должны быть предсказуемыми. Если /robots.txt или /sitemap.xml открываются с разными ответами, это уже не косметика. Поисковый робот может видеть устаревший sitemap, а в robots.txt — правила, которые не соответствуют текущей структуре сайта.

Типичные симптомы

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

Диагностика: что именно сломано

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

Проверка ответа сервера

Посмотрите заголовки и код ответа. Это можно сделать через браузерные devtools, curl или любой HTTP-клиент.

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

Что важно увидеть:

• 200 OK для реально существующего файла или маршрута;
• 404 для неиспользуемых вариантов, если вы их сознательно отключили;
• отсутствие редиректов на старый домен, http или www-версию без необходимости;
• одинаковое поведение для главного домена и зеркала, если зеркало закрыто.

Проверка источника sitemap

В WordPress sitemap может генерироваться ядром с версии 5.5 через wp-sitemap.xml, а может — SEO-плагином. Если оба механизма активны, часто получается путаница. Сначала проверьте, не включен ли отдельный sitemap в Yoast SEO, Rank Math, All in One SEO или другом плагине.

Пошаговое решение

1. Оставьте один источник sitemap

Если вы используете SEO-плагин, обычно лучше оставить его sitemap и отключить лишние генераторы. Если плагин не нужен, можно оставить штатный sitemap WordPress, но тогда не должно быть второго источника, который создает /sitemap.xml отдельно.

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

<?php
add_filter( 'wp_sitemaps_enabled', '__return_false' );

Этот код можно добавить в functions.php дочерней темы или в небольшой mu-plugin. Но делайте это только если вы точно понимаете, какой sitemap будет основным.

2. Проверьте robots.txt на динамическую генерацию

WordPress может отдавать robots.txt динамически, если физического файла в корне нет. Это удобно, но при наличии SEO-плагина или кастомного правила сервер может начать отдавать не ту версию. Если у вас есть физический robots.txt в корне, убедитесь, что он не конфликтует с настройками плагина.

Пример минимального robots.txt для сайта на WordPress:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/sitemap_index.xml

Адрес sitemap в строке Sitemap: должен совпадать с тем, что реально открывается в браузере и отдается с кодом 200.

3. Уберите дубли через SEO-плагин или код

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

Например, если вам нужно убрать attachment-страницы из индекса и не плодить лишние URL, можно перенаправлять их на родительскую запись или на главную:

<?php
add_action( 'template_redirect', function () {
    if ( is_attachment() ) {
        $parent = wp_get_post_parent_id( get_queried_object_id() );
        if ( $parent ) {
            wp_safe_redirect( get_permalink( $parent ), 301 );
        } else {
            wp_safe_redirect( home_url( '/' ), 301 );
        }
        exit;
    }
} );

Это не замена полноценной SEO-настройке, но рабочий способ убрать мусорные страницы, если они уже попали в индекс.

4. Очистите кэш и проверьте CDN

Очень часто проблема остается после того, как вы уже все исправили в WordPress. Причина простая: robots.txt и sitemap кэшируются на уровне плагина, сервера или CDN. Если кэш не сброшен, поисковик еще какое-то время видит старую версию.

• очистите кэш плагина;
• сбросьте серверный кэш, если он есть;
• обновите CDN-кэш для /robots.txt и sitemap;
• проверьте, не включено ли отдельное правило кэширования для служебных файлов.

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

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

Мини-чек-лист проверки

• /robots.txt открывается с 200 и содержит актуальный sitemap;
• основной sitemap открывается без редиректов и ошибок;
• старые sitemap возвращают 404 или корректный редирект, если это задумано;
• в Search Console нет новых ошибок по sitemap;
• в индексе не появляются лишние служебные URL;
• после очистки кэша версия файла не меняется самопроизвольно.

Для быстрой проверки удобно смотреть заголовки:

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

Если вы видите 200, но содержимое старое, значит проблема не в WordPress, а в кэше или CDN.

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

Оставили два sitemap одновременно

Это самая частая ошибка после установки SEO-плагина поверх штатного sitemap WordPress. Исправление простое: оставьте один источник и проверьте, что все ссылки в robots.txt указывают на него.

Закрыли robots.txt через редирект

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

Забыли про кэш на уровне CDN

После обновления sitemap старый файл может продолжать отдаваться с edge-серверов. В таком случае локальная проверка на хостинге покажет одно, а внешняя — другое. Проверяйте именно публичный URL.

Подменили sitemap статическим файлом и не обновляют его

Статический sitemap кажется удобным, пока не меняется структура сайта. После этого в карте остаются удаленные URL, а новые страницы не попадают в индекс. Если сайт живой, динамический генератор обычно надежнее.

Что выбрать: плагин, код или серверную настройку

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

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

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

Служебные файлы — мелочь только на первый взгляд. Через них легко случайно открыть лишние разделы, тестовые каталоги или старые поддомены. Не храните в robots.txt внутренние пути, которые могут выдать структуру админки или staging-среды, если это не нужно.

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

Если после правок проблема не уходит, проверьте, не генерирует ли sitemap другой плагин, не подменяет ли ответ серверное правило и не висит ли старый файл в корне сайта. В таких случаях помогает не очередная «магическая» настройка, а последовательная проверка источника ответа и его кэша.