Как исправить проблемы с robots.txt и sitemap в WordPress

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

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

Когда проблема действительно в robots.txt или sitemap

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

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

Что проверить первым делом

Откройте в браузере /robots.txt и адрес sitemap, который использует сайт. Для WordPress это может быть стандартный /wp-sitemap.xml или карта сайта от SEO-плагина. Важно не просто увидеть файл, а проверить, что он отдаётся с кодом ответа 200 и содержит ожидаемые директивы и URL.

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

Диагностика: где именно ломается цепочка

В WordPress есть три типовых источника конфликта:

1. ядро WordPress генерирует базовый robots.txt динамически;
2. SEO-плагин подменяет его своим вариантом;
3. сервер или кэш отдают статический файл из корня сайта, который перекрывает динамическую генерацию.

Если в корне сайта лежит физический файл robots.txt, WordPress его уже не «перепишет» на лету. Это нужно учитывать до любых правок.

Проверить ответ сервера можно и из консоли:

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

Смотрите на статус, тип ответа и редиректы. Если вместо 200 OK видите 301, 302 или 404, сначала чините маршрут, а не содержимое файла.

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

1. Уберите конфликтующие источники robots.txt

Если в корне сайта есть статический robots.txt, сравните его с тем, что должен отдавать сайт сейчас. Часто там остаются старые запреты вроде Disallow: /wp-content/uploads/ или закрытие служебных разделов, которые уже не нужны.

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

2. Проверьте sitemap в SEO-плагине

У популярных SEO-плагинов карта сайта включается отдельно. После миграции сайта или обновления плагина она может сменить адрес, а старый URL продолжит висеть в Search Console. В таком случае нужно:

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

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

3. Добавьте точечные правила, если нужно скрыть служебные URL

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

Ниже пример, как убрать из sitemap отдельный тип записей через фильтр WordPress. Это не универсальная «волшебная кнопка», а рабочий способ для точечной настройки.

add_filter( 'wp_sitemaps_post_types', function( $post_types ) {
    if ( isset( $post_types['post'] ) ) {
        unset( $post_types['post'] );
    }

    return $post_types;
} );

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

4. При необходимости переопределите robots.txt через код

Если нужно добавить несколько директив без ручного файла в корне, используйте фильтр robots_txt. Это безопаснее, чем править физический файл на сервере, если сайт часто разворачивается из деплоя.

add_filter( 'robots_txt', function( $output, $public ) {
    $output .= "\nUser-agent: *";
    $output .= "\nDisallow: /wp-admin/";
    $output .= "\nAllow: /wp-admin/admin-ajax.php";
    $output .= "\nSitemap: https://example.com/wp-sitemap.xml";

    return $output;
}, 10, 2 );

Не копируйте этот фрагмент без проверки. Если у вас уже есть sitemap от SEO-плагина, указывать второй адрес не нужно. И если сайт закрыт от индексации на уровне Настройки → Чтение, сначала снимите этот флаг, иначе робот всё равно увидит запрет.

Сравнение подходов: файл, плагин или код

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

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

• curl -I показывает 200 OK без лишних редиректов;
• robots.txt содержит только актуальные директивы;
• sitemap открывается как XML и не возвращает HTML-страницу ошибки;
• в Search Console новый sitemap добавлен без предупреждений;
• запрещённые разделы действительно исчезли из карты сайта, а нужные URL остались.

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

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

Старый robots.txt лежит в корне и перекрывает всё

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

В sitemap попадают и старые, и новые URL

Обычно это происходит после смены SEO-плагина или переноса сайта. Нужно оставить только один источник sitemap и удалить старый адрес из Search Console, иначе отчёты будут путать.

Кэш отдаёт неактуальную версию

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

Закрыли важные разделы через Disallow

Disallow в robots.txt не удаляет URL из индекса мгновенно и не заменяет noindex. Если вы случайно закрыли CSS, JS или публичные страницы, робот может хуже рендерить сайт. Исправляйте правило точечно, а не добавляйте новые запреты «на всякий случай».

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

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

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

И ещё один практический момент: после любых изменений в robots.txt и sitemap не полагайтесь только на визуальную проверку. Сверяйте HTTP-ответ, содержимое XML и данные в Search Console. Именно эта связка показывает, что решение действительно сработало, а не просто «выглядит правильно» в браузере.