Если в Search Console всплывают URL с параметрами, служебные страницы, архивы автора или лишние версии одного и того же контента, первым делом обычно смотрят на robots.txt. Но это не универсальная кнопка «убрать из индекса». Файл помогает ограничить обход, а не гарантированно удалить URL из поиска. Поэтому на практике важно не только написать правила, но и понимать, что именно вы хотите решить: сократить краулинг мусора, убрать дубли из обхода или не дать поисковику тратить бюджет на служебные разделы.
Какие симптомы указывают, что robots.txt настроен неудачно
Проблема обычно проявляется не в самом файле, а в поведении поисковых ботов и отчётах по индексации. Типичные признаки: в индексе появляются URL с ?replytocom=, ?utm_, ?sort= и другими параметрами; в отчётах видны архивы тегов, авторов или дат, которые не несут ценности; бот активно ходит по /wp-admin/, /wp-includes/ и техническим путям; в логах много запросов к XML-картам и служебным страницам, которые не должны участвовать в ранжировании.
Что важно проверить до правки файла
- Есть ли у сайта дубли из-за параметров в URL.
- Используются ли архивы тегов, авторов и дат как полноценные посадочные страницы.
- Не закрыт ли случайно CSS, JS или изображения, которые нужны для рендеринга.
- Не мешает ли текущий
robots.txtобходу sitemap.
Если вы закрыли слишком много, страницы могут хуже обходиться, а поисковик — дольше понимать структуру сайта. Если закрыли слишком мало, бот будет тратить ресурсы на мусорные URL, а в индексе останутся дубли.
Что можно и что нельзя решать через robots.txt
Это ключевой момент. robots.txt подходит для ограничения обхода, но не для удаления уже проиндексированных страниц. Если URL уже в индексе, чаще нужен noindex, каноникал или 301-редирект. Закрывать через robots.txt имеет смысл служебные каталоги, лишние параметры, внутренние поисковые страницы и технические пути, которые не должны обходиться ботом.
| Подход | Когда использовать | Ограничение |
|---|---|---|
| robots.txt | Сократить обход служебных URL и параметров | Не удаляет URL из индекса сам по себе |
| noindex | Нужно убрать страницу из поиска | Страница должна быть доступна для обхода |
| 301 redirect | Есть дубль, который нужно заменить основным URL | Требует аккуратной настройки и проверки цепочек |
Пошаговая настройка robots.txt в WordPress
В WordPress файл robots.txt может отдаваться виртуально, если физического файла нет. Это удобно, но иногда мешает, когда плагины SEO или хостинг подменяют содержимое. Поэтому сначала проверьте текущую версию файла по адресу /robots.txt, а потом уже вносите изменения.
Шаг 1. Сохраните базовые директивы
Не стоит начинать с полного запрета всего подряд. Базовый файл должен оставлять доступ к sitemap и не блокировать нужные ресурсы. Для большинства сайтов минимальный вариант выглядит так:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Sitemap: https://example.com/sitemap_index.xmlЗдесь важно не закрывать admin-ajax.php, если тема, плагин или фронтенд-скрипты используют AJAX. И не забывать подставить реальный адрес sitemap, который генерирует ваш SEO-плагин или сам сайт.
Шаг 2. Закройте типовые служебные разделы
Если сайт генерирует много бесполезных обходов, можно добавить ограничения для типовых путей WordPress. Но делайте это только для того, что действительно не нужно в поиске и не участвует в публичной работе сайта.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /cgi-bin/
Disallow: /trackback/
Disallow: /feed/
Sitemap: https://example.com/sitemap_index.xmlС /feed/ и /trackback/ нужно быть аккуратнее: если вы используете RSS как канал распространения контента, полное закрытие может быть лишним. В некоторых проектах лучше не блокировать feed, а просто не выводить его в карту сайта и не ссылаться на него внутри шаблонов.
Шаг 3. Уберите обход параметров, если они создают дубли
Если у вас есть повторяющиеся URL с параметрами, например сортировка, фильтры, UTM-метки или внутренний поиск, их можно ограничить через правила для конкретных путей. Но robots.txt не умеет надёжно закрывать все параметры на уровне шаблона URL. Для сложных случаев лучше сочетать каноникал, редиректы и настройку плагина SEO.
Пример для внутреннего поиска WordPress:
User-agent: *
Disallow: /?s=
Disallow: /search/
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xmlНо если поиск уже индексируется, одного запрета мало. Поисковик может продолжать показывать URL без сниппета. В такой ситуации лучше дополнительно закрыть страницы поиска через noindex на уровне шаблона или плагина.
Как сделать настройку через код, если нужен контроль из темы или плагина
Если вы не хотите редактировать файл вручную, можно отдать свой вариант robots.txt через хук do_robotstxt. Это полезно, когда сайт разворачивается из шаблона, а правила должны храниться в коде проекта.
add_filter('do_robotstxt', function ($output, $public) {
if (! $public) {
return $output;
}
$lines = [
'User-agent: *',
'Disallow: /wp-admin/',
'Allow: /wp-admin/admin-ajax.php',
'Disallow: /wp-login.php',
'Disallow: /search/',
'Sitemap: ' . home_url('/sitemap_index.xml'),
];
return implode("\n", $lines) . "\n";
}, 10, 2);Этот вариант удобен тем, что правила не потеряются при миграции, если код хранится в репозитории. Но есть и минус: SEO-плагин или хостинг тоже могут вмешиваться в вывод. После внедрения обязательно проверьте, какой именно robots.txt отдается в ответе.
Как проверить, что решение сработало
Проверка должна быть не на глаз, а по факту ответа сервера и поведению поисковика. Сначала откройте /robots.txt в браузере или через curl и убедитесь, что файл отдается без ошибок и содержит нужные директивы. Затем проверьте, не блокируются ли ресурсы, которые нужны для рендеринга страниц.
curl -I https://example.com/robots.txt
curl https://example.com/robots.txtДальше откройте Google Search Console или Яндекс Вебмастер и посмотрите:
- есть ли ошибки чтения robots.txt;
- не выросло ли число исключённых страниц из-за случайной блокировки;
- сократился ли обход служебных URL;
- не пропали ли из обхода важные страницы и ресурсы.
Если вы закрывали параметры или внутренний поиск, проверьте конкретный URL вручную: он должен либо не обходиться ботом, либо получать корректный noindex / редирект в зависимости от выбранной схемы.
Частые ошибки и как их исправить
Закрыли CSS и JS вместе с техническими путями
Это частая ошибка после копирования чужого robots.txt. Если в файле есть запреты на каталоги темы, плагинов или статические ресурсы, поисковик может хуже рендерить страницы. Исправление простое: уберите лишние Disallow для ресурсов, которые нужны публичной части сайта.
Пытаются удалить страницу из индекса только через robots.txt
Если URL уже в поиске, запрет обхода не гарантирует исчезновение из выдачи. Нужен noindex, канонический адрес или редирект. Robots.txt в этой схеме — вспомогательный слой, а не основное средство удаления.
Закрывают sitemap
Иногда в погоне за «чистотой» случайно блокируют XML-карту сайта. Это мешает поисковику быстрее находить важные страницы. Sitemap должен оставаться доступным, иначе вы сами усложняете индексацию.
Используют слишком общие правила для параметров
Например, пытаются закрыть все URL с вопросительным знаком одним грубым правилом. В результате можно задеть полезные страницы или служебные маршруты. Лучше анализировать конкретные шаблоны URL и закрывать только то, что реально создаёт мусор.
Практические советы по безопасности и производительности
Robots.txt не защищает сайт от атак, но может уменьшить лишний шум в логах и снизить нагрузку от бот-обхода. При этом не стоит рассчитывать на него как на средство безопасности: /wp-login.php и /wp-admin/ всё равно должны быть защищены нормальными методами — ограничением попыток входа, 2FA, WAF или хотя бы корректной политикой доступа на уровне сервера.
Для производительности полезно держать robots.txt коротким и понятным. Чем больше в нём экспериментальных правил, тем выше шанс ошибиться при следующем обновлении. Если сайт большой и правила сложные, храните их в репозитории рядом с конфигурацией SEO-плагина или темы, а не в разрозненных заметках.
Если вы используете плагин для SEO и чистки дублей, например Clearfy Pro, проверьте, не дублирует ли он часть правил, которые уже есть в robots.txt. Дублирование логики в двух местах часто приводит к путанице: в одном месте закрыли, в другом — открыли, а потом непонятно, почему бот всё ещё ходит по нежелательным URL.
Когда лучше не трогать robots.txt вручную
Если сайт уже использует сложную SEO-настройку, мультиязычность, фильтры каталога или нестандартные маршруты, ручная правка без карты URL может принести больше вреда, чем пользы. В таких проектах сначала соберите список проблемных адресов, проверьте, как они отдаются в ответе, и только потом меняйте правила. Иногда правильнее убрать дубли на уровне шаблона, чем пытаться «запретить всё» в одном файле.
Самый надёжный порядок такой: сначала определить тип URL, потом выбрать механизм — noindex, редирект или robots.txt, затем проверить ответ сервера и только после этого смотреть на изменения в индексации. Если делать наоборот, легко получить сайт, который вроде бы «закрыт», но поисковик продолжает видеть старые дубли или, наоборот, теряет важные страницы.