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