Как настроить robots.txt и meta robots в WordPress без конфликтов

Проблема с индексацией в WordPress часто выглядит не как одна ошибка, а как набор мелких несостыковок: в robots.txt одно, в SEO-плагине другое, а в исходном коде страницы — третий вариант. В итоге поисковик может обходить лишние URL, не видеть нужные страницы или получать противоречивые сигналы по noindex и canonical.

Ниже — рабочая схема, которая помогает привести в порядок robots.txt и meta robots без лишних правок в ядре и без опасных «универсальных» шаблонов.

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

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

• в Search Console URL помечен как заблокирован robots.txt;
• в исходном коде страницы есть <meta name="robots" content="noindex">, хотя страница должна индексироваться;
• SEO-плагин и тема одновременно выводят разные директивы robots;
• в robots.txt закрыты служебные пути, но вместе с ними случайно закрыт важный раздел сайта;
• страницы пагинации, архивы или фильтры начинают массово выпадать из индекса без понятной причины.

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

Откройте три источника и сравните их между собой:

1. файл /robots.txt;
2. исходный код проблемной страницы;
3. настройки SEO-плагина, если он установлен.

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

Как выглядит правильная схема настройки

Удобнее разделить задачу на два уровня. robots.txt управляет обходом, а meta robots — индексацией конкретной страницы. Это не одно и то же.

Что обычно закрывают в robots.txt

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

Пример аккуратного robots.txt для типового сайта:

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

Здесь нет агрессивных запретов вроде Disallow: /. Такой вариант часто ломает обход сайта целиком и потом долго мешает переобходу страниц.

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

Шаг 1. Уберите дублирующие правила

Если SEO-плагин уже умеет управлять robots, не дублируйте его настройки в теме. Проверьте, не выводит ли тема собственный meta name="robots" через wp_head. Это частая причина, когда в коде страницы появляется сразу две директивы, и поисковик берёт не ту, которую вы ожидали.

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

<?php
add_filter( 'wp_robots', function( array $robots ) {
    if ( is_search() || is_404() ) {
        $robots['noindex'] = true;
        $robots['nofollow'] = true;
    }

    return $robots;
} );

Такой код лучше размещать в небольшом плагине или в mu-plugin, а не в файле темы. Тогда правило не исчезнет после обновления шаблона.

Шаг 2. Настройте индексацию служебных страниц

Для страниц поиска, архивов с пустым или слабым содержимым, а также для некоторых технических страниц обычно используют noindex. Но важно не закрыть всё подряд. Например, если у вас есть полезные архивы рубрик, их не стоит автоматически исключать только потому, что это архив.

Пример более точечной логики:

<?php
add_filter( 'wp_robots', function( array $robots ) {
    if ( is_search() ) {
        $robots['noindex'] = true;
        $robots['nofollow'] = true;
    }

    if ( is_author() && ! get_the_author_meta( 'description' ) ) {
        $robots['noindex'] = true;
    }

    return $robots;
} );

Здесь авторские архивы закрываются только если у автора нет описания. Это не универсальное правило, но оно показывает правильный принцип: решение должно зависеть от качества конкретной страницы.

Шаг 3. Проверьте sitemap и canonical

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

Проверьте, что:

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

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

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

1. Откройте страницу в браузере и посмотрите исходный код.
2. Убедитесь, что в HTML есть только одна логичная директива meta robots, если она вообще нужна.
3. Проверьте, что robots.txt доступен по адресу /robots.txt и отдает ожидаемые правила.
4. В Search Console отправьте URL на повторную проверку после обновления.
5. Если страница должна индексироваться, убедитесь, что она не закрыта ни в robots.txt, ни в noindex.

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

curl -I https://example.com/robots.txt
curl -s https://example.com/robots.txt
curl -s https://example.com/sample-page/ | grep -i robots

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

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

Закрыли страницу в robots.txt, а потом ждёте удаления из индекса

Это распространённая ошибка. Запрет обхода не всегда означает быстрое удаление URL из индекса. Если страница уже известна поисковику, лучше использовать noindex и оставить доступ к обходу, чтобы робот увидел директиву.

Два SEO-инструмента меняют одни и те же метатеги

Если одновременно активны SEO-плагин и код в теме, они могут конфликтовать. В результате в HTML появляются разные версии robots или canonical. Решение простое: оставьте один источник истины для каждой группы правил.

Закрыли не тот каталог

Особенно опасно закрывать /wp-content/ целиком. В этом каталоге лежат и изображения, и файлы темы, и скрипты. Если нужно ограничить только приватные загрузки, закрывайте конкретный подкаталог, а не весь путь.

Сделали noindex, но URL остался в sitemap

Это создаёт лишний шум для поисковика. После изменения индексации проверьте генератор sitemap и исключите оттуда закрытые страницы. Иначе вы сами отправляете роботу противоречивый список URL.

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

Если сайт большой, не пытайтесь решать всё через ручные правки в шаблоне. Лучше вынести точечные правила в отдельный мини-плагин или mu-plugin. Так вы:

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

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

Для ручной работы полезно держать короткий чек-лист перед публикацией:

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

Если после правок проблема не исчезла сразу, не спешите менять ещё десяток параметров. Сначала очистите кэш страницы и кэш CDN, затем повторно проверьте исходный HTML. Часто ошибка оказывается не в настройке, а в том, что поисковику и браузеру отдаются старые версии страницы.