robots.txt в WordPress часто правят по шаблону: закрывают все подряд, а потом удивляются, почему поисковик продолжает видеть дубли или, наоборот, перестаёт обходить важные разделы. На практике задача обычно проще и конкретнее: убрать из обхода служебные URL, не трогая то, что должно индексироваться и сканироваться.
Если сайт уже живёт, у него почти всегда есть лишние точки входа для роботов: служебные страницы плагинов, результаты внутреннего поиска, архивы с тонким контентом, технические параметры, иногда — staging-URL, которые случайно попали в публичную зону. robots.txt не решает все SEO-проблемы, но помогает сократить мусор в обходе и не тратить краулинговый бюджет на очевидно лишнее.
Что именно нужно закрывать, а что нет
Перед правкой файла полезно разделить URL на три группы. Это снижает риск случайно закрыть важные страницы и потом искать причину падения обхода.
Обычно имеет смысл ограничить обход
/wp-admin/— кроме/wp-admin/admin-ajax.php, если он нужен фронтенду;/wp-includes/— служебные файлы ядра;- внутренний поиск, если он создаёт много мусорных URL;
- служебные каталоги плагинов, если они доступны по прямым URL и не нужны в индексе;
- тестовые или временные разделы, если они случайно открыты наружу.
Не стоит закрывать в robots.txt
- страницы, которые должны индексироваться, но просто имеют
noindex; - CSS и JS, нужные для рендеринга страницы;
- файлы, которые участвуют в отображении темы и блоков;
- всё подряд по маске только потому, что «так советовали в статье».
Важно помнить: robots.txt управляет обходом, а не гарантирует удаление из индекса. Если страница уже известна поисковику, одного запрета в robots.txt может быть недостаточно. Для удаления из индекса обычно нужен noindex или корректный ответ сервера.
Диагностика: как понять, что проблема именно в robots.txt
Сначала проверьте, что поисковик вообще видит текущую версию файла. Откройте /robots.txt в браузере и сравните содержимое с тем, что реально лежит на сервере. В WordPress файл может генерироваться плагином SEO, кэшем или серверной конфигурацией, поэтому правка «в админке» не всегда совпадает с тем, что отдается наружу.
Дальше посмотрите на симптомы:
- в отчётах сканирования много URL с параметрами, поиском, архивами или служебными разделами;
- в логах сервера часто встречаются запросы к бесполезным страницам;
- в Search Console есть предупреждения о заблокированных ресурсах или странные URL в разделе обхода;
- страницы, которые должны быть закрыты, продолжают появляться в результатах поиска как «URL без описания».
Если проблема не в обходе, а в индексации уже известных страниц, robots.txt может быть только частью решения. Тогда дополнительно проверяйте мета-теги noindex, canonical и внутренние ссылки.
Как настроить robots.txt в WordPress без лишнего риска
Есть три рабочих подхода: через SEO-плагин, через физический файл в корне сайта и через фильтр WordPress, если нужен программный контроль. Выбор зависит от того, кто поддерживает сайт и как у вас устроен деплой.
| Способ | Когда подходит | Плюс | Минус |
|---|---|---|---|
| SEO-плагин | Если файл правят контент-менеджеры | Удобно и быстро | Легко потерять контроль при смене плагина |
Физический robots.txt | Если есть доступ к серверу или Git-деплой | Прозрачно и предсказуемо | Нужно следить, чтобы его не перезаписывали |
Фильтр robots_txt | Если нужно генерировать правила кодом | Можно версионировать в теме или плагине | Требует аккуратности и тестов |
Вариант 1: базовый robots.txt для WordPress
Если у вас нет особых требований, начните с аккуратного базового файла. Он не закрывает лишнего и не мешает поисковику видеть важные ресурсы.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /author/
Disallow: /tag/
Disallow: /feed/
Sitemap: https://example.com/sitemap_index.xmlЗдесь есть важный нюанс: /author/, /tag/ и /feed/ стоит закрывать только если вы точно понимаете, что эти разделы не нужны в обходе. На некоторых сайтах архивы тегов и авторов дают трафик, и тогда лучше не закрывать их в robots.txt, а управлять индексацией через noindex и canonical.
Вариант 2: генерация через фильтр robots_txt
Если сайт разворачивается из кода, удобнее держать правила рядом с темой или собственным плагином. WordPress отдаёт содержимое robots.txt через фильтр robots_txt.
<?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 );Такой вариант полезен, если у вас несколько окружений и нужно, чтобы на staging и production правила отличались. Но не забывайте: если SEO-плагин тоже генерирует robots.txt, он может перехватить вывод. Тогда нужно оставить один источник правды.
Вариант 3: правка физического файла
Если сервер позволяет, самый понятный путь — положить robots.txt в корень сайта и контролировать его как обычный текстовый файл. Это удобно для Git, CI/CD и аудита изменений. Главное — не забыть, что некоторые хостинги и плагины кеширования могут отдавать старую версию файла, пока не сброшен кэш.
Пошаговое решение для типового WordPress-сайта
- Откройте текущий
https://ваш-домен/robots.txtи сохраните копию. - Проверьте, кто его генерирует: SEO-плагин, сервер, тема или фильтр WordPress.
- Составьте список URL, которые реально не должны обходиться.
- Уберите из файла агрессивные правила вроде
Disallow: /или массовых масок без проверки. - Добавьте только нужные запреты и строку sitemap.
- Сохраните изменения и очистите кэш, если он есть на уровне плагина, сервера или CDN.
- Проверьте файл снова в браузере и через инструменты для проверки robots.txt.
Проверка результата после внедрения
После правки важно не ограничиться просмотром файла в браузере. Нужно убедиться, что поисковый робот видит именно ту версию, которую вы ожидаете, и что важные страницы не оказались под запретом.
- откройте
/robots.txtв режиме инкогнито и проверьте ответ сервера; - посмотрите заголовки ответа через DevTools или
curl; - проверьте sitemap, указанный в файле, и убедитесь, что он доступен;
- в Search Console отправьте файл на повторную проверку, если меняли правила для уже известных URL;
- сравните список заблокированных URL до и после изменения.
Для быстрой проверки с консоли можно использовать:
curl -I https://example.com/robots.txt
curl https://example.com/robots.txtЕсли в ответе видите старое содержимое, значит проблема не в WordPress, а в кэше, CDN или серверной конфигурации. Пока это не исправлено, поисковик может продолжать получать устаревшие правила.
Частые ошибки и как их исправить
Закрыли слишком много
Самая частая ошибка — запретить всё подряд, а потом обнаружить, что поисковик не видит CSS, JS или важные разделы. Исправление простое: уберите широкие маски, оставьте только точечные запреты и проверьте, не блокируются ли ресурсы, нужные для рендеринга.
Путают robots.txt и noindex
Если страница уже в индексе, robots.txt не всегда поможет убрать её быстро. Для удаления из индекса используйте noindex на самой странице или корректный ответ сервера для удалённого контента. robots.txt нужен в первую очередь для управления обходом.
Забывают про sitemap
Если в robots.txt нет строки Sitemap:, поисковику сложнее быстро найти актуальную карту сайта. Это не критическая ошибка, но на больших сайтах лучше указывать sitemap явно.
Редактируют не тот источник
Иногда файл меняют в админке SEO-плагина, а на сервере уже лежит физический robots.txt, который перекрывает вывод. В итоге кажется, что настройки «не работают». Проверьте, какой источник реально отдаёт ответ.
Когда лучше не править robots.txt вручную
Если сайт поддерживается несколькими людьми, а правила обхода завязаны на окружения, ручная правка в админке быстро превращается в источник ошибок. В таких случаях лучше хранить правила в репозитории или управлять ими через один SEO-плагин, чтобы не было расхождений между staging и production.
Если вам нужно не только закрыть лишние страницы, но и системно убрать дубли, служебные архивы и лишние элементы из индекса, удобнее смотреть в сторону комплексной SEO-чистки. Для WordPress это часто решается настройками темы, SEO-плагина и точечным кодом, а не одним файлом robots.txt.
Главный критерий простой: если правило можно объяснить одной конкретной проблемой, его стоит оставить. Если оно выглядит как «на всякий случай», скорее всего, его нужно пересмотреть.