Если в индексе всплывают служебные URL, которые не должны участвовать в поиске, первым делом обычно смотрят на robots.txt. Это нормальная точка входа, но в WordPress здесь легко сделать хуже: закрыть не то, забыть про виртуальный файл, дублировать правила плагином и вручную или попытаться спрятать то, что уже отдается через noindex.
Ниже разберем рабочий сценарий: какие сервисные страницы имеет смысл закрывать в robots.txt, когда это не помогает, как проверить ответ сервера и где чаще всего ошибаются.
Какие страницы WordPress действительно стоит закрывать в robots.txt
robots.txt нужен не для “удаления из поиска”, а для ограничения обхода. Поэтому он полезен там, где URL не должен тратить краулинговый бюджет и не несет ценности для пользователя.
Типичные кандидаты на закрытие
/wp-admin/— административная часть сайта;/wp-login.php— страница входа;/wp-json/— если у вас есть осознанная причина ограничить обход части REST API, но не закрывайте это вслепую;/cgi-bin/— если такой каталог вообще существует на хостинге;- временные технические каталоги и тестовые папки, которые не должны индексироваться.
А вот архивы, пагинацию, attachment-страницы, авторов и даты лучше решать не через robots.txt, если цель — убрать дубли из поиска. Для них важнее корректный canonical, noindex или отключение самих архивов. Иначе поисковик может увидеть URL, но не получить сигнал на удаление из индекса.
Диагностика: что именно сейчас отдает сайт
Перед правкой проверьте, есть ли у сайта виртуальный robots.txt и кто его формирует. В WordPress файл часто не лежит физически в корне, а генерируется системой или SEO-плагином.
Что проверить вручную
- Откройте
https://site.ru/robots.txtв браузере. - Посмотрите, есть ли там правила от темы, SEO-плагина или хостинга.
- Проверьте, не дублируются ли директивы
Disallow. - Убедитесь, что в файле нет случайного
Disallow: /.
Если сайт уже использует SEO-плагин, сначала ищите настройку robots в нем. Ручная правка физического файла на сервере может вообще не влиять на итоговый ответ, если плагин подменяет его на лету.
Быстрая проверка через curl
curl -I https://site.ru/robots.txtВ ответе важны статус 200 и корректный Content-Type. Если вместо текста вы видите редирект, ошибку или HTML-страницу, значит файл отдается не так, как ожидается.
Пошаговая настройка robots.txt в WordPress
Есть три рабочих подхода: через SEO-плагин, через физический файл в корне сайта и через код, если нужно сформировать правила программно. Для большинства проектов удобнее первый вариант, но важно понимать ограничения каждого.
Вариант 1. Настроить через SEO-плагин
Если у вас уже стоит SEO-плагин, используйте его интерфейс для редактирования robots.txt. Это снижает риск конфликта между виртуальным файлом и физическим файлом на сервере. В админке обычно можно добавить свои директивы и сразу увидеть итоговый текст.
Плюс этого способа — меньше ручной возни. Минус — не все плагины одинаково прозрачно показывают, что именно сейчас отдается поисковику. Поэтому после сохранения все равно откройте /robots.txt в браузере.
Вариант 2. Создать физический robots.txt в корне
Если плагин не нужен, можно положить обычный файл robots.txt в корень сайта. Для WordPress это допустимо, но только если вы понимаете, что он не должен конфликтовать с виртуальной генерацией.
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Allow: /wp-admin/admin-ajax.php
Sitemap: https://site.ru/sitemap_index.xmlЗдесь важно не закрыть admin-ajax.php, если он используется темой, формами или фронтенд-скриптами. Это одна из самых частых ошибок: сайт визуально работает, но часть AJAX-запросов начинает вести себя странно у ботов и сервисов проверки.
Вариант 3. Добавить правила через код
Если нужен управляемый вариант без ручного редактирования файла, можно добавить фильтр robots_txt. Это полезно, когда правила должны зависеть от окружения или роли сайта.
<?php
add_filter( 'robots_txt', function( $output, $public ) {
$lines = array(
'User-agent: *',
'Disallow: /wp-admin/',
'Disallow: /wp-login.php',
'Allow: /wp-admin/admin-ajax.php',
'',
'Sitemap: https://site.ru/sitemap_index.xml',
);
return implode( "\n", $lines );
}, 10, 2 );Этот способ подходит для темы или небольшого mu-plugin. Но если у вас уже есть SEO-плагин, проверьте, не перезаписывает ли он robots.txt своим выводом. Иначе вы будете править код, а в браузере видеть совсем другой файл.
Когда robots.txt не решает задачу
Есть важный момент: robots.txt не удаляет URL из индекса сам по себе. Если страница уже известна поисковику, он может продолжать показывать ее без сниппета или с урезанными данными. Для удаления из поиска нужны другие сигналы: noindex, корректный canonical, редирект или статус 404/410 в зависимости от сценария.
Поэтому не пытайтесь закрывать в robots.txt то, что должно исчезнуть из индекса. Например, старые attachment-страницы, архивы автора или дубли пагинации лучше решать отдельной логикой, а не одним файлом.
| Подход | Что делает | Когда использовать | Компромисс |
|---|---|---|---|
| robots.txt | Ограничивает обход | Для служебных URL и каталогов | Не удаляет уже проиндексированные страницы |
| noindex | Просит не индексировать страницу | Для дублей и технических архивов | Страница должна быть доступна для обхода |
| 404/410 | Сообщает, что страницы нет | Для удаленного контента | Нельзя использовать для живых страниц |
Как проверить, что решение сработало
Проверка должна быть не только визуальной. В WordPress легко получить “правильный” файл в браузере и при этом оставить старые правила в кеше или в SEO-плагине.
- Откройте
/robots.txtв браузере и убедитесь, что там именно тот текст, который вы ожидаете. - Проверьте ответ через
curl -Iи убедитесь, что нет редиректа на HTML-страницу. - В Search Console посмотрите, не выросло ли число ошибок обхода после изменения правил.
- Если закрывали
/wp-admin/и/wp-login.php, проверьте, что вход в админку не сломался для пользователей и сервисов, которые должны работать.
Полезно также открыть несколько URL из списка закрытия и посмотреть, не остались ли они доступными через старые кэши CDN или плагина кеширования. Иногда проблема не в robots.txt, а в том, что CDN отдает старую версию файла.
Частые ошибки и как их исправить
Закрыли слишком много
Самая дорогая ошибка — случайно закрыть весь сайт через Disallow: / или заблокировать важные ресурсы темы. Если после правки поисковик перестал нормально обходить сайт, сначала сравните текущий файл с резервной копией и уберите лишние директивы.
Путают robots.txt и noindex
Если задача — убрать URL из индекса, robots.txt не всегда подходит. Страница должна быть доступна для обхода, чтобы поисковик увидел noindex или каноникал. Иначе URL может зависнуть в поиске дольше, чем вы ожидаете.
Редактируют не тот robots.txt
На WordPress часто есть виртуальный robots.txt, а на сервере лежит физический файл. Если SEO-плагин генерирует свой вариант, ручная правка файла в корне ничего не изменит. Сначала выясните источник ответа, потом вносите правки.
Забывают про кеш
После изменения файла очистите кеш плагина, серверный кеш и CDN. Иначе вы будете проверять старую версию и делать ложные выводы.
Практические советы по безопасности и производительности
Не используйте robots.txt как средство защиты. Он не скрывает URL от злоумышленника и не закрывает доступ к админке. Для безопасности нужны нормальные пароли, ограничение попыток входа, 2FA и корректные права на сервере.
Если у вас большой сайт, не раздувайте файл десятками лишних правил. Чем проще robots.txt, тем меньше шансов сломать обход важных разделов. Для сложной технической чистки иногда удобнее использовать специализированные инструменты вроде Clearfy Pro, если вам нужно централизованно управлять дублями, служебными страницами и техническими настройками без ручного редактирования каждого файла.
Если после настройки robots.txt вы видите, что часть URL все равно лезет в индекс, не пытайтесь добить проблему дополнительными запретами. Сначала проверьте, какие страницы реально должны быть закрыты, а какие — просто переадресованы, удалены или помечены как noindex.