robots.txt в WordPress нужен не для «магической» индексации, а для управления обходом сайта поисковыми роботами. Через него вы подсказываете, какие разделы можно сканировать, а какие лучше не тратить на них краулинговый бюджет и не показывать в результатах поиска технические страницы. Если настроить файл неаккуратно, можно случайно закрыть важные разделы или, наоборот, оставить открытыми служебные URL, которые не нужны ни пользователю, ни поисковику.
Для WordPress это особенно актуально: у сайта есть системные страницы, служебные каталоги и параметры, которые обычно не должны попадать в поиск. При этом robots.txt не заменяет noindex и не удаляет страницы из индекса сам по себе. Он только управляет обходом.
Что обычно стоит закрывать в WordPress
Базовая задача robots.txt — не мешать поисковику находить полезный контент и одновременно не тратить его время на технические разделы. В WordPress чаще всего ограничивают доступ к таким путям:
/wp-admin/— административная часть сайта;/wp-includes/— системные файлы WordPress;/wp-content/plugins/и иногда/wp-content/themes/— служебные ресурсы, если нет необходимости их обходить;- страницы поиска по сайту с параметром
?s=, если они создают мусорный трафик и не нужны в выдаче; - технические URL, которые генерируются плагинами и не несут ценности для посетителя.
При этом не стоит закрывать в robots.txt то, что должно индексироваться: записи, страницы, рубрики, изображения, если они важны для поиска. Если вы запретите обход важного раздела, поисковик может не увидеть содержимое страницы и не понять, что на ней находится.
Где в WordPress редактировать robots.txt
У WordPress есть виртуальный robots.txt: если физического файла в корне сайта нет, WordPress может отдавать его динамически. Это удобно, но на практике чаще используют обычный файл robots.txt в корне сайта, потому что его проще контролировать и он не зависит от плагинов, которые могут вмешиваться в вывод.
Проверить, какой вариант у вас сейчас работает, можно по адресу https://ваш-домен.ru/robots.txt. Если открывается текстовый файл с правилами — значит, robots.txt уже доступен. Если там пусто или вы видите неожиданные директивы, сначала разберитесь, кто именно его формирует: WordPress, SEO-плагин, хостинг или вручную созданный файл.
Практически безопасный вариант для большинства сайтов — создать или отредактировать физический файл robots.txt в корне сайта через FTP, файловый менеджер хостинга или панель управления. Так вы точно знаете, что именно отдаётся роботам.
Базовый пример robots.txt для WordPress
Для типичного сайта на WordPress можно начать с аккуратного минимального набора правил. Он не перегружает файл и закрывает только то, что обычно не нужно в обходе:
User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php Disallow: /wp-includes/ Disallow: /wp-content/plugins/ Disallow: /wp-content/themes/
Этот вариант подходит не всем без исключения, но как стартовая точка он понятен и предсказуем. Директива User-agent: * означает, что правила применяются ко всем роботам. Строка Allow: /wp-admin/admin-ajax.php нужна потому, что этот файл часто используется фронтендом и плагинами, и закрывать его полностью обычно не стоит.
Если на сайте есть изображения, CSS или JS, которые должны обходиться поисковиком для корректного рендеринга страниц, не закрывайте каталоги слишком агрессивно. В некоторых случаях запрет на /wp-content/ целиком мешает поисковым системам увидеть ресурсы, нужные для оценки страницы. Поэтому правило лучше подбирать под конкретную структуру сайта, а не копировать вслепую.
Что не стоит делать при настройке
Самая частая ошибка — пытаться с помощью robots.txt решить задачу, для которой он не предназначен. Например, если страница уже в индексе, запрет в robots.txt не гарантирует её удаление. Поисковик может перестать её обходить, но URL ещё какое-то время останется в выдаче. Для удаления из индекса нужны другие механизмы, а robots.txt здесь только вспомогательный инструмент.
Ещё одна типичная проблема — закрыть слишком много. Если в файл попадает Disallow: /, сайт фактически становится недоступным для обхода роботами. Это иногда делают по ошибке при переносе сайта или тестировании и потом долго ищут причину падения видимости.
Не стоит также дублировать в robots.txt то, что уже закрыто на уровне сайта или сервера. Если раздел и так отдаёт 403, 404 или защищён авторизацией, дополнительный запрет в robots.txt не даёт практической пользы. Лучше держать файл коротким и понятным.
Как проверить, что robots.txt настроен правильно
После сохранения файла откройте /robots.txt в браузере и проверьте три вещи: файл доступен по HTTP-адресу, в нём нет синтаксических ошибок и правила действительно соответствуют вашей структуре сайта. В robots.txt не должно быть лишних символов, HTML-разметки или случайных пробелов в директивах.
Дальше проверьте несколько URL вручную:
- адреса, которые должны быть доступны роботам;
- служебные разделы, которые вы закрыли;
- страницы с параметрами, если вы их ограничивали.
Если у вас есть доступ к инструментам для вебмастеров поисковой системы, используйте их для проверки доступности robots.txt и отдельных URL. Это особенно полезно после переноса сайта, смены хостинга или установки SEO-плагина, который может перезаписывать правила.
Важно смотреть не только на сам файл, но и на поведение сайта в целом. Если вы закрыли каталог в robots.txt, но страницы из него уже были проиндексированы, они не исчезнут мгновенно. В таком случае нужно отдельно проверить, не остались ли старые URL в индексе и не конфликтуют ли правила robots.txt с мета-тегами на страницах.
Когда robots.txt лучше не усложнять
Для небольшого сайта с обычной структурой часто достаточно минимального файла: закрыть админку, оставить доступ к нужным системным файлам и не добавлять лишних директив. Чем сложнее robots.txt, тем выше риск ошибки при обновлении темы, плагина или структуры URL.
Если сайт активно развивается, а технические разделы меняются, удобнее держать robots.txt в одном месте и периодически пересматривать его после крупных изменений. Особенно это касается сайтов на WordPress с большим количеством плагинов: один плагин может добавлять свои служебные URL, другой — менять структуру параметров, и старые правила перестают быть актуальными.
Если вам нужно не просто закрыть несколько каталогов, а системно убрать дубли, служебные страницы и лишние технические URL, имеет смысл использовать SEO-плагин с управлением мета-тегами и служебными настройками. Но сам robots.txt всё равно лучше проверять вручную: автоматическая генерация не гарантирует, что файл будет оптимален именно для вашего сайта.
Практичный порядок настройки
Если свести работу к короткому алгоритму, он будет таким:
- Откройте текущий
/robots.txtи посмотрите, кто его формирует. - Определите, какие разделы действительно нужно ограничить, а какие должны оставаться доступными.
- Сделайте минимальный файл без лишних директив.
- Проверьте, что важные страницы не закрыты случайно.
- После сохранения снова откройте
/robots.txtи протестируйте несколько URL.
Такой подход безопаснее, чем копировать готовый шаблон из чужой статьи. В WordPress структура сайта и набор плагинов сильно влияют на то, какие правила уместны. Хороший robots.txt — это не длинный список запретов, а короткий и понятный файл, который не мешает поисковику работать с вашим сайтом.