Если в индексе всплывают служебные URL, это не всегда проблема мета-тегов. Часто поисковик просто видит лишние разделы сайта: /wp-admin/, /wp-login.php, служебные файлы, внутренние поисковые страницы, архивы с параметрами или технические каталоги темы и плагинов. В WordPress это обычно решают через robots.txt, но здесь легко переборщить и случайно закрыть важные ресурсы.
Ниже — рабочий сценарий: что именно закрывать, как это сделать без конфликтов с WordPress и как проверить, что правило реально сработало.
Когда robots.txt действительно нужен
robots.txt полезен не для «секретности», а для управления обходом. Он помогает сократить мусорный crawl budget и убрать из обхода заведомо технические адреса. Но он не заменяет noindex и не удаляет уже проиндексированные страницы мгновенно.
Типичные служебные URL, которые можно ограничить
/wp-admin/— административная часть сайта;/wp-login.php— страница входа;/wp-includes/— внутренние файлы WordPress;/xmlrpc.php— если вы не используете XML-RPC;- служебные каталоги плагинов, если они доступны по прямым URL и не нужны в поиске;
- страницы внутреннего поиска, если они создают много мусорных URL.
При этом нельзя бездумно закрывать /wp-content/uploads/, если у вас там лежат изображения, которые должны индексироваться и участвовать в поиске по картинкам. То же касается CSS и JS: если вы закроете слишком много, поисковик может хуже рендерить страницу.
Диагностика проблемы: что именно попало в обход
Перед правкой файла стоит посмотреть, какие URL реально создают шум. Откройте отчёты поисковой системы, проверьте логи сервера или просто выполните ручной поиск по сайту в формате site:example.ru. Если в выдаче есть страницы входа, служебные архивы или параметры сортировки, это сигнал, что robots.txt стоит привести в порядок.
Полезно проверить и сам файл. В WordPress он обычно доступен по адресу /robots.txt. Если там уже есть правила от плагина SEO или кэша, не надо создавать второй файл на сервере и ждать, что они «сложатся» сами. В WordPress приоритет может быть у виртуального robots.txt, который генерируется системой или плагином.
Какой вариант настройки выбрать
| Подход | Когда подходит | Минус |
|---|---|---|
| Редактировать robots.txt через плагин SEO | Если уже используете SEO-плагин и не хотите трогать код | Зависимость от интерфейса и настроек плагина |
| Добавить фильтр в тему или мини-плагин | Если нужен точный контроль и стабильное правило | Нужно аккуратно поддерживать код |
| Править файл в корне сайта вручную | Если у вас статический robots.txt без виртуальной генерации | Можно конфликтовать с WordPress и плагинами |
Для большинства проектов с WordPress практичнее использовать фильтр robots_txt. Так вы не зависите от ручного редактирования файла и можете централизованно управлять правилами.
Пошаговое решение через код
Если нужен предсказуемый результат, добавьте правило через фильтр robots_txt. Это безопаснее, чем хранить отдельный файл в корне, если WordPress уже генерирует robots динамически.
add_filter( 'robots_txt', function( $output, $public ) {
$rules = array(
'User-agent: *',
'Disallow: /wp-admin/',
'Disallow: /wp-login.php',
'Disallow: /wp-includes/',
'Disallow: /xmlrpc.php',
);
// Не закрываем админку полностью для роботов, но оставляем доступ к admin-ajax.php.
$rules[] = 'Allow: /wp-admin/admin-ajax.php';
return implode( "\n", $rules ) . "\n";
}, 10, 2 );Этот вариант подходит, если вы хотите переопределить стандартный вывод. Но если у вас уже есть важные правила от SEO-плагина, лучше не заменять всё целиком, а дописывать только нужные строки.
Более аккуратный вариант — добавить свои правила к существующему содержимому:
add_filter( 'robots_txt', function( $output, $public ) {
$extra = array(
'Disallow: /wp-admin/',
'Disallow: /wp-login.php',
'Disallow: /xmlrpc.php',
);
return $output . "\n" . implode( "\n", $extra ) . "\n";
}, 20, 2 );Если вы используете дочернюю тему, такой код можно временно проверить в functions.php. Для постоянной поддержки лучше вынести его в небольшой mu-plugin, чтобы правило не пропало после смены темы.
Когда лучше не закрывать wp-includes целиком
На старых проектах часто советуют закрыть /wp-includes/ полностью. На практике это не всегда оправдано: некоторые файлы из этой папки могут быть нужны для корректного рендеринга страниц. Если вы не уверены, начните с закрытия только /wp-admin/, /wp-login.php и /xmlrpc.php, а затем смотрите отчёты обхода.
Если нужен ручной robots.txt
Иногда на сайте уже есть физический файл robots.txt в корне, и WordPress его не переопределяет. Тогда можно отредактировать его вручную через FTP или файловый менеджер хостинга. Базовый пример выглядит так:
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /xmlrpc.php
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.ru/sitemap.xmlЗдесь важно не забыть строку с картой сайта, если она у вас есть. Поисковику проще находить актуальные URL, когда sitemap указан прямо в robots.txt.
Проверка результата после внедрения
После правки не ограничивайтесь открытием файла в браузере. Проверьте несколько вещей:
- открывается ли
/robots.txtбез ошибки 404; - видны ли нужные директивы именно в том виде, как вы их задали;
- не пропали ли правила, которые добавлял SEO-плагин;
- не закрыли ли вы случайно CSS, JS или изображения;
- не остались ли в индексе старые служебные URL, которые нужно добивать уже через
noindexили удаление страниц.
Технически проверить можно и через консоль:
curl -I https://example.ru/robots.txt
curl https://example.ru/robots.txtЕсли сервер отдаёт 200 OK и в ответе есть ваши директивы, базовая часть настроена правильно. Дальше смотрите отчёты в панели вебмастера: там обычно видно, не заблокировали ли вы случайно важные ресурсы.
Частые ошибки и как их исправить
Закрыли слишком много
Самая частая ошибка — запретить всё подряд, включая папки с ресурсами темы и плагинов. В результате поисковик хуже видит страницу, а иногда начинает считать её менее качественной из-за проблем с рендерингом. Исправление простое: уберите лишние Disallow и оставьте только реально служебные адреса.
Путают robots.txt и noindex
robots.txt запрещает обход, но не гарантирует удаление URL из индекса. Если страница уже в выдаче, одного robots.txt может быть мало. Для таких случаев нужен noindex, редирект или удаление страницы с корректным кодом ответа.
Создали физический файл, а WordPress отдаёт другой
Так бывает, если сайт использует виртуальный robots.txt или SEO-плагин генерирует свой вариант. Проверьте, какой именно источник отдаёт файл, и не держите одновременно несколько конфликтующих реализаций.
Не учли кэш
После правки robots.txt кэш на сервере или CDN может ещё какое-то время отдавать старую версию. Очистите кэш и проверьте ответ повторно из режима инкогнито или через curl.
Практические советы по безопасности и производительности
Если вы закрываете /wp-login.php и /wp-admin/, это не защита от атак. Для безопасности нужны отдельные меры: сложные пароли, ограничение попыток входа, 2FA и актуальные обновления. Robots.txt здесь работает только как вспомогательная мера, чтобы не светить служебные URL в обходе.
Для производительности полезно не перегружать robots.txt десятками правил без необходимости. Чем короче и понятнее файл, тем меньше риск ошибки при сопровождении. Если у вас большой сайт с SEO-плагином, проверьте, не дублируются ли правила в нескольких местах: в теме, в плагине и в физическом файле.
Если нужен более широкий контроль над дублями, архивами и служебными страницами, иногда удобнее использовать SEO-плагин с настройками индексации и очистки, например Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае важно понимать, какие правила он генерирует, а не включать их вслепую.
Что проверить после публикации статьи на сайте
/robots.txtотдаёт актуальные правила;- служебные URL больше не попадают в новые обходы;
- важные ресурсы темы и плагинов не закрыты;
- в sitemap остались только нужные страницы;
- в панели вебмастера нет новых ошибок обхода после изменения файла.
Если всё это сходится, настройка выполнена корректно. Если нет — сначала ищите конфликт между физическим файлом, виртуальной генерацией WordPress и SEO-плагином, а уже потом добавляйте новые директивы.