В WordPress robots.txt часто правят «на глаз»: закрывают всё подряд, потом удивляются, почему в индексе остаются дубли, а нужные страницы выпадают из поиска. На практике задача обычно проще: убрать из обхода служебные URL, не мешая поисковикам видеть контент, sitemap и важные разделы.
Ниже — рабочая схема для типичного сайта на WordPress: что проверять, как собрать robots.txt без лишних запретов и как убедиться, что изменения действительно сработали.
Когда robots.txt нужен, а когда проблема не в нём
Если в поиске всплывают страницы вида /wp-admin/, /wp-login.php, /feed/, параметры сортировки, внутренний поиск или архивы с пустым содержимым, robots.txt помогает сократить мусорный обход. Но если у вас уже есть страницы в индексе, robots.txt сам по себе их не удалит. Для этого нужны noindex, редиректы или удаление URL с сайта.
Типичные симптомы
- в Search Console растёт число «Просканировано, но не проиндексировано»;
- в выдаче есть URL с параметрами
?replytocom=,?s=,?ampили сортировкой; - поисковик тратит обход на служебные разделы, а новые статьи индексируются медленно;
- в логах видно частые запросы к
/wp-json/,/xmlrpc.phpили страницам авторов, которые вам не нужны в поиске.
Что проверять до правки robots.txt
Сначала посмотрите, какой robots.txt сейчас отдаёт сайт. В WordPress он может быть виртуальным, если файла в корне нет. Откройте /robots.txt в браузере и проверьте, нет ли там старых правил от темы, плагина или хостинга.
Дальше проверьте три вещи:
- есть ли у сайта XML sitemap и указан ли он в robots.txt;
- не закрыты ли случайно CSS, JS или изображения, которые нужны для рендеринга;
- не запрещены ли разделы, которые должны индексироваться, например рубрики, записи или страницы.
Если у вас стоит SEO-плагин, он может генерировать robots.txt сам. В этом случае править файл на сервере бессмысленно, пока не понимаете, кто именно его отдаёт.
Пошаговая настройка robots.txt в WordPress
Ниже — консервативный вариант. Он не пытается «ускорить SEO» магией, а просто убирает очевидный мусор и оставляет поисковику путь к контенту.
1. Сформируйте базовый файл
Для обычного сайта можно начать с такого шаблона:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /cgi-bin/
Disallow: /?s=
Disallow: /*?replytocom=
Disallow: /*?utm_
Disallow: /feed/
Sitemap: https://example.com/sitemap_index.xmlЗдесь важно не переусердствовать. Например, /wp-admin/ закрывают почти всегда, но admin-ajax.php обычно оставляют доступным, потому что его используют фронтенд-скрипты и некоторые плагины.
2. Не закрывайте лишнее
Частая ошибка — запретить /wp-content/ целиком. Так делать не нужно: внутри лежат изображения, стили и скрипты. Если поисковик не сможет нормально загрузить ресурсы, он хуже оценит страницу.
Ещё одна плохая идея — закрывать весь /wp-json/ без понимания последствий. Если у вас блоки редактора, headless-интеграции или плагины, которые используют REST API, можно сломать часть функциональности. Закрывать этот путь стоит только если вы точно знаете, что он не нужен для публичной части сайта.
3. Добавьте sitemap
Если sitemap не указан, поисковик всё равно может его найти, но лучше не надеяться на это. В robots.txt оставляют одну явную строку Sitemap: с актуальным адресом карты сайта.
Если у вас несколько sitemap, укажите основной индексный файл, например sitemap_index.xml. Это стандартный и понятный вариант для большинства SEO-плагинов.
Как сделать это через код, если robots.txt генерируется WordPress
Если нужен контроль без ручного редактирования файла, используйте фильтр robots_txt. Это безопаснее, чем править что-то в корне сайта, когда robots.txt виртуальный.
<?php
add_filter( 'robots_txt', function( $output, $public ) {
$lines = array(
'User-agent: *',
'Disallow: /wp-admin/',
'Allow: /wp-admin/admin-ajax.php',
'Disallow: /wp-login.php',
'Disallow: /?s=',
'Disallow: /*?replytocom=',
'Sitemap: ' . home_url( '/sitemap_index.xml' ),
);
return implode( "\n", $lines ) . "\n";
}, 10, 2 );Этот вариант полезен, если вы хотите держать правила в теме или в небольшом mu-plugin. Но если сайт обслуживает SEO-плагин, сначала проверьте, не перезапишет ли он ваш вывод. В таком случае лучше выбрать один источник правды: либо плагин, либо код.
Сравнение подходов: файл, плагин или код
| Способ | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Ручной robots.txt в корне | Простой сайт, нет конфликтов | Понятно и быстро | Легко забыть обновить после изменений |
| Через SEO-плагин | Нужно управлять sitemap и правилами из админки | Удобно для редактора | Можно случайно задать слишком жёсткие запреты |
Через robots_txt в коде | Нужна повторяемость и контроль | Версионируется в Git | Нужно следить за конфликтами с плагинами |
Проверка результата после внедрения
После правки не ограничивайтесь открытием файла в браузере. Проверьте поведение поисковика и фактическую отдачу URL.
- Откройте
/robots.txtи убедитесь, что файл отдаёт нужные правила без дублей строк. - Проверьте, что
sitemap_index.xmlдоступен по указанному адресу. - В Google Search Console используйте проверку URL для нескольких страниц: главной, записи, рубрики и служебного URL.
- Посмотрите, не пропали ли из обхода важные ресурсы: CSS, JS, изображения.
Если у вас есть доступ к серверным логам, полезно посмотреть, как боты ходят по сайту после изменения. Это особенно заметно на больших проектах: иногда запрет одного шаблона убирает тысячи лишних запросов, а иногда почти ничего не меняет, потому что проблема была в параметрах URL, а не в robots.txt.
Частые ошибки и как их исправить
Закрыли слишком много
Симптом: страницы есть на сайте, но поисковик перестал их нормально сканировать. Причина обычно в запрете каталогов с ресурсами или в слишком широких масках вроде Disallow: / для всех ботов. Исправление простое: верните доступ к публичным разделам и проверьте, что не закрыты стили, скрипты и изображения.
Ожидали удаления страниц из индекса
Robots.txt не удаляет уже известные URL из выдачи. Если страница должна исчезнуть, используйте noindex, 301-редирект или отдачу 404/410 в зависимости от сценария.
Смешали несколько источников robots.txt
Так бывает, когда файл лежит в корне, а SEO-плагин тоже генерирует правила. В итоге вы видите не тот результат, который ожидаете. Оставьте один источник и проверьте, кто реально формирует ответ сервера.
Закрыли параметры, которые нужны сайту
Иногда в robots.txt запрещают все URL с вопросительным знаком, а потом ломают фильтры, пагинацию или внутренний поиск. Если параметр нужен для пользователей, не закрывайте его вслепую. Лучше точечно ограничить только те шаблоны, которые создают мусор.
Практические советы по безопасности и производительности
Robots.txt не защищает сайт от атак. Если цель — снизить нагрузку и убрать шум, он помогает только частично. Для безопасности важнее закрыть wp-login.php дополнительной защитой, ограничить попытки входа и следить за обновлениями.
Для производительности полезно не только править robots.txt, но и убрать причины появления дублей: параметры сортировки, архивы без контента, лишние авторские страницы, технические теги и пустые таксономии. Если на сайте много мусорных URL, иногда быстрее сначала почистить структуру, а уже потом настраивать robots.txt.
Если нужен более широкий набор технических правок — от дублей до чистки служебных элементов — удобнее собрать это в одном инструменте, а не держать десяток разрозненных сниппетов. Но даже в этом случае robots.txt стоит проверять вручную: автоматизация не отменяет базовую валидацию.
Короткий чек-лист перед публикацией
- robots.txt открывается по адресу
/robots.txt; - в файле есть только нужные запреты;
- не закрыты CSS, JS и изображения;
- указан актуальный sitemap;
- важные страницы доступны для обхода;
- проверка URL в Search Console не показывает блокировку там, где её быть не должно.
Если после правки сайт стал хуже индексироваться, откатите изменения и сравните старый и новый robots.txt построчно. В таких задачах выигрывает не самый строгий файл, а тот, который не мешает поисковику видеть нормальный контент и не создаёт лишних ограничений.