Если в индексе всплывают служебные URL, архивы, страницы авторов, результаты поиска или технические разделы, часто первым делом лезут в robots.txt. Это нормальный инструмент, но только если понимать его границы: он не удаляет страницы из индекса, а лишь подсказывает роботам, куда не ходить. Для WordPress это особенно важно, потому что часть лишних адресов создаётся ядром, темой и плагинами автоматически.
Ниже — рабочий сценарий: что проверять, что закрывать, как не испортить обход сайта и чем robots.txt отличается от noindex.
Когда robots.txt действительно нужен
Файл полезен, если вы хотите сократить обход мусорных URL и не тратить краулинговый бюджет на заведомо бесполезные разделы. На небольшом сайте это не критично, но на проекте с большим количеством архивов, фильтров, вложений и служебных страниц эффект заметен быстрее.
Типичные кандидаты на закрытие:
/wp-admin/— административная часть;/wp-includes/— внутренние файлы ядра;/wp-content/plugins/и/wp-content/themes/— каталоги с кодом, а не контентом;- служебные параметры поиска и сортировки, если они генерируют мусорные URL;
- временные или тестовые разделы, которые не должны обходиться роботами.
Но если страница уже попала в индекс, одного Disallow недостаточно. В таком случае нужен отдельный контроль через noindex, canonical или удаление страницы из выдачи через Search Console.
Диагностика: что именно мешает индексации
Перед правкой файла посмотрите, какие URL реально создают шум. В WordPress это обычно не «весь сайт», а несколько повторяющихся шаблонов адресов. Откройте отчёты поисковой системы, логи сервера или хотя бы список страниц, которые чаще всего появляются в обходе.
Что проверить вручную
- есть ли в индексе страницы поиска вида
?s=; - появляются ли архивы автора, даты, теги без смысла для поиска;
- индексируются ли вложения медиафайлов как отдельные страницы;
- не создаёт ли плагин фильтров десятки параметров в URL;
- не закрыт ли случайно CSS, JS или изображения, которые нужны для рендеринга.
Последний пункт особенно важен: если закрыть слишком много, поисковик может хуже понимать страницу. Это уже не про экономию обхода, а про риск ухудшить качество индексации.
Какой подход выбрать: плагин, вручную или через сервер
Для WordPress есть три нормальных варианта. Выбор зависит от того, кто будет поддерживать сайт и насколько сложные правила нужны.
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин SEO/оптимизации | Нужны базовые правила без правки файлов | Удобно, меньше риска ошибки | Зависимость от интерфейса плагина |
Ручной robots.txt | Нужен точный контроль | Прозрачно, легко проверить | Можно ошибиться в синтаксисе |
| Правка на уровне сервера | Сложная инфраструктура, нестандартная отдача файла | Гибкость | Нужен доступ к серверу и опыт |
Если задача обычная, достаточно ручного файла или настроек SEO-плагина. Если сайт уже использует плагин, который умеет управлять robots.txt, не плодите дублирующие правила в нескольких местах.
Пошаговая настройка robots.txt в WordPress
1. Проверьте, есть ли файл уже сейчас
Откройте https://ваш-домен.ru/robots.txt. В WordPress файл может отдаваться виртуально, даже если физически его нет в корне. Это нормально, но важно понимать, кто именно его формирует: ядро, плагин или сервер.
2. Составьте минимальный набор правил
Для большинства сайтов достаточно базового каркаса. Он не должен быть перегружен десятком сомнительных директив. Пример:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/
Disallow: /search/
Disallow: /?s=
Sitemap: https://example.com/sitemap_index.xmlЗдесь есть важная оговорка: строка Disallow: /?s= не универсальна для всех поисковиков и не заменяет нормальную настройку страниц поиска через noindex. Если поиск создаёт отдельные URL с параметрами, лучше решать это на уровне шаблона или SEO-плагина.
3. Не закрывайте то, что нужно для рендеринга
Если тема или плагин грузит стили и скрипты из нестандартных каталогов, проверьте, не попали ли они под запрет. Поисковики должны видеть ресурсы, которые влияют на отображение страницы. Иначе можно получить странные проблемы в рендеринге и некорректную оценку страницы.
4. Сохраните файл в одном месте
Если вы редактируете robots.txt вручную, убедитесь, что он действительно лежит в корне сайта и не перезаписывается плагином. Если правила задаются через SEO-плагин, не дублируйте их в физическом файле без необходимости.
Пример более аккуратного robots.txt для WordPress
Ниже — вариант для сайта, где нужно закрыть служебные каталоги, но оставить доступ к ресурсам, которые участвуют в загрузке страниц:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/
Disallow: /trackback/
Disallow: /comments/feed/
Disallow: /feed/
Sitemap: https://example.com/sitemap_index.xmlЭтот вариант не идеален для каждого проекта, но он показывает логику: закрываем служебное, не мешаем работе сайта и не пытаемся через robots.txt решить задачи, которые он не решает.
Проверка результата после внедрения
После правки не ограничивайтесь тем, что файл открылся в браузере. Проверьте несколько вещей:
https://ваш-домен.ru/robots.txtотдаёт актуальный текст без ошибок;- в Search Console или аналогичном инструменте нет массовых ошибок сканирования из-за запрета важных ресурсов;
- страницы, которые вы хотели скрыть от обхода, действительно получают статус
Disallowпри проверке URL; - в индексе не остаются старые служебные URL, если для них нужен был не только
robots.txt, но иnoindex; - основные страницы сайта продолжают нормально обходиться и попадать в отчёты.
Если у вас есть доступ к серверным логам, посмотрите, уменьшилось ли количество обращений к закрытым разделам. Это хороший практический индикатор, что правила работают.
Частые ошибки и как их исправить
Закрыли страницу, но она всё ещё в индексе
Это ожидаемо. robots.txt не удаляет URL из индекса мгновенно. Если страница уже известна поисковику, добавьте noindex или уберите её из сайта и дождитесь переобхода.
Случайно закрыли CSS и JS
Такое бывает, когда в Disallow попадает слишком широкий каталог. Проверьте, не блокируются ли файлы, которые нужны для отображения страниц. Если блокируются — уберите правило или сузьте его.
Используют несколько источников правил
Один файл лежит в корне, второй генерирует SEO-плагин, третий правит сервер. В итоге непонятно, какой вариант видит робот. Оставьте один источник истины и документируйте его для команды.
Пытаются закрыть всё подряд
Иногда в robots.txt добавляют десятки строк на всякий случай. Это плохая практика: файл становится трудно поддерживать, а риск случайно перекрыть нужные URL растёт. Лучше короткий и понятный набор правил.
Безопасность и производительность: что важно не забыть
robots.txt не защищает от доступа. Если каталог действительно должен быть закрыт по безопасности, используйте серверные ограничения, авторизацию или удаление лишних файлов. Не рассчитывайте, что запрет для роботов скроет чувствительные данные.
С точки зрения производительности полезно не только закрыть мусорные разделы, но и убрать причины их появления. Например, если плагин создаёт лишние архивы или параметры, иногда проще отключить саму генерацию, чем потом бесконечно запрещать URL в robots.txt.
Если нужен более широкий набор технических настроек для WordPress — от чистки лишних архивов до управления мета-тегами и служебными страницами — обычно удобнее решать это через один инструмент, а не набор разрозненных правок. В таких сценариях часто используют Clearfy Pro, если он уже есть в стеке и подходит по задаче.
Главное правило простое: robots.txt — это фильтр для обхода, а не универсальная кнопка «убрать из поиска». Когда задача сформулирована точно, файл помогает. Когда его используют вместо noindex или удаления страниц, начинаются ложные ожидания и лишняя возня с индексацией.