Как настроить robots.txt в WordPress без закрытия важных страниц

В WordPress robots.txt часто правят по привычке: добавляют пару строк из чужой статьи, закрывают лишнее и в итоге случайно режут индексацию нужных URL. Проблема в том, что robots.txt не удаляет страницы из поиска сам по себе, а только управляет обходом. Поэтому здесь важны не «красивые правила», а понятная схема: что именно вы хотите скрыть от бота, что оставить доступным и как потом проверить, что файл не мешает SEO.

Когда robots.txt действительно нужен

Файл полезен, если нужно ограничить обход технических разделов, которые не должны тратить краулинговый бюджет и не несут ценности для поиска. В WordPress это обычно служебные директории, результаты внутреннего поиска, некоторые параметры URL и файлы, которые не должны регулярно обходиться роботами. Но если задача — убрать страницу из индекса, одного robots.txt недостаточно: для этого чаще нужен noindex, canonical или корректная настройка плагина SEO.

Что можно закрывать, а что лучше не трогать

Безопаснее всего ограничивать доступ к техническим URL, которые не являются контентом. Например, к служебным папкам плагинов, к результатам поиска по сайту и к отдельным параметрам, если они создают мусорные обходы. А вот закрывать CSS, JS или изображения обычно не стоит: поисковики должны видеть страницу так же, как пользователь, иначе можно получить проблемы с рендерингом и оценкой качества.

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

Перед правкой файла проверьте, есть ли вообще проблема с обходом или индексацией. Частая ошибка — менять robots.txt «на всякий случай», не понимая, какие URL уже попали в индекс и почему. Начните с просмотра текущего файла по адресу /robots.txt и списка страниц в Google Search Console, если она подключена. Если в отчётах видны URL с параметрами, внутренний поиск или служебные разделы, тогда есть смысл настраивать правила точечно.

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

Мини-чек-лист перед изменением файла

• Проверьте текущий robots.txt в браузере.
• Сверьте, какие URL реально индексируются, а какие только обходятся.
• Убедитесь, что не закрываете CSS, JS и изображения.
• Поймите, нужен ли именно запрет обхода или запрет индексации.
• Сохраните текущую версию файла, чтобы быстро откатиться.

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

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

Вариант 1: статический robots.txt в корне сайта

Если у вас есть доступ к корню сайта, создайте или отредактируйте файл robots.txt. Это самый прозрачный вариант: вы точно знаете, что отдает сервер.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /wp-json/
Sitemap: https://example.com/sitemap_index.xml

Здесь важно не копировать правила вслепую. Например, Disallow: /wp-json/ может быть лишним, если у вас есть фронтенд, завязанный на REST API. А Disallow: /?s= сработает не на все варианты поиска, если тема или плагин формируют другой шаблон URL. Поэтому после правки нужно проверить реальные адреса.

Вариант 2: через фильтр robots_txt

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

add_filter('robots_txt', function ($output, $public) {
    $output .= "\nUser-agent: *\n";
    $output .= "Disallow: /wp-admin/\n";
    $output .= "Allow: /wp-admin/admin-ajax.php\n";
    $output .= "Disallow: /search/\n";
    $output .= "Sitemap: https://example.com/sitemap_index.xml\n";

    return $output;
}, 10, 2);

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

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

Не закрывайте в лоб все URL с параметрами, если не понимаете, как они используются. Не добавляйте десятки строк Disallow для каждого найденного мусорного адреса. И не рассчитывайте, что robots.txt удалит уже проиндексированные страницы: если URL уже в индексе, он может оставаться там довольно долго, пока поисковик не увидит другие сигналы.

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

После изменения файла откройте /robots.txt в браузере и убедитесь, что сервер отдает именно ту версию, которую вы ожидали. Затем проверьте несколько реальных URL: служебный раздел должен быть закрыт для обхода, а важные страницы — доступны. Если используете Google Search Console, отправьте на проверку отдельные URL и посмотрите, как бот интерпретирует правила.

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

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

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

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

Закрыли то, что должно индексироваться

Самая неприятная ошибка — запретить обход страниц, которые должны участвовать в поиске. Это часто случается, когда в robots.txt добавляют слишком широкие правила вроде Disallow: / для теста и потом забывают убрать. Если страница уже выпала из индекса, проверьте, не мешает ли ей robots.txt, и снимите запрет, если это важный контент.

Путают robots.txt и noindex

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

Закрывают ресурсы темы

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

Дублируют правила в нескольких местах

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

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

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

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

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

Когда лучше не править robots.txt руками

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

Практический ориентир простой: если вы не можете объяснить, зачем нужна каждая строка в robots.txt, правило, скорее всего, лишнее. Для WordPress это особенно важно, потому что многие «проблемные» URL лучше решаются не запретом обхода, а настройкой индексации, canonical или исправлением генерации ссылок на уровне темы и плагинов.