В WordPress robots.txt часто используют слишком грубо: закрывают всё подряд или, наоборот, оставляют в индексе служебные URL, которые не должны конкурировать с основными страницами. На практике проблема обычно не в самом файле, а в том, какие именно разделы вы пытаетесь скрыть от поисковиков и как это сочетается с sitemap, canonical и настройками плагинов SEO.
Ниже разберём рабочий сценарий: какие технические страницы имеет смысл закрывать, как собрать аккуратный robots.txt без лишних запретов, чем отличается блокировка от удаления из индекса и как проверить, что всё сработало.
Какие страницы WordPress обычно стоит закрывать
robots.txt нужен не для «секретности», а для управления обходом. Если страница уже попала в индекс, один только robots.txt её не удалит. Но он помогает не тратить краулинговый бюджет на мусорные URL и не провоцировать поисковики на обход служебных разделов.
Типичные кандидаты на закрытие
/wp-admin/— административная часть сайта;/wp-login.php— страница входа;/wp-json/— REST API, если вы точно понимаете последствия его закрытия;- служебные параметры и внутренние поисковые URL, если они создают дубли;
- медиа-страницы вложений, если они не используются как отдельные посадочные страницы;
- технические каталоги плагинов и тем, если они вдруг доступны для обхода.
При этом не стоит закрывать CSS, JS и изображения, если они нужны для корректного рендеринга. Поисковым системам важно видеть страницу так же, как её видит браузер.
Диагностика: что именно мешает индексации
Перед правкой robots.txt проверьте, что именно вы хотите исправить. Частая ошибка — закрыть URL в robots.txt, когда проблема на самом деле в дублях, canonical или неверных мета-тегах.
- Если в индексе много URL с параметрами, сначала посмотрите, откуда они берутся: фильтры, поиск по сайту, сортировки, UTM.
- Если в выдаче есть страницы вложений, проверьте настройки медиафайлов и редиректы с attachment URL.
- Если поисковик видит служебные страницы, убедитесь, что они не попадают в sitemap.
- Если нужно убрать уже проиндексированные URL, robots.txt сам по себе не поможет — понадобится noindex, canonical или редирект.
Для быстрой проверки можно открыть исходный код страницы и посмотреть, не генерирует ли SEO-плагин лишние ссылки в sitemap. Если у вас стоит Clearfy Pro, там удобно проверить техническую чистку сайта и закрытие дублей в одном месте: Clearfy Pro.
Рабочий robots.txt для WordPress
Если сайт обычный, без сложной логики и нестандартных API-подключений, можно начать с аккуратного базового варианта. Он не ломает публичные ресурсы и закрывает только то, что обычно не нужно в обходе.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /search/
Disallow: /trackback/
Disallow: /feed/
Sitemap: https://example.com/sitemap_index.xmlЗдесь есть важный нюанс: admin-ajax.php часто нужен фронтенду и плагинам, поэтому его обычно не закрывают. А вот /search/ и /?s= стоит закрывать только если внутренний поиск создаёт мусорные URL и не нужен в индексе.
Когда закрывать REST API
/wp-json/ не стоит закрывать автоматически. Многие темы, блоки и плагины используют REST API на фронтенде. Если вы его запретите без проверки, можно получить сломанные формы, динамические блоки или проблемы с редактором.
Закрывать REST API имеет смысл только в узких сценариях: если сайт полностью статический по выводу, API не используется внешними сервисами и вы проверили, что фронтенд не делает запросы к /wp-json/.
Как задать robots.txt в WordPress без ручной правки файлов
В WordPress robots.txt может отдаваться виртуально, без физического файла в корне. Это удобно, если вы не хотите править сервер напрямую. Но если у вас уже есть реальный robots.txt в корне сайта, он обычно имеет приоритет над виртуальной версией.
Если нужен контроль через код, можно использовать фильтр robots_txt. Это безопаснее, чем править ядро или надеяться на случайный плагин.
add_filter( 'robots_txt', function( $output, $public ) {
$lines = array(
'User-agent: *',
'Disallow: /wp-admin/',
'Allow: /wp-admin/admin-ajax.php',
'Disallow: /wp-login.php',
'Sitemap: ' . home_url( '/sitemap_index.xml' ),
);
return implode( "\n", $lines ) . "\n";
}, 10, 2 );Такой подход полезен, если вы ведёте несколько сред — production, staging, тестовую копию — и хотите централизованно управлять правилами. Но не забывайте, что код в теме может потеряться при обновлении. Для постоянной логики лучше использовать мини-плагин или mu-plugin.
Пошаговая настройка: что делать на практике
- Составьте список URL, которые не должны обходиться поисковиками: админка, логин, поиск, feed, технические параметры.
- Проверьте, нет ли среди них страниц, которые уже участвуют в трафике или нужны внешним сервисам.
- Соберите минимальный robots.txt без лишних запретов.
- Убедитесь, что sitemap не содержит закрытые URL.
- Проверьте, не конфликтует ли robots.txt с canonical и meta robots.
- После публикации протестируйте файл в инструментах для вебмастеров и в браузере.
Проверка результата после внедрения
После изменения robots.txt важно не ограничиться открытием файла в браузере. Нужно проверить три вещи: доступность самого файла, отсутствие конфликтов с sitemap и поведение поискового робота на нужных URL.
Что проверить вручную
- открывается ли
/robots.txtпо HTTPS без редиректов и ошибок; - виден ли в нём актуальный адрес sitemap;
- не закрыли ли вы случайно CSS, JS или изображения;
- не остались ли в sitemap URL, которые вы запретили в robots.txt;
- не растёт ли число «Просканировано, но не проиндексировано» из-за слишком жёстких запретов.
Если используете Google Search Console или Яндекс Вебмастер, проверьте отчёты по страницам, которые были закрыты. Для уже проиндексированных URL robots.txt не является способом удаления — там нужен отдельный сценарий: noindex, 301 или удаление страницы.
Сравнение подходов: robots.txt, noindex и редирект
| Подход | Когда использовать | Плюс | Минус |
|---|---|---|---|
| robots.txt | Нужно ограничить обход технических URL | Быстро и просто | Не удаляет уже проиндексированные страницы |
| noindex | Страница доступна, но не должна быть в индексе | Подходит для удаления из выдачи | Страница должна быть доступна для обхода |
| 301 редирект | Есть новый канонический адрес | Передаёт сигнал на новый URL | Нужна корректная карта перенаправлений |
Если задача — убрать дубль, robots.txt почти всегда вторичен. Сначала решают вопрос с каноническим URL, а уже потом закрывают технические хвосты от обхода.
Частые ошибки и как их исправить
Закрыли слишком много
Самая неприятная ошибка — запретить весь сайт или важные статические ресурсы. В результате поисковик не может отрендерить страницу, а в отчётах появляются проблемы с доступом к CSS и JS. Исправление простое: убрать лишние Disallow и оставить только действительно технические разделы.
Пытаются удалить страницы через robots.txt
Если URL уже в индексе, запрет на обход не решит задачу. Страница может остаться в выдаче как «URL без описания». Для удаления используйте noindex, редирект или удаление страницы с корректным кодом ответа.
Забыли про sitemap
Если закрытый URL всё ещё есть в sitemap, вы создаёте противоречие: поисковик видит ссылку на страницу, но не может её обойти. Это не критично в каждом случае, но лишний шум лучше убрать.
Редактируют robots.txt в теме
Если правила завязаны на тему, после обновления или смены шаблона они могут исчезнуть. Для стабильной настройки лучше использовать отдельный плагин, mu-plugin или серверный файл в корне сайта.
Безопасность и производительность
robots.txt не защищает от атак и не скрывает чувствительные данные. Если в админке или API есть риск, решать его нужно авторизацией, ограничением доступа на сервере и актуальными обновлениями WordPress, тем и плагинов.
С точки зрения производительности не стоит закрывать всё подряд. Чем меньше хаотичных правил, тем проще поддерживать сайт и тем меньше шанс случайно заблокировать важные ресурсы. Если у вас много технических дублей, удобнее сначала навести порядок в структуре URL, а потом уже ограничивать обход.
Если нужна более широкая техническая чистка WordPress — дубли, служебные страницы, лишние элементы в head и другие мелкие источники шума — имеет смысл смотреть не только на robots.txt, но и на общую SEO-гигиену сайта. В этом сценарии полезен Clearfy Pro: https://wpshop.ru/plugins/clearfy.
Короткий чек-лист перед публикацией
- robots.txt открывается по HTTPS;
- в нём нет запрета на CSS, JS и изображения;
/wp-admin/закрыт, ноadmin-ajax.phpдоступен;- sitemap указан актуальный и ведёт на реальные URL;
- закрытые страницы не нужны в индексе и не участвуют в трафике;
- для уже проиндексированных URL выбран правильный способ удаления: noindex, редирект или удаление.
Если после правки сайт стал хуже индексироваться, откатите изменения и проверьте, не перепутали ли вы блокировку обхода с удалением из выдачи. В WordPress это одна из самых частых технических ошибок: файл настроили правильно, но задачу выбрали неверно.