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

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

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

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

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

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

• Можно закрывать: служебные страницы поиска, параметры сортировки, внутренние фильтры, страницы авторизации и админки.
• Осторожно: архивы, теги, пагинация, медиа-страницы. Их закрывают только если есть понятная причина и вы понимаете последствия.
• Не закрывайте: CSS, JS и изображения, если тема или плагины отдают их из стандартных путей и поисковику нужно видеть рендер страницы.

Диагностика проблемы перед правкой

Перед изменением robots.txt проверьте, что именно вы хотите исправить. Частая ошибка — закрыть всё подряд, хотя проблема была в дублях мета-тегов, canonical или параметрах URL. Сначала посмотрите, какие адреса реально обходятся ботом и какие из них создают шум.

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

• Есть ли в индексе страницы с параметрами вроде ?sort=, ?filter=, ?replytocom=.
• Не закрыты ли случайно важные разделы в текущем robots.txt.
• Не отдаёт ли сайт отдельный robots.txt через плагин кеша, SEO-плагин или серверную настройку.
• Нет ли конфликта между robots.txt и мета-тегом noindex на странице.

Если у вас уже есть SEO-плагин, сначала откройте его генератор robots.txt. Иногда файл создаётся не в корне сайта вручную, а через интерфейс плагина, и правка «на сервере» просто не сработает.

Какой robots.txt подходит для типичного WordPress-сайта

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

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /search/
Disallow: /feed/
Disallow: /comments/feed/

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

Здесь есть важный нюанс: строка Allow: /wp-admin/admin-ajax.php нужна, чтобы не ломать фронтенд-функции, которые обращаются к AJAX-обработчику. А вот закрытие /wp-login.php не делает вход «безопаснее» само по себе — это лишь убирает страницу из обхода, но не защищает от атак.

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

Шаг 1. Определите, где файл должен редактироваться

Если сайт использует SEO-плагин, проверьте его настройки. Если файла нет в интерфейсе, создайте обычный robots.txt в корне сайта. Для WordPress это стандартный путь: https://site.ru/robots.txt. Важно, чтобы сервер отдавал именно этот файл, а не страницу 404 или редирект на главную.

Шаг 2. Уберите лишние запреты

Не копируйте бездумно старые шаблоны, где закрыты /wp-content/, /wp-includes/ или даже весь сайт через Disallow: /. Такие правила часто встречаются в устаревших примерах и ломают индексацию ресурсов и контента.

Шаг 3. Добавьте только нужные служебные ограничения

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

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

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

Сравнение подходов: плагин, ручной файл или серверная настройка

Для обычного WordPress-сайта чаще всего достаточно ручного файла или настройки в SEO-плагине. Если у вас уже стоит плагин для технической оптимизации, например Clearfy Pro, проверьте, не дублирует ли он генерацию robots.txt и sitemap. В таких случаях важно не смешивать несколько источников правды.

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

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

Чек-лист проверки

• Откройте /robots.txt в браузере и убедитесь, что файл доступен без редиректов и ошибок.
• Проверьте, что в нём нет случайного Disallow: /.
• Убедитесь, что sitemap указан правильным URL.
• Проверьте несколько важных страниц в поисковой консоли на предмет обхода и индексации.
• Посмотрите серверные логи, если нужно понять, продолжает ли бот ходить по закрытым URL.

Если у вас есть доступ к Google Search Console, используйте проверку URL и отчёты по индексированию. Для Яндекса логика аналогичная: важно смотреть не только наличие файла, но и то, как поисковик воспринимает конкретные адреса.

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

Закрыли CSS и JS вместе с контентом

Это происходит, когда в robots.txt добавляют слишком широкие правила для /wp-content/ или /wp-includes/. Исправление простое: уберите широкие запреты и проверьте, что стили и скрипты снова доступны для обхода.

Ожидали, что robots.txt удалит страницу из индекса

Не удалит. Если URL уже известен поисковику, нужен другой механизм: noindex, удаление страницы, корректный редирект или ответ 404/410 в зависимости от ситуации.

Сделали запрет на поиск, но в индексе остались старые URL

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

Проверяли не тот файл

Иногда на хостинге лежит один robots.txt, а WordPress или SEO-плагин отдает другой. Всегда проверяйте именно публичный URL /robots.txt, а не файл в файловом менеджере.

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

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

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

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