robots.txt в WordPress часто правят в двух крайностях: либо закрывают слишком много и потом ищут пропавшие страницы из индекса, либо вообще ничего не настраивают и получают мусор в обходе. На практике задача обычно одна: дать поисковым роботам понятные правила, не мешая индексации важных страниц и не тратя краулинговый бюджет на служебные URL.
Если у сайта уже есть проблемы с дублями, служебными страницами или лишними параметрами в обходе, robots.txt — это не волшебная кнопка. Он помогает управлять обходом, но не заменяет canonical, noindex и нормальную структуру ссылок. Поэтому сначала стоит понять, что именно вы хотите закрыть, а что — оставить доступным.
Когда robots.txt действительно нужен
Файл полезен, когда нужно ограничить обход технических разделов: админку, системные каталоги, служебные скрипты, временные директории, внутренние поисковые страницы. В WordPress это особенно актуально на сайтах с большим количеством медиафайлов, фильтров, архивов и плагинов, которые создают свои URL.
Но закрывать через robots.txt страницы, которые уже попали в индекс, — слабая стратегия. Если URL должен исчезнуть из поиска, обычно нужен noindex или корректный редирект, а не только запрет в robots.txt. Иначе робот может продолжать видеть URL в выдаче без возможности переобхода и обновления сигнала.
Диагностика: что именно мешает индексации
Перед правкой файла проверьте три вещи:
- какие URL реально индексируются в поиске;
- какие разделы создают лишний обход в логах или в отчётах краулинга;
- нет ли уже конфликта между robots.txt, meta robots и canonical.
Для быстрой проверки откройте текущий файл по адресу /robots.txt и посмотрите, не закрыт ли там важный каталог вроде /wp-content/uploads/ или CSS/JS. Если сайт использует кэш или CDN, убедитесь, что вы смотрите актуальную версию, а не старую копию.
Ещё один практический тест — проверить, не блокируются ли ресурсы, без которых поисковик не может отрисовать страницу. Если CSS и JS закрыты слишком агрессивно, страница может выглядеть для робота иначе, чем для пользователя.
Как настроить robots.txt в WordPress пошагово
В WordPress robots.txt можно отдавать виртуально через систему пермалинков или создать физический файл в корне сайта. Для большинства проектов достаточно виртуального файла, но если у вас сложная инфраструктура, CDN или нестандартная обработка на сервере, физический файл иногда удобнее контролировать.
Базовый безопасный вариант
Ниже пример, который обычно подходит для обычного сайта на 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.
Что можно закрывать дополнительно
Если на сайте есть технический мусор, можно аккуратно ограничить обход отдельных разделов. Например, внутренний поиск, служебные страницы авторов на небольшом сайте, временные каталоги плагинов или тестовые директории. Но каждое правило должно быть обосновано, а не добавлено «на всякий случай».
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /search/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xmlЗдесь есть нюанс: закрытие /?s= и /search/ не удаляет такие страницы из индекса автоматически. Если поисковик уже знает эти URL, лучше дополнительно проверить, отдают ли они noindex или редиректятся ли на более полезную страницу.
Сравнение подходов: плагин, код или ручная правка
| Подход | Когда уместен | Плюсы | Минусы |
|---|---|---|---|
| Ручной файл robots.txt | Нужен полный контроль | Прозрачно, без лишней логики | Легко ошибиться и перезаписать файл |
| Через SEO-плагин | Нужна простая админская настройка | Удобно для редактора, меньше риска правки по FTP | Не всегда подходит для сложных правил |
| Через код | Нужно динамически менять правила | Гибко, можно учитывать окружение | Требует поддержки в теме или плагине |
Если на сайте уже используется SEO-плагин, проверьте, не управляет ли он robots.txt сам. Иначе можно получить ситуацию, когда вы правите файл вручную, а плагин генерирует другой набор правил в админке.
Пример: добавить правило через код
Иногда нужно не редактировать файл вручную, а подмешать правило программно. Например, если на staging-версии сайта нужно закрыть весь обход, а на production оставить обычный набор правил. В WordPress для этого подходит фильтр robots_txt.
<?php
add_filter('robots_txt', function ($output, $public) {
if (defined('WP_ENVIRONMENT_TYPE') && WP_ENVIRONMENT_TYPE === 'staging') {
return "User-agent: *\nDisallow: /\n";
}
$output .= "\nSitemap: https://example.com/sitemap_index.xml\n";
return $output;
}, 10, 2);Такой подход полезен, если у вас несколько окружений и вы не хотите вручную синхронизировать файл. Но используйте его только тогда, когда понимаете, где именно выполняется код: в теме, в mu-plugin или в отдельном плагине.
Проверка результата после внедрения
После правки robots.txt не ограничивайтесь открытием файла в браузере. Проверьте поведение на реальных URL:
- открывается ли
/robots.txtбез ошибок; - не закрыт ли sitemap;
- не блокируются ли CSS и JS, нужные для рендеринга;
- не появились ли новые ошибки обхода в Search Console или аналогичном инструменте;
- не остались ли в индексе страницы, которые вы хотели убрать другим способом.
Если у вас есть доступ к логам сервера, посмотрите, как часто робот запрашивает закрытые разделы. Иногда проблема не в robots.txt, а в бесконечных параметрах, которые генерирует тема, фильтр или старый плагин.
Частые ошибки и как их исправить
Закрывают весь сайт строкой Disallow: /
Это типичная ошибка при переносе сайта на staging или при копировании чужого шаблона robots.txt. На продакшене такая строка полностью запрещает обход. Если сайт уже в индексе, поисковик может ещё какое-то время показывать старые URL, но новые сигналы он не получит.
Исправление простое: уберите глобальный запрет и оставьте только точечные правила. Если нужен закрытый тестовый сайт, лучше ограничить доступ на уровне HTTP-авторизации, а не только robots.txt.
Закрывают /wp-content/ целиком
Так делать не стоит, если внутри лежат изображения, стили и скрипты. Поисковику нужен доступ к ресурсам страницы. Закрывать можно только конкретные служебные подпапки, если вы точно знаете, что они не участвуют в рендеринге.
Путают robots.txt и noindex
robots.txt управляет обходом, а не гарантированным удалением из индекса. Если страница уже проиндексирована, запрет на обход не всегда решает задачу. Для удаления из поиска проверяйте мета-тег robots, заголовки ответа и канонические URL.
Не обновляют sitemap после правок
Если вы меняете структуру сайта, а в robots.txt остаётся старый sitemap, поисковик будет получать устаревшие подсказки. После внедрения проверьте, что ссылка на карту сайта ведёт на актуальный файл и не отдаёт 404.
Практические советы по безопасности и производительности
robots.txt не защищает от атак и не скрывает чувствительные данные. Админку, приватные файлы и служебные endpoints нужно защищать отдельно: правами доступа, авторизацией, настройками сервера и безопасной конфигурацией плагинов.
С точки зрения производительности полезно не только закрыть лишний обход, но и убрать источники дублирования: параметры фильтров, внутренний поиск, архивы без ценности, технические страницы пагинации, если они не нужны в индексе. В некоторых случаях удобнее сначала почистить дубли на уровне SEO-настроек, а уже потом править robots.txt.
Если вам нужно быстро навести порядок в дублях, служебных страницах и SEO-мета, можно посмотреть в сторону инструментов класса Clearfy Pro: он помогает закрывать типовые технические хвосты без ручного редактирования каждого файла. Но даже с плагином логику правил всё равно нужно проверять вручную, особенно после обновлений темы или SEO-модуля.
Хороший рабочий сценарий такой: сначала определить, какие URL должны индексироваться, затем закрыть только лишний обход, после этого проверить sitemap, canonical и ответы сервера. Тогда robots.txt становится частью технической настройки, а не источником случайных блокировок.