Как настроить robots.txt в WordPress, чтобы закрыть дубли и системные страницы

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

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

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

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

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

• в индексе появляются /wp-admin/, /wp-login.php, /wp-json/ или страницы поиска по сайту;
• в отчётах видны URL с параметрами сортировки, фильтров или UTM, которые не должны индексироваться;
• поисковик часто ходит в /wp-content/plugins/, /wp-content/themes/ или в служебные файлы;
• в логах сервера много запросов к архивам, которые не несут ценности для поиска.

Что не стоит закрывать через robots.txt

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

Что обычно закрывают в WordPress

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

Для WordPress обычно имеет смысл закрывать:

• /wp-admin/ — кроме admin-ajax.php, если он нужен фронтенду;
• /wp-login.php — это не защита, но лишний обход не нужен;
• /wp-content/plugins/ и /wp-content/themes/ — если сервер и так отдаёт файлы напрямую;
• внутренний поиск вида ?s=;
• служебные параметры сортировки и фильтрации, если они создают дубли;
• архивы автора, дат и тегов — только если вы осознанно решили их не индексировать.

Пошаговая настройка robots.txt

Шаг 1. Проверьте, какой robots.txt сейчас отдаётся

Откройте https://ваш-домен.ru/robots.txt. В WordPress этот файл может быть виртуальным: если физического файла нет, WordPress отдаёт его динамически. Это важно, потому что правка в корне сайта не всегда сработает, если файл подменяется плагином или серверной конфигурацией.

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

Шаг 2. Соберите минимально безопасный набор правил

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

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /search/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

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

Здесь важно не копировать правила вслепую. Например, запрет /wp-content/themes/ не всегда нужен, если вы хотите, чтобы поисковик видел CSS и JS для корректного рендеринга. Обычно поисковики и так умеют обходить статические ресурсы, но если вы закрываете слишком много, можно получить проблемы с отрисовкой страницы в инструментах проверки.

Шаг 3. Добавьте правила только под реальные дубли

Если на сайте есть параметры сортировки или фильтров, не закрывайте весь сайт по маске только потому, что где-то появился дубль. Сначала посмотрите, какие URL реально создаются. Например, если дубли идут через ?orderby= или ?filter_, можно точечно ограничить обход этих вариантов. Но в robots.txt маски работают не так гибко, как многие ожидают, поэтому иногда лучше решать вопрос на уровне канонических ссылок и редиректов.

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

Пример: как отдать свой robots.txt через код

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

add_filter('robots_txt', function ($output, $public) {
    $lines = [
        'User-agent: *',
        'Disallow: /wp-admin/',
        'Allow: /wp-admin/admin-ajax.php',
        'Disallow: /wp-login.php',
        'Disallow: /search/',
        'Sitemap: ' . home_url('/sitemap_index.xml'),
    ];

    return implode("\n", $lines) . "\n";
}, 10, 2);

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

Когда код лучше файла

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

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

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

1. Откройте /robots.txt и убедитесь, что там именно тот текст, который вы ожидаете.
2. Проверьте, не закрыт ли /wp-admin/admin-ajax.php, если фронтенд использует AJAX-запросы.
3. В Search Console запустите проверку отдельных URL, которые должны быть доступны для обхода.
4. Посмотрите отчёт по страницам, которые были исключены из-за запрета в robots.txt.
5. Если сайт использует CSS/JS из нестандартных директорий, проверьте рендер страницы в инструменте проверки URL.

Хороший практический тест — открыть страницу, которая должна индексироваться, и убедиться, что в её HTML есть корректный canonical, а сам URL не заблокирован правилами robots.txt.

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

Слишком широкий Disallow

Ошибка выглядит так: Disallow: / или слишком общий запрет на весь сайт. Это полностью останавливает обход. Если такое правило попало в продакшен, поисковик перестаёт нормально обновлять данные по страницам. Исправление простое: убрать глобальный запрет и оставить только точечные технические разделы.

Закрыли то, что должно быть доступно

Часто случайно закрывают /wp-content/uploads/ или директории со стилями и скриптами. Это уже влияет не только на SEO, но и на отображение сайта в поиске. Если после правки в тесте URL перестал рендериться корректно, проверьте, не заблокированы ли статические ресурсы.

Путают robots.txt и noindex

Если страница должна открываться для пользователя, но не попадать в индекс, robots.txt не всегда подходит. Для таких случаев используйте noindex или корректные заголовки. Robots.txt — это про обход, а не про удаление из индекса.

Забывают про sitemap

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

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

Robots.txt не защищает сайт от атак. Он лишь подсказывает роботам, куда не ходить. Поэтому не рассчитывайте, что запрет /wp-login.php в robots.txt скроет админку. Для безопасности нужны отдельные меры: ограничение попыток входа, двухфакторная аутентификация, актуальные обновления и нормальная политика паролей.

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

Если вам нужно не только закрыть дубли, но и почистить сайт от SEO-мусора, дублей и лишних технических сущностей, иногда удобнее делать это через специализированный набор настроек вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае сначала проверьте, какие правила реально нужны именно вашему сайту, а не включайте всё подряд.

Короткий чек-лист перед публикацией

• robots.txt открывается по адресу /robots.txt и отдаёт нужный текст;
• не закрыт admin-ajax.php, если он используется на фронтенде;
• в файле указан актуальный sitemap;
• не заблокированы CSS и JS, нужные для рендеринга;
• в Search Console нет массового роста ошибок обхода после изменения;
• дубли решаются не только robots.txt, но и canonical/редиректами, если это требуется.

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