Если в индексе всплывают служебные страницы WordPress — результаты поиска, страницы авторов, архивы по датам, служебные URL плагинов, — первый импульс обычно один: «закрою всё через robots.txt». Это рабочий инструмент, но только для части задач. Ошибка здесь не в самом файле, а в том, что его используют как универсальный выключатель индексации.
Ниже разберём, какие страницы действительно имеет смысл ограничивать через robots.txt, где нужен noindex, как не сломать обход сайта и как проверить, что поисковики увидели изменения.
Когда robots.txt подходит, а когда нет
robots.txt управляет обходом, а не гарантированной деиндексацией. Если страница уже известна поисковику и на неё есть ссылки, запрет на обход не всегда означает её исчезновение из выдачи. Поэтому для служебных страниц с контентом, который уже попал в индекс, чаще нужен noindex или canonical на основную версию.
Через robots.txt удобно закрывать:
- служебные разделы, которые не должны обходиться вообще;
- внутренний поиск по сайту;
- страницы предпросмотра и технические URL, если они не нужны поисковым роботам;
- параметры, создающие мусорные дубли, если они не участвуют в индексации.
Не стоит пытаться закрыть через robots.txt всё подряд, если задача — убрать уже проиндексированные страницы. В таком случае поисковик может продолжать показывать URL без описания, но сам адрес останется в индексе.
Диагностика: что именно нужно закрыть
Перед правкой файла полезно понять, откуда берутся дубли и служебные страницы. Иначе легко закрыть лишнее и случайно ограничить обход нужных разделов.
Проверьте типичные источники мусора
/search/или страницы с результатами внутреннего поиска;- архивы автора, если на сайте один автор и архив не несёт пользы;
- архивы по датам, если они дублируют рубрики;
- страницы с параметрами сортировки и фильтрации;
- технические URL плагинов, которые не должны индексироваться;
- тестовые и служебные страницы, оставшиеся после разработки.
Если сайт уже в индексе, откройте отчёт по страницам в Google Search Console или Яндекс Вебмастере и посмотрите, какие URL реально попали в выдачу. Это важнее, чем абстрактный список «что обычно закрывают».
Пошаговая настройка robots.txt в WordPress
В WordPress файл robots.txt может быть виртуальным, если физического файла в корне нет. Это удобно: правила можно отдавать через код, не трогая файловую систему. Но если у вас уже есть физический robots.txt, проверьте, не конфликтует ли он с правилами плагина SEO или хостинга.
Вариант 1: редактировать физический robots.txt
Подходит, если у вас есть доступ к корню сайта и вы хотите управлять правилами напрямую. Пример базового файла для WordPress:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /search/
Disallow: /?s=
Disallow: /author/
Disallow: /date/
Disallow: /tag/
Sitemap: https://example.com/sitemap_index.xmlЗдесь есть важный нюанс: строка Disallow: /?s= не всегда покрывает все варианты внутреннего поиска, если URL формируется в другом виде. Поэтому лучше дополнительно закрыть сам шаблон поиска на уровне темы или SEO-плагина через noindex.
Вариант 2: отдать robots.txt через фильтр WordPress
Если вы не хотите держать файл в корне или сайт разворачивается в нескольких средах, можно сформировать правила через фильтр robots_txt. Это штатный фильтр WordPress, он не выдуман и работает для виртуального robots.
<?php
add_filter( 'robots_txt', function( $output, $public ) {
$lines = array(
'User-agent: *',
'Disallow: /wp-admin/',
'Allow: /wp-admin/admin-ajax.php',
'Disallow: /search/',
'Disallow: /author/',
'Disallow: /date/',
'Disallow: /tag/',
'Sitemap: https://example.com/sitemap_index.xml',
);
return implode( "\n", $lines ) . "\n";
}, 10, 2 );Такой подход удобен, если правила должны быть частью темы или небольшого mu-plugin. Но не забывайте: если SEO-плагин тоже генерирует robots, нужно проверить, кто именно отдаёт финальный ответ.
Что лучше закрывать через noindex, а не через robots.txt
Есть страницы, которые поисковику лучше показать, но без индексации. Для этого подходит noindex. Типичный пример — архивы автора на сайте с одним редактором или архивы дат, которые не несут самостоятельной ценности.
Если вы используете SEO-плагин, обычно проще задать noindex в его настройках. Если нужно сделать это кодом, используйте фильтр wp_robots, который добавляет директивы robots meta.
<?php
add_filter( 'wp_robots', function( $robots ) {
if ( is_author() || is_date() || is_search() ) {
$robots['noindex'] = true;
$robots['nofollow'] = true;
}
return $robots;
} );Это не замена robots.txt, а другой уровень управления. Важно не смешивать их без понимания цели: robots.txt ограничивает обход, noindex — индексацию.
Сравнение подходов
| Подход | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| robots.txt | Нужно ограничить обход служебных URL | Просто, быстро, подходит для технических разделов | Не гарантирует удаление уже проиндексированных страниц |
| noindex | Страница должна быть доступна, но не в индексе | Точнее управляет индексацией | Нужен обход страницы роботом |
| canonical | Есть дубль, который должен указывать на основную версию | Помогает объединять сигналы | Не подходит для полного скрытия служебных страниц |
Проверка результата после внедрения
После правки не ограничивайтесь открытием файла в браузере. Проверьте, что поисковик видит именно тот ответ, который вы ожидаете.
- Откройте
/robots.txtв браузере и убедитесь, что файл отдаётся без редиректов и ошибок. - Проверьте, не перезаписывает ли robots SEO-плагин.
- В Google Search Console используйте проверку URL для страниц, которые должны быть закрыты.
- Посмотрите исходный код страниц с
noindexи убедитесь, что директива реально присутствует. - Проверьте логи сервера или инструменты аналитики, если нужно понять, продолжают ли роботы ходить в закрытые разделы.
Для быстрой проверки можно использовать curl:
curl -I https://example.com/robots.txt
curl -s https://example.com/robots.txtЕсли вы настраивали noindex, проверьте HTML страницы и наличие meta robots:
curl -s https://example.com/author/admin/ | grep -i robotsЧастые ошибки и как их исправить
Закрыли в robots.txt то, что уже в индексе
Если URL уже проиндексирован, одного запрета на обход мало. Добавьте noindex, снимите внутренние ссылки на эту страницу и дождитесь переобхода.
Случайно закрыли важные разделы
Частая ошибка — слишком общий шаблон, например Disallow: /tag/ на сайте, где теги дают полезный трафик. Перед публикацией проверьте, какие URL начинаются с этого пути, и не заденете ли вы нужные страницы.
Конфликт robots.txt от плагина и вручную созданного файла
Если в корне лежит физический robots.txt, а SEO-плагин генерирует виртуальный, вы можете видеть не тот набор правил, который ожидаете. Оставьте один источник правды.
Путают canonical и noindex
canonical не скрывает страницу, а подсказывает основную версию. Если задача — убрать служебный URL из индекса, canonical сам по себе не решит проблему.
Практические советы по безопасности и производительности
Не добавляйте в robots.txt правила, которые раскрывают внутреннюю структуру сайта без необходимости. Файл доступен публично, и по нему легко понять, какие разделы вы считаете служебными.
Если у вас большой сайт, не делайте robots.txt слишком длинным и хаотичным. Слишком много точечных правил усложняет поддержку и повышает риск ошибки при следующем обновлении темы или плагина.
Для сайтов, где часто появляются дубли из-за параметров, полезно сначала решить источник проблемы: отключить лишние query-параметры, настроить canonical, убрать генерацию мусорных ссылок в шаблоне. Robots.txt здесь — не лечение, а ограничитель.
Если нужен более системный контроль за дублями, служебными архивами и мета-данными, иногда проще вынести это в SEO-плагин или использовать Clearfy Pro от WPShop: https://wpshop.ru/plugins/clearfy. Но даже в этом случае логику закрытия лучше понимать вручную, а не полагаться на пресет.
Мини-чек-лист перед публикацией
- Поняли, что именно нужно: запрет обхода или запрет индексации.
- Проверили, нет ли уже проиндексированных URL.
- Убедились, что robots.txt не конфликтует с SEO-плагином.
- Добавили только те пути, которые действительно служебные.
- Проверили ответ
/robots.txtи исходный код страниц сnoindex. - Сделали повторную проверку в Search Console или Вебмастере после переобхода.
Если после изменений служебные страницы всё ещё появляются в выдаче, не расширяйте запреты вслепую. Сначала проверьте, есть ли на них внутренние ссылки, sitemap, canonical и meta robots. В WordPress именно эти четыре точки чаще всего и создают иллюзию, что «robots не работает».