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