В WordPress robots.txt часто правят по остаточному принципу: добавляют пару строк из старой статьи и надеются, что поисковик сам разберётся. На практике это заканчивается либо лишними страницами в индексе, либо блокировкой того, что должно сканироваться. Если задача — убрать из обхода служебные URL, не трогая важные разделы, лучше идти от конкретных сценариев: что именно закрываем, зачем и как потом проверяем результат.
Какие страницы WordPress обычно стоит закрывать
robots.txt нужен не для «улучшения SEO вообще», а для управления обходом. Он помогает подсказать роботам, что не нужно тратить краулинговый бюджет на технические адреса. В WordPress чаще всего речь идёт о таких URL:
/wp-admin/— административная часть сайта;/wp-login.php— страница входа;/wp-json/— REST API, если он не нужен для публичного обхода;/search/или параметры поиска, если на сайте есть внутренний поиск с индексируемыми результатами;- служебные файлы и каталоги плагинов, если они случайно доступны по прямым URL.
При этом важно не путать запрет на обход и запрет на индексацию. robots.txt не удаляет уже известные страницы из индекса мгновенно и не гарантирует, что URL не появится в поиске. Если страница уже попала в индекс, иногда нужен ещё и noindex на самой странице или корректный редирект/удаление.
Диагностика: что именно мешает сейчас
Перед правкой robots.txt стоит понять, какая проблема у вас на самом деле. Это не всегда «лишние страницы в индексе». Иногда сайт просто отдаёт мусорные URL в обход, а иногда поисковик видит дубли из-за параметров, пагинации или внутренних поисковых страниц.
Проверьте текущий robots.txt
Откройте https://ваш-домен.ru/robots.txt и посмотрите, что там уже есть. У WordPress файл часто генерируется автоматически, если физического файла нет в корне. Это значит, что правки через FTP в пустом корне могут не сработать так, как ожидается.
Если robots.txt уже существует, проверьте:
- нет ли там слишком широких запретов вроде
Disallow: /; - не закрыт ли
/wp-content/uploads/без причины; - не дублируются ли правила от темы, плагина и ручной правки;
- не закрыт ли
/wp-json/, если он нужен для фронтенда или интеграций.
Проверьте, какие URL реально индексируются
В Google Search Console откройте отчёт по страницам и найдите служебные адреса, которые не должны попадать в поиск. Если там есть результаты поиска, архивы с параметрами, тестовые страницы или технические разделы, robots.txt сам по себе может быть недостаточен. В таком случае сначала решают источник дублирования, а уже потом ограничивают обход.
Рабочая схема настройки robots.txt
Для большинства сайтов достаточно не пытаться «запретить всё», а аккуратно закрыть только то, что не должно сканироваться. Ниже — базовый вариант, который можно адаптировать под конкретный проект.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /search/
Disallow: /?s=
Disallow: /*?s=
Sitemap: https://example.com/sitemap_index.xmlЗдесь есть несколько важных моментов. /wp-admin/ закрывается почти всегда, но admin-ajax.php лучше оставить доступным, потому что его используют темы и плагины на фронтенде. Строки с поиском нужны только если у вас действительно есть индексируемые поисковые URL. Если поиск на сайте не создаёт отдельных страниц, эти правила можно убрать.
Если нужен более точный контроль
Иногда удобнее не редактировать файл руками, а формировать его через код, особенно если сайт развёрнут на нескольких окружениях. В WordPress можно отдать свой robots.txt через фильтр robots_txt.
<?php
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: https://example.com/sitemap_index.xml',
];
return implode("\n", $lines) . "\n";
}, 10, 2);Такой подход удобен, если вы хотите хранить правила в теме или в небольшом mu-plugin и не зависеть от ручного редактирования файла на сервере. Но у него есть минус: при ошибке в коде можно сломать выдачу robots.txt целиком. Поэтому перед выкладкой проверяйте файл в браузере и на тестовом окружении.
Сравнение подходов: файл, код или плагин
| Подход | Когда подходит | Плюсы | Компромисс |
|---|---|---|---|
| Ручной robots.txt в корне | Небольшой сайт, редкие правки | Просто, прозрачно, не требует кода | Можно забыть про обновление и сломать правила при деплое |
Фильтр robots_txt | Нужна управляемость через код | Версионирование, удобно для нескольких окружений | Ошибки в коде влияют на генерацию файла |
| SEO-плагин | Нужно править без разработчика | Удобно для редакторов и контент-менеджеров | Лишняя зависимость от интерфейса плагина и его логики |
Если у вас уже стоит SEO-плагин и он умеет управлять robots.txt, не обязательно дублировать правила ещё и в корне. Достаточно выбрать один источник правды. Иначе через пару месяцев вы получите конфликт между физическим файлом, настройками плагина и ожиданиями команды.
Пошаговое решение без лишнего риска
- Соберите список URL, которые не должны обходиться: админка, логин, поиск, технические параметры.
- Проверьте, нет ли среди них страниц, которые реально нужны для фронтенда или интеграций.
- Составьте минимальный набор правил, без широких запретов.
- Добавьте sitemap в robots.txt, если он у вас есть и доступен по стабильному адресу.
- Опубликуйте изменения и сразу проверьте ответ по
/robots.txt. - В Search Console отправьте важные URL на повторную проверку, если до этого они уже были в индексе.
Как проверить, что настройка сработала
Проверка должна быть не формальной, а по факту. Откройте /robots.txt в браузере и убедитесь, что там отображаются нужные директивы. Затем проверьте несколько URL вручную:
/wp-admin/должен быть закрыт для обхода;/wp-admin/admin-ajax.phpдолжен оставаться доступным;/wp-login.phpдолжен быть запрещён;- страница поиска, если она есть, должна попадать под нужное правило;
- sitemap должен открываться по указанному адресу.
Если используете Google Search Console, проверьте отчёт по страницам и инструмент проверки URL. Важно смотреть не только на robots.txt, но и на то, как поисковик видит конкретный адрес. Иногда URL уже исключён из обхода, но всё ещё висит в индексе как известный без сканирования.
Частые ошибки и как их исправить
Слишком широкое правило Disallow
Ошибка выглядит безобидно: Disallow: / или запрет на целый каталог, который нужен для сайта. В результате поисковик перестаёт обходить важные страницы. Исправление простое: оставьте только точечные запреты и проверьте, что не задеты CSS, JS и публичные разделы.
Запретили то, что нужно фронтенду
Частая история — закрывают /wp-json/ или /wp-admin/admin-ajax.php, а потом ломаются блоки, формы, фильтры или редактор. Если не уверены, сначала проверьте, какие запросы делает тема и плагины. Для REST API запрет нужен не всегда, а для admin-ajax.php чаще всего не нужен.
Дублируют правила в нескольких местах
Когда robots.txt правят и в корне, и через плагин, и через код, итоговый файл становится непредсказуемым. Оставьте один источник генерации. Если нужен ручной файл, уберите автоматическую генерацию из плагина или наоборот.
Путают robots.txt и noindex
Если страница уже в индексе, robots.txt не всегда поможет быстро убрать её оттуда. Для удаления из поиска используйте noindex, редирект или удаление страницы с корректным статусом ответа. robots.txt — это про обход, а не про гарантированное исключение из индекса.
Безопасность и производительность
Закрывать служебные URL в robots.txt полезно, но не стоит воспринимать это как защиту. Админка и логин всё равно должны быть защищены нормальной авторизацией, сложными паролями и ограничением попыток входа. robots.txt лишь снижает шум в обходе и убирает часть технических адресов из внимания роботов.
С точки зрения производительности не закрывайте ресурсы, которые нужны для рендеринга страницы. Если поисковик не может обойти CSS и JS, он может хуже понять страницу. Это особенно заметно на сайтах с тяжёлой темой или большим количеством скриптов. В сомнительных случаях лучше проверить рекомендации в Search Console, чем действовать по шаблону.
Если вам нужно не только закрыть служебные страницы, но и почистить сайт от дублей, лишних архивов и технического мусора, имеет смысл смотреть на комплексные инструменты вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае правила лучше проверять вручную, а не полагаться только на интерфейс плагина.
Что делать, если после правки ничего не изменилось
Если robots.txt обновили, а поисковик продолжает показывать старые данные, проверьте кэш на сервере, CDN и плагине кэширования. Иногда браузер видит новый файл, а робот ещё получает старую версию из-за промежуточного кэша. Также убедитесь, что вы правите именно тот домен и протокол, который индексируется: www и без www могут вести себя по-разному.
Ещё один практический момент: если сайт недавно переехал, robots.txt мог сохраниться от старого проекта. Тогда сначала нужно привести в порядок карту сайта, редиректы и канонические адреса, а уже потом закрывать служебные URL. Иначе вы будете лечить симптом, а не причину.