Как настроить robots.txt в WordPress без закрытия важных страниц

Автор: Марина Соколова | Опубликовано: 31.08.2026

robots.txt в WordPress часто правят по одной и той же причине: сайт начинает плодить служебные URL, а в индексе остаются лишние страницы. Но здесь легко переборщить. Один неверный Disallow — и поисковик перестаёт обходить нужные разделы, а потом это вылезает в просадке трафика и странных статусах в Search Console.

Ниже — рабочая схема: что проверять перед правкой, как собрать безопасный robots.txt, чем отличается закрытие от индексации от запрета обхода и как убедиться, что файл не ломает сайт.

Когда robots.txt действительно нужен

robots.txt полезен не для «SEO на всякий случай», а для управления обходом. Его задача — подсказать роботам, какие URL не стоит тратить на crawl budget. Это уместно для:

служебных страниц поиска;
URL с параметрами сортировки и фильтров;
служебных директорий плагинов, если они доступны по публичному URL;
дублирующих технических путей, которые не должны обходиться регулярно.

При этом robots.txt не удаляет страницу из индекса сам по себе. Если URL уже известен поисковику и на него есть ссылки, он может остаться в выдаче без сниппета. Для удаления из индекса нужен другой механизм: noindex, каноникал, редирект или удаление страницы.

Диагностика: что проверить до правки файла

Перед тем как открывать robots.txt, посмотрите, какие именно URL создают проблему. Иначе легко закрыть не то, что нужно.

Проверьте, какие страницы уже попали в индекс

В Google Search Console откройте отчёт по страницам и посмотрите, какие типы URL индексируются: поиск, параметры, архивы, служебные пути. Если у вас уже есть статья про закрытие дублирующих архивов авторов или внутренних поисков, не дублируйте решение в robots.txt: для части таких страниц лучше работает noindex на уровне шаблона.

Посмотрите, что реально обходится ботом

Если есть доступ к логам сервера, проверьте частые запросы от Googlebot и других роботов. Иногда проблема не в индексации, а в том, что бот тратит время на мусорные URL с параметрами. Тогда robots.txt помогает именно как ограничитель обхода.

Сверьте текущий robots.txt

Откройте /robots.txt в браузере и проверьте, нет ли там:

случайного Disallow: /;
закрытия /wp-content/ или /wp-includes/ целиком без понимания последствий;
конфликтующих правил от плагина и вручную добавленного файла;
ошибок в путях, например лишних слэшей или неверных директорий.

Что можно закрывать, а что лучше не трогать

Самая частая ошибка — считать, что robots.txt подходит для любой «нежелательной» страницы. На практике это не так.

Подход	Когда использовать	Ограничение
robots.txt	Чтобы ограничить обход служебных и параметрических URL	Не гарантирует удаление из индекса
`noindex`	Чтобы убрать страницу из индекса, но оставить доступной для обхода	Страница должна быть доступна роботу
редирект 301	Чтобы склеить дубли и перенести вес	Нужна корректная целевая страница

Если задача — убрать из индекса страницу, которую нужно оставить доступной пользователю, robots.txt не лучший инструмент. Если задача — сократить обход мусорных URL, он подходит.

Пошаговая настройка robots.txt в WordPress

Есть два нормальных пути: править файл вручную или использовать плагин, который даёт интерфейс для robots.txt. Если нужен контроль без лишней магии, удобнее ручной вариант.

Вариант 1. Редактирование файла вручную

Создайте или откройте файл robots.txt в корне сайта. Базовый безопасный шаблон для WordPress обычно выглядит так:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/sitemap_index.xml

Что здесь важно:

/wp-admin/ закрывает админку от обхода, но admin-ajax.php остаётся доступным, потому что его часто используют темы и плагины;
Sitemap помогает поисковикам быстрее находить нужные URL;
не закрывайте /wp-content/uploads/ без причины — изображения и медиа должны быть доступны, если они нужны в поиске или на страницах сайта.

Если у вас есть служебные URL поиска или фильтров, которые создают мусорный crawl, добавляйте точечные правила. Например, если сайт генерирует внутренний поиск по параметру s, лучше закрывать именно шаблоны поиска на уровне шаблона или плагина, а не пытаться ловить всё через robots.txt.

Вариант 2. Через плагин для SEO-правок

Если в проекте уже стоит SEO-плагин или плагин для технической чистки, проверьте, умеет ли он управлять robots.txt. Это удобно, когда доступ к файлам ограничен или сайт ведётся не разработчиком. Но важно не смешивать ручную правку и настройки плагина без понимания, кто из них отдаёт финальный файл.

Если нужен именно технический набор для чистки дублей, мета-правок и служебных элементов, можно посмотреть на Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но перед внедрением всё равно проверьте, какой robots.txt реально отдаётся сервером.

Пример более точечного robots.txt для WordPress

Если на сайте есть лишние служебные разделы, можно добавить аккуратные правила, не ломая остальное:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /tag/

Sitemap: https://example.com/sitemap_index.xml

Но здесь нужен здравый смысл. Закрытие /tag/ уместно только если теги действительно не нужны в поиске и вы не используете их как посадочные страницы. Если теги дают трафик и содержат уникальные тексты, закрывать их нельзя. В таком случае лучше доработать шаблон архива тегов, убрать дубли и настроить мета-robots точечно.

Как проверить, что robots.txt сработал

После правки не ограничивайтесь просмотром файла в браузере. Проверьте несколько уровней.

Откройте https://ваш-домен/robots.txt и убедитесь, что отдаётся нужный текст без кешированного старого варианта.
В Search Console используйте проверку URL для страниц, которые вы закрывали, и посмотрите, не блокируется ли важный контент случайно.
Проверьте, остаются ли доступными CSS, JS и изображения, если они нужны для рендеринга.
Посмотрите серверные логи через несколько дней: уменьшилось ли количество запросов к закрытым служебным URL.

Если вы закрыли только обход, но URL всё ещё в индексе, это ожидаемо. Тогда нужен отдельный шаг: noindex, canonical или редирект.

Частые ошибки и как их исправить

Закрыли слишком много

Классическая ошибка — добавить Disallow: / или закрыть целые каталоги, которые нужны для отображения сайта. Симптомы: страницы перестают нормально обходиться, в отчётах появляются проблемы с индексированием, а часть контента выпадает из поиска.

Исправление: откатить правило, проверить кэш CDN и серверный кэш, затем заново отправить robots.txt на переобход через Search Console.

Путают robots.txt и noindex

Если страница должна исчезнуть из выдачи, но оставаться доступной, robots.txt не решает задачу. Робот может не увидеть noindex, если вы запретили обход раньше.

Исправление: сначала дайте роботу доступ к странице, поставьте noindex в HTML или через HTTP-заголовок, и только потом, если нужно, ограничивайте лишний обход.

Не учитывают кэш

На сайте может быть кэш страницы robots.txt на уровне плагина, nginx или CDN. Тогда вы меняете файл, а поисковик ещё видит старую версию.

Исправление: очистить все уровни кэша и проверить ответ через curl:

curl -I https://example.com/robots.txt

Если сервер отдаёт не тот вариант, ищите источник кэша раньше, чем править файл повторно.

Закрывают ресурсы темы и плагинов

Иногда в robots.txt по ошибке попадают /wp-content/ или конкретные папки плагинов. Это может мешать рендерингу и проверке качества страниц.

Исправление: убрать широкие запреты и оставить только действительно служебные пути. Если есть сомнения, проверьте страницу в инструменте проверки URL и посмотрите, не блокируются ли важные файлы стилей и скриптов.

Чек-лист перед публикацией robots.txt

Проверил, какие URL реально создают проблему.
Убедился, что robots.txt нужен именно для обхода, а не для удаления из индекса.
Не закрыл /wp-content/, /wp-includes/ и другие рабочие каталоги без причины.
Оставил доступ к admin-ajax.php, если он используется темой или плагинами.
Добавил актуальную ссылку на sitemap.
Проверил ответ /robots.txt после очистки кэша.
Сверил результат в Search Console и по логам сервера.

Практические замечания по безопасности и производительности

robots.txt не защищает от атак и не прячет административные URL от злоумышленников. Он только подсказывает роботам, что обходить не нужно. Поэтому не используйте его как замену нормальной защите /wp-admin/, ограничению логина, двухфакторной аутентификации или WAF.

С точки зрения производительности robots.txt помогает только косвенно: если бот перестаёт тратить время на мусорные URL, серверу легче. Но если у вас тяжёлые страницы, кеш, база данных и медленные запросы, проблему нужно решать отдельно — через оптимизацию шаблонов, кеширование и чистку лишних запросов.

Если нужен более широкий набор технических правок для WordPress — от дублей до мелких SEO-настроек — лучше собирать их в одном контролируемом месте и не разносить по случайным сниппетам. Тогда проще проверять, что именно изменилось после обновления темы или плагина.