Если сайт на WordPress начал плодить мусор в индексе, первым делом обычно смотрят не на контент, а на служебные страницы: архивы авторов, теги, даты, страницы поиска, вложения, параметры сортировки и внутренние дубли. В большинстве случаев проблема не в том, что robots.txt «плохой», а в том, что его либо вообще не настроили, либо закрыли лишнее и потом удивляются просадке в поиске.
Ниже — рабочий сценарий: что именно закрывать, что не трогать, как проверить, что поисковики видят файл правильно, и где WordPress-проекты чаще всего ошибаются.
Какие страницы в WordPress обычно создают дубли
Сначала полезно понять, что вы пытаетесь исправить. robots.txt не удаляет страницы из индекса сам по себе, а только ограничивает обход. Поэтому закрывать им стоит в первую очередь то, что не несёт самостоятельной ценности и часто дублируется:
- страницы поиска вида
?s=; - архивы по датам, если они не нужны для трафика;
- архивы авторов на сайтах с одним автором;
- страницы вложений, если они открываются отдельно и дублируют медиа;
- параметры сортировки и фильтров, если они создают много URL;
- служебные каталоги плагинов и темы, которые не должны обходиться поисковиком.
При этом не стоит пытаться через robots.txt закрыть всё подряд. Если страница уже в индексе, директива Disallow не гарантирует её исчезновение. Для удаления из поиска обычно нужен noindex на самой странице или корректный каноникал, а robots.txt — это только часть схемы.
Диагностика: что именно мешает индексации
Перед правкой файла проверьте, какие URL реально индексируются и откуда они берутся. Удобнее всего открыть отчёты в Google Search Console и посмотреть:
- страницы с пометкой «Просканировано, но не проиндексировано»;
- дубли без выбранной канонической страницы;
- URL с параметрами, которые не должны попадать в поиск;
- страницы поиска и архивы, если они массово появляются в отчёте.
Если у вас есть доступ к серверу, полезно проверить текущий robots.txt напрямую:
curl -I https://example.com/robots.txtИ затем открыть сам файл в браузере. Важно убедиться, что он отдаётся с кодом 200, а не редиректится на другую версию домена или на страницу ошибки.
Что должно насторожить
- robots.txt отдаётся с редиректом на неканонический домен;
- в файле есть
Disallow: /или слишком широкие запреты; - файл генерирует плагин, но вы не понимаете, какие правила он добавляет;
- в Search Console URL всё ещё доступен для обхода, хотя вы ожидали обратного.
Какой подход выбрать: плагин, код или ручная правка
Для WordPress есть три нормальных варианта. Выбор зависит от того, насколько часто вы меняете правила и кто будет поддерживать сайт дальше.
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин SEO/оптимизации | Если нужно править robots.txt без доступа к серверу | Удобно для редактора или менеджера | Легко случайно добавить лишние правила |
| Ручная правка файла | Если доступ к корню сайта есть и правила стабильны | Прозрачно и предсказуемо | Нужно следить за перезаписью при обновлениях |
| Код через фильтр WordPress | Если robots.txt должен собираться динамически | Можно централизовать логику | Нужен разработчик и тестирование |
Если сайт типовой, я бы начинал с ручной правки или с SEO-плагина, который позволяет редактировать robots.txt без лишней магии. Если у вас уже стоит комплексный плагин для чистки дублей и технической оптимизации, например Clearfy Pro, его удобно использовать именно как инструмент контроля служебных URL, но не как замену пониманию того, что вы закрываете.
Пошаговая настройка robots.txt в WordPress
Шаг 1. Сохраните текущую версию
Перед изменениями скопируйте текущий robots.txt. Если что-то пойдёт не так, вы быстро вернёте рабочий вариант. Это особенно важно, если файл уже настроен хостингом, CDN или SEO-плагином.
Шаг 2. Добавьте только нужные директивы
Для большинства сайтов на WordPress безопасная базовая версия выглядит так:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /author/
Disallow: /date/
Disallow: /tag/
Disallow: /attachment/
Sitemap: https://example.com/sitemap_index.xmlЭто не универсальный шаблон, а стартовая точка. Например, если архивы тегов у вас дают трафик и хорошо проработаны, закрывать их не нужно. Если на сайте есть полезные страницы авторов, их тоже лучше оставить открытыми и доработать контентом, а не прятать от робота.
Шаг 3. Если нужен динамический robots.txt, используйте фильтр
WordPress позволяет менять содержимое robots.txt через фильтр robots_txt. Это удобно, когда нужно добавлять правила из темы или небольшого mu-plugin, а не редактировать файл вручную.
<?php
add_filter( 'robots_txt', function( $output, $public ) {
$lines = array(
'User-agent: *',
'Disallow: /wp-admin/',
'Allow: /wp-admin/admin-ajax.php',
'Disallow: /?s=',
'Disallow: /search/',
'Sitemap: ' . home_url( '/sitemap_index.xml' ),
);
return implode( "\n", $lines ) . "\n";
}, 10, 2 );Такой вариант имеет смысл только если вы понимаете, что именно формирует итоговый файл. Если на сайте уже есть SEO-плагин, проверьте, не перезаписывает ли он robots.txt своим выводом.
Что закрывать, а что лучше оставить открытым
Самая частая ошибка — закрыть в robots.txt всё, что кажется «служебным». На практике это может навредить. Например, если вы закрыли слишком много архивов, поисковик теряет внутренние переходы и хуже понимает структуру сайта.
- Обычно закрывают: поиск, технические архивы, вложения, служебные URL с параметрами.
- Обычно оставляют: главную, рубрики, важные страницы, полезные архивы, sitemap.
- С осторожностью: теги, авторы, даты — решение зависит от структуры сайта и качества контента.
Если сомневаетесь, сначала ограничьте индексацию через noindex или каноникал, а не через жёсткий запрет в robots.txt. Для страниц, которые должны быть доступны пользователю, но не попадать в поиск, это обычно более управляемый путь.
Проверка результата после внедрения
После правки не ограничивайтесь тем, что файл «открылся». Проверьте несколько вещей:
- robots.txt отдаётся с кодом
200и без лишних редиректов; - в файле нет случайного
Disallow: /; - сайт всё ещё отдаёт sitemap по указанному адресу;
- страницы, которые вы не хотели закрывать, доступны для обхода;
- в Search Console новые ошибки обхода не появляются.
Для быстрой проверки можно использовать curl:
curl https://example.com/robots.txt
curl -I https://example.com/sitemap_index.xmlЕсли вы закрывали страницы поиска или архивы, проверьте их вручную в браузере и в отчётах Search Console. Важно понимать разницу: robots.txt ограничивает обход, но не гарантирует мгновенное удаление из индекса.
Частые ошибки и как их исправить
Закрыли CSS и JS вместе с контентом
Иногда в robots.txt по старой привычке запрещают целые каталоги темы или плагинов. В результате поисковик не может корректно отрендерить страницу. Если после правки упали проверки в Search Console, уберите слишком широкие запреты и оставьте доступ к ресурсам, которые нужны для отображения сайта.
Ожидали, что robots.txt удалит URL из поиска
Не удалит. Если страница уже проиндексирована, нужен отдельный механизм удаления: noindex, каноникал, редирект или удаление страницы с сайта. robots.txt полезен для сокращения обхода, но не для «магического» вычищения индекса.
Файл конфликтует с плагином
Если SEO-плагин или плагин оптимизации генерирует свой robots.txt, ручная правка файла на сервере может не сработать. В таком случае нужно оставить один источник правды: либо файл, либо настройки плагина, либо фильтр WordPress.
Закрыли архивы, которые приносят трафик
Это уже не техническая, а редакционная ошибка. Перед закрытием проверьте, есть ли у архивов поисковый спрос и внутренние переходы. Если архив полезен, лучше улучшить его заголовок, описание и наполнение, чем прятать его от робота.
Практические советы по безопасности и производительности
robots.txt сам по себе не защищает сайт, но помогает не тратить краулинговый бюджет на мусорные URL. Это особенно заметно на больших проектах с фильтрами, поиском и множеством архивов.
- не закрывайте в robots.txt то, что должно участвовать в рендеринге страницы;
- не дублируйте одни и те же правила в нескольких местах без необходимости;
- держите sitemap актуальным и не включайте в него закрытые URL;
- если сайт часто меняет структуру, документируйте, кто и зачем редактировал robots.txt;
- после крупных обновлений темы или SEO-плагина перепроверяйте итоговый файл.
Если вам нужен не только robots.txt, но и системная чистка дублей, служебных страниц и лишних настроек WordPress, имеет смысл смотреть на комплексные инструменты технической оптимизации. Но даже в этом случае сначала проверьте логику индексации, а уже потом включайте автоматические правила.
Хороший тест на адекватность настройки простой: если вы можете объяснить каждую строку в robots.txt и показать, зачем она нужна, значит файл собран нормально. Если нет — почти наверняка там есть лишнее.