Если в WordPress в индекс попадают служебные URL, дубли архивов или мусорные страницы, часто проблема начинается не с контента, а с robots.txt. Ошибка типичная: файл либо слишком жёсткий, либо, наоборот, ничего не ограничивает, и поисковик тратит краулинговый бюджет на то, что не должно индексироваться.
Ниже разберём, как диагностировать ситуацию, что именно закрывать в robots.txt, чем этот файл отличается от noindex, и как проверить, что после правки сайт не потерял важные страницы.
Когда проблема действительно в robots.txt
Не каждый случай с дубликатами решается через robots.txt. Этот файл управляет обходом, а не гарантирует удаление из индекса. Если страница уже попала в поиск, одного запрета в robots.txt может быть недостаточно: робот просто перестанет её обходить, но URL может ещё долго висеть в выдаче без сниппета.
Сначала проверьте, что именно происходит:
- в Search Console есть сообщения о заблокированных ресурсах;
- в индексе видны служебные URL вроде
/wp-admin/,/wp-login.php,/feed/, параметрические адреса; - в отчётах по сканированию много мусорных URL, которые не должны обходиться;
- после миграции или установки SEO-плагина изменился
robots.txtи часть страниц перестала обходиться.
Если проблема в том, что страница уже индексируется и её нужно убрать, чаще нужен noindex, canonical или корректная настройка шаблона, а не только запрет в robots.txt.
Что обычно закрывают в WordPress
В WordPress есть набор адресов, которые почти всегда стоит ограничить от обхода поисковыми роботами. Это не «магия SEO», а базовая гигиена сайта.
Служебные и технические URL
Обычно закрывают:
/wp-admin/— админка;/wp-login.php— форма входа;/wp-json/— REST API, если нет задачи индексировать его ответы;/xmlrpc.php— если не используется;/trackback/и/comments/feed/— если они не нужны;- внутренние поисковые страницы и архивы с параметрами, если они создают мусор.
При этом не стоит закрывать CSS, JS и изображения без причины. Современные поисковые системы рендерят страницы, и если вы запретите доступ к критическим ресурсам, можете сломать понимание контента.
Что лучше не закрывать без проверки
Опасные кандидаты на запрет — это:
/wp-content/uploads/целиком, если там лежат изображения для страниц;- категории и теги, если они реально дают трафик;
- страницы пагинации, если они используются для обхода каталога или блога;
- публичные REST-эндпоинты, которые нужны фронтенду или интеграциям.
Диагностика: как понять, что у вас уже есть конфликт
Откройте текущий robots.txt по адресу https://ваш-домен.ru/robots.txt. Если там есть странные директивы вроде Disallow: / для всех роботов, это почти наверняка ошибка. Если файл генерируется плагином, проверьте его настройки и историю изменений после обновлений.
Дальше полезно посмотреть, что реально отдаёт сервер. Иногда WordPress показывает виртуальный robots.txt, а на уровне Nginx или Apache уже лежит физический файл, который его перекрывает.
curl -I https://example.com/robots.txtЕсли ответ не 200 OK, есть редиректы, 403 или неожиданный HTML вместо plain text, сначала чините серверную часть. Поисковики должны видеть обычный текстовый файл.
Ещё одна проверка — Search Console. Если там много URL со статусом «заблокировано robots.txt», откройте примеры и посмотрите, не закрыли ли вы случайно важные разделы сайта.
Пошаговое решение: безопасный robots.txt для WordPress
Самый практичный подход — не полагаться на случайную генерацию, а задать понятный минимальный файл. Для большинства сайтов достаточно аккуратного базового набора правил.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /xmlrpc.php
Disallow: /trackback/
Disallow: /comments/feed/
Sitemap: https://example.com/sitemap_index.xmlЧто здесь важно:
Allow: /wp-admin/admin-ajax.phpнужен, если фронтенд использует AJAX-запросы;Sitemapлучше указывать явно, чтобы робот быстро находил карту сайта;- не добавляйте лишние запреты «на всякий случай» — потом сложнее понять, что именно сломалось.
Если у вас есть отдельные служебные разделы, их можно добавить точечно. Например, закрыть внутренний поиск WordPress:
User-agent: *
Disallow: /?s=
Disallow: /search/
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /xmlrpc.php
Sitemap: https://example.com/sitemap_index.xmlНо здесь есть нюанс: параметр ?s= не всегда одинаково обрабатывается роботами, а поисковые системы могут по-разному интерпретировать URL с параметрами. Если внутренний поиск уже попал в индекс, лучше дополнительно поставить noindex на шаблон результатов поиска.
Как задать robots.txt через код темы или плагина
Если вы не хотите редактировать файл вручную, в WordPress можно изменить виртуальный robots.txt через фильтр robots_txt. Это удобно, когда файл генерируется динамически и нужен контроль в коде.
add_filter('robots_txt', function ($output, $public) {
$lines = [
'User-agent: *',
'Disallow: /wp-admin/',
'Allow: /wp-admin/admin-ajax.php',
'Disallow: /wp-login.php',
'Disallow: /xmlrpc.php',
'Disallow: /trackback/',
'Disallow: /comments/feed/',
'',
'Sitemap: ' . home_url('/sitemap_index.xml'),
];
return implode("\n", $lines);
}, 10, 2);Такой вариант подходит, если вы контролируете тему или собственный плагин. Но если SEO-плагин уже управляет robots.txt, не дублируйте правила в двух местах. Иначе потом сложно понять, какой именно источник отдаёт финальный файл.
Чем robots.txt отличается от noindex и canonical
Это частая точка путаницы. robots.txt запрещает обход. noindex просит не индексировать страницу. canonical указывает предпочтительную версию URL. Это разные инструменты, и они не взаимозаменяемы.
| Инструмент | Что делает | Когда использовать | Ограничение |
|---|---|---|---|
| robots.txt | Запрещает обход | Для служебных URL, админки, мусорных разделов | Не гарантирует удаление уже проиндексированного URL |
| noindex | Просит не включать страницу в индекс | Для архивов, поиска, дублей контента | Страница должна быть доступна роботу для чтения |
| canonical | Указывает основную версию | Для дублей с параметрами, сортировками, пагинацией | Не скрывает страницу полностью |
Если задача — убрать из индекса страницу поиска или архив с тонким контентом, чаще нужен noindex. Если задача — не тратить краулинг на админку и технические URL, нужен robots.txt.
Проверка результата после внедрения
После правки не ограничивайтесь открытием файла в браузере. Нужно проверить, что робот видит именно то, что вы задумали.
- Откройте
/robots.txtв браузере и убедитесь, что файл отдается без редиректов и ошибок. - Проверьте, не перекрывает ли его физический файл на сервере.
- В Search Console отправьте на проверку важные URL и посмотрите, не стали ли они заблокированы.
- Проверьте sitemap: он должен быть доступен и не закрыт правилами robots.txt.
- Убедитесь, что CSS/JS и изображения не заблокированы без необходимости.
Для быстрой проверки можно использовать curl и посмотреть заголовки:
curl -I https://example.com/robots.txt
curl -s https://example.com/robots.txtЕсли после изменения файла важные страницы перестали обходиться, откатите правку и сравните старую и новую версии. Часто проблема в одной лишней строке, которая закрыла слишком широкий шаблон URL.
Частые ошибки и как их исправить
Закрыли слишком много
Самая дорогая ошибка — запретить целый каталог, который нужен для рендеринга страниц. Например, закрыть /wp-content/ или папку с темой. В результате поисковик видит страницу без стилей, скриптов или изображений и может хуже её интерпретировать.
Исправление простое: уберите широкий Disallow, оставьте только точечные правила и проверьте, что критические ресурсы доступны.
Путают robots.txt и noindex
Если страница уже в индексе, запрет в robots.txt не всегда решает задачу. Робот может перестать её обходить, но URL останется в выдаче. Для удаления из индекса используйте noindex на самой странице, а robots.txt применяйте только для обхода.
Дублируют правила в плагине и вручную
Когда robots.txt правится и через SEO-плагин, и через физический файл, итоговое поведение становится неочевидным. В одном месте правило есть, в другом его уже нет, а на сервере отдаётся третий вариант.
Исправление: оставьте один источник правды. Либо физический файл, либо генерацию через код/плагин.
Закрывают sitemap
Иногда в robots.txt случайно попадает запрет на карту сайта или её путь меняется после миграции. В итоге поисковик хуже находит новые URL. Sitemap должен быть доступен и указан явно.
Практические советы по безопасности и производительности
Если у вас есть отдельная задача по защите сайта, не пытайтесь решать её только через robots.txt. Он не защищает от атак, не скрывает URL от злоумышленников и не блокирует сканеры. Для безопасности нужны ограничения на уровне сервера, актуальные обновления, сложные пароли и, при необходимости, WAF.
Для производительности robots.txt полезен тем, что помогает не тратить обход на мусор. Но не стоит превращать его в свалку правил. Чем проще файл, тем легче его поддерживать после обновлений темы, SEO-плагина или миграции домена.
Если вам нужно регулярно чистить сайт от дублей, служебных архивов и технического мусора, удобнее централизовать это в SEO-плагине или в инструменте, который управляет дублями и служебными страницами. Например, в Clearfy Pro есть набор функций для чистки WordPress и отключения лишнего, но даже с таким инструментом важно понимать, какие именно URL вы закрываете и зачем.
Хороший рабочий принцип здесь простой: сначала определить тип URL, потом выбрать инструмент, и только затем вносить правило. Тогда robots.txt перестаёт быть «магическим файлом» и становится обычной частью технической настройки сайта.