Если в индексе всплывают служебные URL WordPress, первый инстинкт — сразу править мета-теги или ставить плагин. Но в ряде случаев проблема проще: поисковик тратит краулинговый бюджет на страницы, которые не должны обходиться вообще. Здесь помогает аккуратная настройка robots.txt.
Важно понимать границу: robots.txt не удаляет URL из индекса сам по себе. Он ограничивает обход. Если страница уже проиндексирована, одного запрета в robots.txt может быть недостаточно — тогда нужен отдельный план: снять ссылочную доступность, поставить noindex там, где это уместно, и дождаться переобхода.
Какие URL в WordPress обычно закрывают в robots.txt
Не стоит пытаться закрыть все подряд. В WordPress обычно имеют смысл служебные и технические разделы, которые не несут ценности для поиска и часто создают лишние запросы к серверу.
/wp-admin/— административная часть;/wp-login.php— форма входа;/wp-json/— REST API, если он не нужен для индексации и внешних интеграций;- служебные файлы и каталоги плагинов, если они доступны по прямым URL и не должны индексироваться;
- поисковые выдачи сайта, если они генерируют мусорные страницы и не нужны в поиске.
При этом не надо закрывать CSS, JS и изображения только потому, что они лежат в /wp-content/. Современные поисковые системы должны видеть ресурсы страницы, иначе можно получить проблемы с рендерингом и оценкой мобильной версии.
Диагностика: что именно мешает индексации и что уже попало в поиск
Перед правкой файла проверьте, какие URL реально индексируются и откуда они берутся. Частая ошибка — закрыть не то, а потом удивляться, что поисковик продолжает показывать старые адреса.
Что смотреть в первую очередь
- отчет по страницам в Google Search Console или Яндекс.Вебмастере;
- лог обхода, если он доступен;
- результат поиска по оператору
site:domain.ru; - наличие внутренних ссылок на служебные URL в теме, меню, виджетах и плагинах.
Если URL получает трафик или на него ведут внутренние ссылки, сначала уберите источник ссылки. Иначе вы просто спрячете симптом, а не причину.
Мини-проверка перед изменениями
curl -I https://example.com/wp-login.phpОтвет сервера поможет понять, доступен ли URL напрямую. Если страница отдает 200 OK, это не значит, что ее надо закрывать в robots.txt, но значит, что она существует и может участвовать в обходе.
Какой вариант настройки выбрать: вручную, через плагин или код
Если задача точечная и сайт небольшой, проще всего отредактировать robots.txt вручную. Если проект живой, с несколькими средами и частыми правками, удобнее держать логику в коде или в плагине, который умеет управлять robots без ручного редактирования файла.
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Ручной robots.txt | Небольшой сайт, редкие изменения | Быстро и прозрачно | Легко перезаписать при миграции или обновлении настроек хостинга |
| Плагин | Контент-менеджер правит настройки без разработчика | Удобно для редакции | Лишняя зависимость от плагина |
| Код в теме/му-плагине | Нужна стабильная логика на проекте | Контроль в репозитории | Требует аккуратного деплоя |
Если вы уже используете набор для технической чистки сайта, например Clearfy Pro, проверьте, не дублирует ли он ваши правила. Двойная логика в robots.txt — частая причина конфликтов.
Пошаговая настройка robots.txt в WordPress
Шаг 1. Проверьте, где сейчас лежит robots.txt
В WordPress файл может быть физическим в корне сайта, а может генерироваться виртуально. Если на сервере уже есть реальный robots.txt, именно он обычно имеет приоритет. Это важно: вы можете править настройки в админке, а поисковик будет читать старый файл с диска.
Шаг 2. Добавьте только нужные директивы
Базовый пример для служебных разделов выглядит так:
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /cgi-bin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xmlЗдесь есть важный момент: admin-ajax.php часто нужен фронтенду и плагинам, поэтому его обычно не закрывают. Если вы заблокируете его без понимания последствий, можно сломать формы, фильтры, подгрузку контента и часть интерактивных блоков.
Шаг 3. Не закрывайте то, что должно быть доступно поисковику
Не добавляйте в Disallow каталоги со стилями, скриптами и изображениями, если они участвуют в рендеринге страниц. Также не стоит закрывать /wp-content/uploads/ целиком только из-за страха перед дублями: это может мешать индексации полезных медиафайлов и превью.
Шаг 4. Если нужно, добавьте отдельные правила для мусорных разделов
Например, если сайт генерирует внутренний поиск с параметрами, которые не должны обходиться, можно закрыть именно этот шаблон URL. Но не пытайтесь лечить все параметры через один универсальный запрет, если на сайте есть важные фильтры или страницы с параметрами, которые реально используются.
User-agent: *
Disallow: /?s=
Disallow: /search/
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.phpТакой вариант стоит применять только после проверки, как именно у вас формируются URL поиска. На некоторых темах и плагинах адреса отличаются.
Проверка результата после внедрения
После сохранения файла не ограничивайтесь тем, что он открывается в браузере. Нужно проверить, что поисковик видит именно ту версию, которую вы ожидаете.
- откройте
/robots.txtв браузере и убедитесь, что там актуальный текст; - проверьте заголовки и код ответа через
curl -I; - в Search Console отправьте robots.txt на повторную проверку, если инструмент это предлагает;
- проверьте, не исчезли ли из обхода нужные ресурсы;
- посмотрите, не выросло ли число ошибок сканирования после изменения.
Пример быстрой проверки содержимого файла:
curl https://example.com/robots.txtЕсли сайт за прокси, CDN или кэширующим плагином, убедитесь, что отдаётся свежая версия. Иногда браузер показывает одно, а бот получает старый файл из кэша.
Частые ошибки и как их исправить
Закрыли слишком много
Самая дорогая ошибка — запретить доступ к CSS, JS, изображениям или важным API-эндпоинтам. Симптомы обычно такие: страницы в поиске есть, но в отчётах по качеству рендеринга появляются проблемы, а мобильная версия оценивается хуже.
Решение простое: уберите лишние Disallow, оставьте только служебные URL и проверьте, что фронтенд работает без ошибок.
Ожидали, что robots.txt удалит URL из индекса
Не удалит. Если страница уже известна поисковику, он может продолжать показывать ее как URL без сниппета. Для удаления нужен другой механизм: корректный noindex, снятие внутренних ссылок, а иногда и удаление самой страницы.
Правили не тот файл
На хостинге или в плагине мог быть один robots.txt, а в корне сайта — другой. В таком случае поисковик читает не то, что вы редактировали в админке. Проверьте физический файл и настройки кэша.
Перепутали robots.txt и noindex
robots.txt — про обход, noindex — про индексацию. Если у вас задача именно убрать страницу из выдачи, а не просто сократить обход, используйте правильный инструмент. Иначе можно получить ситуацию, когда URL не сканируется, но продолжает жить в индексе по старым сигналам.
Практические советы по безопасности и производительности
Не открывайте в robots.txt лишнюю служебную информацию. Сам файл часто читают не только поисковые боты, но и сканеры. Чем меньше в нем лишних подсказок о структуре админки и внутренних путях, тем лучше.
Если сайт большой, а служебных запросов много, полезно дополнительно проверить, не генерирует ли тема или плагин лишние обращения к /wp-admin/admin-ajax.php. Иногда проблема не в robots.txt, а в тяжелом фронтенде, который постоянно дергает AJAX без необходимости.
Для проектов с частыми изменениями безопаснее хранить правила в репозитории и деплоить их вместе с кодом. Тогда вы не потеряете настройки после миграции, а изменения будут воспроизводимы.
Если нужен не только robots.txt, но и системная чистка дублей, технических страниц и лишних настроек, имеет смысл смотреть в сторону инструментов, которые закрывают несколько задач сразу, а не собирать это вручную из случайных плагинов.
Короткий чек-лист перед публикацией
- Проверен текущий источник robots.txt.
- Не закрыты CSS, JS и изображения без причины.
- Оставлен доступ к
admin-ajax.php, если он нужен фронтенду. - Сайт не потерял важные ресурсы в рендеринге.
- В Search Console/Вебмастере нет новых ошибок обхода.
- Служебные URL больше не попадают в активный обход без необходимости.
Если после правки вы видите, что поисковик все равно обходит старые адреса, проверьте внутренние ссылки, карту сайта и кэш. В WordPress технические проблемы редко живут в одном месте: обычно это связка из темы, плагинов и настроек сервера.