В WordPress robots.txt часто правят «на глаз»: закрывают всё подряд или, наоборот, оставляют открытыми служебные URL, которые не должны попадать в обход краулингового бюджета. На небольшом сайте это обычно не критично, но на проекте с архивами, поиском по сайту, параметрами фильтрации и служебными страницами robots.txt быстро становится точкой, где легко ошибиться.
Ниже — не теория про файл robots.txt, а рабочий сценарий: что именно закрывать в WordPress, как сделать это без лишних запретов и как проверить, что поисковики видят нужную версию файла.
Какие страницы WordPress обычно стоит закрывать
robots.txt не скрывает страницу от пользователя и не удаляет её из индекса сам по себе. Его задача — подсказать роботам, какие разделы не стоит сканировать. Поэтому сюда имеет смысл выносить только технические и малополезные для обхода URL.
Что обычно попадает в список
/wp-admin/— административная часть сайта;/wp-includes/— системные файлы WordPress;/wp-content/plugins/и/wp-content/themes/— если вы не хотите, чтобы робот тратил время на статические ресурсы;- служебные страницы поиска, если они генерируют много мусорных URL;
- внутренние параметры сортировки и фильтрации, если они создают бесконечные комбинации.
При этом не стоит закрывать CSS, JS и изображения без причины: поисковикам нужны ресурсы, чтобы корректно отрендерить страницу. Если закрыть слишком много, можно получить проблемы с индексацией и отображением в рендере.
Диагностика: что именно мешает индексации
Перед правкой файла полезно понять, какие URL реально создают шум. На практике я сначала смотрю:
- отчёт по страницам в Google Search Console;
- логи сервера, если есть доступ;
- список URL, которые появляются из поиска по сайту, архивов и параметров;
- текущий robots.txt и правила, которые уже добавлены плагинами или темой.
Если в индексе всплывают страницы вида ?s=, ?orderby=, ?replytocom= или внутренние служебные архивы, проблема обычно не в одном robots.txt. Но именно он помогает сократить лишний обход и убрать очевидный мусор из краулинга.
Пошаговая настройка robots.txt в WordPress
Есть два нормальных пути: через плагин или вручную. Для большинства сайтов достаточно ручной настройки, если доступен корневой файл robots.txt.
Вариант 1: отредактировать файл в корне сайта
Если файл уже существует, откройте его по FTP, через файловый менеджер хостинга или SSH и проверьте содержимое. Базовый вариант для WordPress выглядит так:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /cgi-bin/
Sitemap: https://example.com/sitemap_index.xmlЗдесь важная деталь: admin-ajax.php часто нужен фронтенду и плагинам, поэтому его обычно разрешают отдельно. Если у вас есть XML-карта сайта, укажите её в robots.txt — это не обязательно, но удобно для роботов и диагностики.
Вариант 2: добавить правила через плагин
Если у вас нет удобного доступа к файлу, можно использовать SEO-плагин или плагин для настройки robots.txt. Но перед сохранением проверьте, не подмешивает ли плагин свои правила и не перезаписывает ли файл при обновлении.
Для сайтов, где одновременно нужно чистить дубли, закрывать архивы и наводить порядок в служебных URL, иногда удобнее использовать связку с Clearfy Pro: он помогает управлять техническими настройками WordPress и не держать часть правок в разных местах. Но даже в этом случае robots.txt лучше проверять отдельно, а не полагаться на интерфейс.
Что не стоит закрывать без проверки
/wp-content/uploads/— если там лежат изображения и файлы, нужные для индексации;/wp-json/— если ваш сайт или тема используют REST API на фронтенде;- каталоги с CSS и JS, если они нужны для рендеринга;
- страницы, которые уже закрыты через
noindex, но при этом должны сканироваться для передачи сигналов ссылок.
Сравнение подходов: файл, плагин или серверная настройка
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Ручной robots.txt в корне | Есть доступ к файлам сайта | Прозрачно, быстро, без лишней логики | Нужно следить за правами доступа и обновлениями |
| Через SEO/технический плагин | Нет удобного доступа к файлам | Удобно для редактора или менеджера | Можно случайно перезаписать правила |
| Через серверные правила | Нужна жёсткая инфраструктурная настройка | Контроль на уровне сервера | Сложнее сопровождать, легко ошибиться |
Если сайт поддерживает несколько администраторов, ручной файл обычно надёжнее: меньше шансов, что кто-то в интерфейсе плагина случайно удалит правило для admin-ajax.php или sitemap.
Пример более аккуратного robots.txt для WordPress-сайта
Ниже — шаблон, который можно адаптировать под свой проект. Он не универсальный, но показывает логику: закрываем служебное, оставляем нужное для рендеринга и явно указываем карту сайта.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /*?replytocom=
Sitemap: https://example.com/sitemap_index.xmlЕсли у вас есть отдельные служебные разделы, например тестовый каталог или приватная документация, добавляйте их точечно. Не стоит пытаться «закрыть всё, что не нравится» одной длинной простынёй правил.
Как проверить, что настройка сработала
После правки не ограничивайтесь открытием файла в браузере. Проверьте несколько вещей:
- Откройте
https://ваш-домен/robots.txtи убедитесь, что файл отдаётся с кодом 200. - Проверьте, что в нём нет лишних директив, добавленных старым плагином или кэшем.
- В Google Search Console используйте проверку robots.txt, если она доступна в вашем аккаунте и интерфейсе.
- Проверьте, что sitemap указан корректно и не ведёт на 404.
- Откройте несколько закрытых URL и убедитесь, что они действительно относятся к служебным разделам, а не к важным страницам сайта.
Полезно также проверить заголовки ответа через curl, если у вас есть SSH-доступ:
curl -I https://example.com/robots.txtВ ответе должен быть 200 OK, а содержимое — именно то, что вы ожидаете. Если вместо этого отдаётся редирект, ошибка 403 или кэшированная старая версия, сначала чините доставку файла, а не правила внутри него.
Частые ошибки и как их исправить
Закрыли слишком много
Самая частая проблема — запретили не только служебные каталоги, но и ресурсы, нужные для рендеринга. Если после правки в отчётах появляются проблемы с доступом к CSS/JS, уберите лишние Disallow и проверьте, не блокируется ли /wp-content/uploads/ без необходимости.
Ожидали, что robots.txt удалит страницу из индекса
Не удалит. Если URL уже в индексе, robots.txt лишь ограничит обход. Для удаления из выдачи нужны noindex, корректный canonical или редирект — в зависимости от ситуации.
Забыли про кэш
Если на сайте стоит серверный кэш, CDN или плагин кэширования, старый robots.txt может продолжать отдаваться какое-то время. После изменений очистите кэш на всех уровнях: плагин, сервер, CDN.
Смешали правила для разных целей
В robots.txt не стоит решать всё сразу: и индексацию, и дубли, и приватность, и редиректы. Это файл про обход, а не про политику индексации в целом. Для закрытия страниц используйте noindex там, где это уместно, а не только Disallow.
Практические советы по безопасности и производительности
robots.txt сам по себе не защищает сайт, но помогает уменьшить шум. Для WordPress это особенно полезно, если у вас много архивов, параметров и служебных URL. Несколько практических правил:
- не закрывайте ресурсы, без которых страница не рендерится корректно;
- не прячьте важные URL в robots.txt вместо нормальной настройки индексации;
- храните копию текущего файла перед изменениями;
- если правки делает не разработчик, ограничьте доступ к редактированию технических настроек;
- после обновления плагинов проверьте, не изменился ли robots.txt автоматически.
Если на сайте уже накопилось много технического мусора — архивы, дубли, служебные страницы и лишние настройки в разных плагинах — имеет смысл сначала навести порядок в техническом слое, а уже потом править robots.txt. Иначе вы просто закрепите хаос в одном файле.