Если в WordPress в индекс попадают служебные разделы, дубли и технические URL, часто первым делом правят именно robots.txt. Это полезный файл, но только если понимать его границы: он не удаляет страницы из индекса сам по себе, а лишь подсказывает роботам, куда не ходить.
Ниже — рабочий сценарий для типичного сайта на WordPress: что можно закрыть, что трогать нельзя, как внести правила без конфликта с плагинами и как проверить, что файл действительно отрабатывает.
Когда robots.txt действительно нужен
Сначала стоит понять, решает ли robots.txt вашу задачу. Он подходит, если нужно ограничить обход технических URL: служебных каталогов, внутренних поисков, страниц предпросмотра, некоторых параметров и файлов, которые не должны тратить краулинговый бюджет. Но если страница уже в индексе, одно только закрытие в robots.txt не гарантирует её исчезновение из поиска.
Типичные случаи, где файл полезен:
- в индекс и логи роботов попадают технические разделы темы или плагинов;
- поисковые роботы тратят время на мусорные URL с параметрами;
- нужно ограничить обход медиа-каталогов или системных путей, которые не несут ценности;
- на сайте есть отдельные служебные директории, не предназначенные для обхода.
Что не стоит закрывать без проверки
Не закрывайте в robots.txt то, что должно участвовать в индексации: важные записи, рубрики, страницы, изображения, CSS и JS, если они нужны для корректного рендеринга. Также осторожно относитесь к /wp-content/ целиком: это слишком грубо и часто ломает доступ роботов к стилям, скриптам и медиа.
Диагностика: какие URL реально создают проблему
Перед правкой файла посмотрите, какие адреса уже светятся в поиске и в логах. На практике полезно проверить три источника: отчёт по страницам в Google Search Console, серверные логи и ручной обход сайта через поиск по оператору site:.
Если у вас есть доступ к логам, ищите частые обращения к служебным путям. Примерно так:
grep -E "robots|wp-json|feed|search|preview|trackback|xmlrpc" access.log | tail -n 50Это не универсальная команда для всех серверов, но она помогает быстро увидеть, что именно чаще всего запрашивают боты. Если логов нет, ориентируйтесь на Search Console: там обычно видно, какие URL обнаружены, но не должны индексироваться.
Проверка перед изменениями
- есть ли уже
robots.txtв корне сайта; - не создаёт ли его плагин SEO или кеширования;
- не закрыты ли случайно важные разделы через
Disallow; - не используется ли отдельная карта сайта, которую нужно оставить доступной;
- не конфликтуют ли правила с директивами для других поисковых систем.
Как собрать безопасный robots.txt для WordPress
Базовый файл должен быть коротким и понятным. Для большинства сайтов достаточно разрешить обход нужных разделов и закрыть только то, что действительно служебное. Ниже пример, который можно адаптировать под свой проект.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /trackback/
Disallow: /feed/
Disallow: /comments/feed/
Disallow: /wp-json/
Sitemap: https://example.com/sitemap_index.xmlЗдесь есть важный нюанс: /wp-admin/ закрывают почти всегда, но admin-ajax.php оставляют доступным, потому что его используют темы и плагины. Если у вас поисковая страница формируется не как /search/, а через параметр ?s=, лучше закрыть оба варианта, но только после проверки, как именно устроен поиск на сайте.
Если нужно закрыть отдельный каталог
Иногда на сайте есть служебная папка, например с выгрузками, тестовыми файлами или внутренними документами. Тогда правило должно быть точечным:
User-agent: *
Disallow: /private-files/
Disallow: /tmp/
Не добавляйте в файл всё подряд. Чем больше исключений, тем выше шанс случайно закрыть нужный ресурс или создать путаницу при дальнейшей поддержке.
Кодом или через плагин: что выбрать
Если сайт небольшой и файл нужен один раз, удобнее отредактировать robots.txt вручную через FTP, хостинг-панель или SEO-плагин. Если же правила должны формироваться автоматически, лучше использовать код в дочерней теме или мини-плагине. Это полезно, когда нужно подставлять карту сайта, учитывать мультиязычность или не дать редакторам случайно сломать файл.
| Подход | Когда подходит | Минус |
|---|---|---|
| Ручной файл | Небольшой сайт, редкие правки | Легко перезаписать при миграции или настройке плагина |
| SEO-плагин | Нужен интерфейс и карта сайта | Может добавлять свои правила и конфликтовать с ручной логикой |
| Код в теме/плагине | Нужна стабильная генерация и контроль | Требует аккуратной поддержки |
Если вы хотите генерировать файл программно, используйте фильтр robots_txt. Это штатный механизм WordPress, а не выдуманный хук. Пример ниже добавляет свои правила и не ломает стандартный вывод:
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 .= "Disallow: /trackback/\n";
return $output;
}, 10, 2);Такой вариант удобен, если вы хотите держать правила под контролем в репозитории. Но если на сайте уже работает SEO-плагин, сначала проверьте, не генерирует ли он robots.txt сам. Иначе получится два источника правды.
Пошаговая настройка без лишнего риска
- Сделайте текущую копию
robots.txtили сохраните его содержимое. - Проверьте, кто сейчас отдаёт файл: сервер, WordPress или SEO-плагин.
- Соберите минимальный набор правил, которые действительно нужны.
- Не закрывайте CSS, JS и изображения без отдельной проверки.
- Добавьте карту сайта только в том формате, который реально используется на сайте.
- После правки проверьте файл через браузер и инструменты для вебмастеров.
Если вы редактируете файл вручную, следите за тем, чтобы он лежал в корне сайта и открывался по адресу https://site.ru/robots.txt. Если адрес отдаёт 404, значит файл не там, где нужно, или его перехватывает серверная конфигурация.
Как проверить, что всё сработало
Проверка должна быть не формальной, а практической. Откройте /robots.txt в браузере и убедитесь, что в ответе видны нужные директивы. Затем проверьте несколько URL, которые вы закрывали: они должны быть недоступны для обхода, но при этом сам сайт не должен потерять важные ресурсы.
Что стоит проверить отдельно:
- открывается ли карта сайта по указанному адресу;
- не закрыт ли случайно
/wp-admin/admin-ajax.php; - не пропали ли стили и скрипты из публичных страниц;
- не изменилось ли поведение внутреннего поиска;
- не появились ли ошибки обхода в Search Console.
Если нужно быстро убедиться в ответе сервера, можно использовать curl:
curl -I https://example.com/robots.txtВ ответе должен быть 200 OK. Если вместо этого приходит редирект, 403 или 404, сначала исправьте серверную часть, а уже потом правьте содержимое файла.
Частые ошибки и как их исправить
Закрыли слишком много
Самая частая ошибка — заблокировать целые каталоги, не проверив, что внутри лежат нужные ресурсы. Особенно опасно закрывать /wp-content/ или папки темы целиком. Исправление простое: уберите грубое правило и замените его точечным исключением для конкретного пути.
Ожидали, что robots.txt удалит страницу из индекса
Файл не удаляет уже проиндексированные URL. Он только ограничивает обход. Если страница уже в поиске, обычно нужно сочетать noindex, корректный статус ответа или удаление страницы из сайта, а затем дождаться переобхода.
Конфликт с SEO-плагином
Если плагин сам генерирует robots.txt, ручная правка в корне может не дать эффекта. В таком случае либо отключайте генерацию в плагине, либо редактируйте файл через его интерфейс. Иначе правила будут меняться непредсказуемо после обновлений.
Сломали карту сайта
Иногда карту сайта закрывают вместе с техническими разделами, а потом удивляются падению обхода. Проверьте, что Sitemap: указывает на реальный URL, который доступен без авторизации и отдаёт 200.
Безопасность и производительность: что важно помнить
robots.txt не защищает данные. Если каталог действительно содержит чувствительные файлы, его нужно закрывать на уровне сервера или убирать из публичной директории, а не надеяться на директиву для роботов. Для производительности же файл полезен только как средство сокращения лишнего обхода, но не как способ ускорить сам сайт.
Если на проекте много технических дублей и служебных страниц, имеет смысл смотреть шире: корректировать канонические URL, чистить лишние архивы, проверять карту сайта и настройки индексации в SEO-плагине. В некоторых случаях удобнее собрать это в одном месте, например через Clearfy Pro, если вам нужен набор инструментов для удаления дублей и технической чистки сайта: https://wpshop.ru/plugins/clearfy.
Но даже с плагином принцип не меняется: сначала диагностика, потом точечные правила, затем проверка ответа сервера и поведения роботов. Это тот случай, где аккуратность важнее количества директив.