Как настроить robots.txt и sitemap в WordPress без конфликтов с SEO-плагином

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

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

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

Сначала стоит убедиться, что вы решаете правильную задачу. На практике чаще всего встречаются такие симптомы:

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

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

• какой SEO-плагин активен и не генерирует ли он собственный sitemap;
• есть ли физический файл robots.txt в корне сайта;
• не включён ли кэш на уровне сервера или плагина, который отдаёт старую версию;
• не создаёт ли тема или другой плагин отдельный XML-индекс;
• не блокирует ли robots.txt путь к самой карте сайта.

Как WordPress отдаёт robots.txt и sitemap

У WordPress есть два типичных сценария. Первый — физический файл robots.txt в корне сайта. Второй — виртуальная генерация через WordPress и SEO-плагин. С sitemap похожая история: его может отдавать сам WordPress, SEO-плагин или отдельный модуль темы.

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

Пошаговая настройка без конфликтов

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

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

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

Шаг 2. Приведите robots.txt к минимально понятному виду

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

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xml

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

Шаг 3. Если нужен ручной robots.txt, создайте его в корне

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

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

User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xml

Не стоит закрывать в robots.txt всё подряд. Если вы блокируете CSS, JS или изображения, поисковик может хуже понимать страницу. Это особенно заметно на сайтах с активной версткой и динамическими блоками.

Шаг 4. Уберите дубли в sitemap

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

Для WordPress-плагинов и тем это обычно надёжнее, чем пытаться закрыть уже опубликованные URL постфактум.

Пример кода: отключить лишние типы записей из sitemap

Если вы работаете без SEO-плагина или хотите точечно убрать отдельный тип записей из XML-карты WordPress, можно использовать фильтр wp_sitemaps_post_types. Это штатный механизм WordPress, а не выдуманный хук.

<?php
add_filter( 'wp_sitemaps_post_types', function( $post_types ) {
    if ( isset( $post_types['attachment'] ) ) {
        unset( $post_types['attachment'] );
    }

    if ( isset( $post_types['revision'] ) ) {
        unset( $post_types['revision'] );
    }

    return $post_types;
} );

Если нужно убрать конкретную таксономию, используйте фильтр wp_sitemaps_taxonomies:

<?php
add_filter( 'wp_sitemaps_taxonomies', function( $taxonomies ) {
    if ( isset( $taxonomies['post_tag'] ) ) {
        unset( $taxonomies['post_tag'] );
    }

    return $taxonomies;
} );

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

Как проверить, что всё работает

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

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

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

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

Если вместо 200 вы видите редирект, 403 или старый контент, сначала чините это, а уже потом проверяйте индексацию.

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

В robots.txt закрыт сам sitemap

Иногда в файле случайно появляется правило, которое блокирует путь к карте сайта. В этом случае поисковик может не увидеть XML, даже если он физически существует. Проверьте, что адрес sitemap не попадает под Disallow.

Редактируют не тот файл

На хостинге может лежать один robots.txt, а WordPress отдаёт виртуальный другой. Если изменения не применяются, проверьте корень сайта по FTP или через файловый менеджер и сравните ответ сервера с тем, что вы ожидали.

Кэш отдаёт старую версию

Это особенно заметно после правок в SEO-плагине. Очистка кэша сайта, CDN и браузера — обязательный шаг. Иначе вы будете смотреть на устаревший файл и думать, что настройка не сработала.

В sitemap попадают страницы, которые закрыты noindex

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

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

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

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

Если вы регулярно чистите сайт от дублей, служебных архивов и лишних метаданных, имеет смысл посмотреть в сторону инструментов, которые помогают централизованно управлять SEO- и техническими настройками, например Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wp-shablon.ru&utm_medium=article&utm_campaign=kak-nastroit-robots-txt-i-sitemap-v-wordpress-bez-konfliktov-s-seo-plaginom. Но даже с плагином логику sitemap и robots.txt всё равно нужно проверять вручную.

Когда лучше идти через код, а когда через плагин

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

Практическое правило простое: если вы не можете за пять минут объяснить, кто именно генерирует sitemap и где лежит robots.txt, значит конфигурация уже слишком сложная. Её стоит упростить до одного источника правды.

После внедрения изменений полезно сохранить короткий чек-лист в задаче или в README проекта:

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