Почему robots.txt не закрывает страницы от индексации в WordPress и что делать вместо этого

Если в WordPress страницы продолжают попадать в поиск, а в robots.txt уже стоит запрет, проблема обычно не в самом файле. robots.txt управляет сканированием, но не гарантирует удаление URL из индекса. Для закрытия от индексации нужны другие механизмы: noindex, корректные канонические URL, иногда — защита на уровне сервера или доступ по авторизации.

Ниже — разбор типичного сценария: вы закрыли раздел, но он всё ещё виден в Google или Яндексе. Покажу, как диагностировать причину, что менять в WordPress и как проверить результат без гадания.

Что именно ломается: сканирование, индексация или дубли

Сначала важно понять, что вы пытаетесь остановить. Это разные задачи.

  • Сканирование — поисковик может заходить на URL и читать его содержимое.
  • Индексация — URL может храниться в базе поисковика и показываться в выдаче.
  • Дубли — в индекс попадают несколько версий одной и той же страницы: с параметрами, со слешем и без, с пагинацией, с архивами автора и т. д.

robots.txt влияет в первую очередь на сканирование. Если URL уже известен поисковику, он может остаться в выдаче даже после запрета в robots.txt, особенно если на него есть внешние или внутренние ссылки.

Диагностика проблемы: что проверить до правок

Перед изменениями откройте нужный URL в браузере и проверьте три вещи: код ответа, мета-тег robots и канонический адрес. Если есть доступ к серверу, полезно посмотреть заголовки ответа.

1. Проверка в исходном коде страницы

Ищите в <head> такие элементы:

<meta name="robots" content="noindex, nofollow">
<link rel="canonical" href="https://example.com/page/">

Если на странице стоит index, follow или вообще нет мета-тега robots, поисковик не получает явного сигнала не индексировать URL.

2. Проверка заголовков ответа

Для не-HTML файлов, архивов и некоторых сценариев удобнее смотреть заголовки. Например:

curl -I https://example.com/private-page/

Если страница должна быть закрыта, а сервер отвечает 200 OK без X-Robots-Tag: noindex, поисковик всё ещё может её индексировать.

3. Проверка дублей

Частая ошибка — закрыть одну версию URL, но оставить доступными другие:

  • /page и /page/;
  • ?replytocom=;
  • страницы пагинации архивов;
  • архивы тегов и авторов;
  • страницы поиска по сайту.

Если дубли не сведены в одну каноническую версию, запрет в robots.txt не решает проблему полностью.

Что делать вместо robots.txt: рабочая схема

Для WordPress обычно нужен не один инструмент, а связка из нескольких. Выбор зависит от того, что именно вы закрываете.

ПодходКогда использоватьПлюсыМинусы
robots.txtЧтобы уменьшить сканирование служебных URLПросто, быстроНе убирает URL из индекса само по себе
noindexДля архивов, тегов, страниц поиска, тонких страницЯвный сигнал поисковикуНужно, чтобы страница была доступна для обхода
401/403 или авторизацияДля приватных разделовНадёжно закрывает контентНе подходит для публичных страниц
Удаление URL через Search Console / ВебмастерЕсли нужно ускорить исчезновение из выдачиПомогает снять старые URLЭто не замена технической настройке

Вариант 1: закрыть страницу от индексации через WordPress

Если у вас есть доступ к SEO-плагину, проще всего поставить noindex на конкретный тип страниц. Вручную это тоже можно сделать через wp_head, но только если вы понимаете, что именно закрываете.

add_action('wp_head', function () {
    if (is_page('private')) {
        echo '<meta name="robots" content="noindex, nofollow">' . "\n";
    }
});

Этот пример годится только как точечное решение. Для массовой настройки лучше использовать SEO-плагин или фильтры темы, чтобы не плодить хрупкий код в шаблоне.

Вариант 2: закрыть архивы, теги и поиск

Если задача — убрать из индекса служебные страницы, логичнее работать на уровне шаблонов и SEO-настроек. В WordPress чаще всего закрывают:

  • страницы поиска;
  • архивы тегов, если они пустые или почти пустые;
  • архивы авторов на сайтах с одним автором;
  • страницы вложений, если они не нужны как отдельные посадочные;
  • пагинацию, если она создаёт мусорные дубли.

Для вложений полезно не только закрыть их от индексации, но и настроить редирект на файл или родительскую запись, если это соответствует структуре сайта.

Вариант 3: закрыть доступ на уровне сервера

Если контент действительно приватный, не ограничивайтесь мета-тегами. Для закрытых разделов лучше использовать авторизацию, Basic Auth, IP-ограничение или хотя бы 403 Forbidden. Тогда поисковик не сможет получить содержимое вообще.

Пример для Nginx, если нужно закрыть каталог с приватными файлами:

location /private-files/ {
    deny all;
    return 403;
}

Для Apache аналогичный эффект можно получить через .htaccess, но синтаксис зависит от конфигурации сервера. Если вы не уверены, лучше не править его вслепую.

Пошаговое решение для WordPress-сайта

  1. Определите, какие URL нужно убрать: отдельные страницы, архивы, параметры, файлы, поиск.
  2. Проверьте, есть ли у этих URL внутренние ссылки из меню, хлебных крошек, виджетов и карты сайта.
  3. Поставьте noindex на нужные типы страниц.
  4. Уберите их из XML-карты сайта, если они не должны индексироваться.
  5. Проверьте канонические URL и редиректы.
  6. Если URL уже в индексе, отправьте запрос на переобход или удаление в инструментах для вебмастеров.

Если вы используете SEO-плагин, проверьте, не конфликтует ли он с ручными правками в теме. Два разных источника noindex и разные канонические URL часто создают путаницу.

Пример кода: закрыть страницы по шаблону и убрать их из sitemap

Ниже пример для дочерней темы или небольшого плагина. Он добавляет noindex на конкретную страницу и исключает её из XML-карты сайта WordPress.

add_filter('wp_robots', function ($robots) {
    if (is_page('private')) {
        $robots['noindex'] = true;
        $robots['nofollow'] = true;
    }
    return $robots;
});

add_filter('wp_sitemaps_posts_query_args', function ($args, $post_type) {
    if ($post_type === 'page') {
        $args['post__not_in'] = array(123); // ID приватной страницы
    }
    return $args;
}, 10, 2);

Здесь важный момент: wp_robots — штатный фильтр WordPress, а не выдуманный хук. Он позволяет менять robots-правила без ручной печати тега в wp_head.

Как проверить, что решение сработало

После внедрения не ограничивайтесь визуальной проверкой. Нужны конкретные признаки.

  • В исходном коде страницы появился noindex.
  • В ответе сервера для приватных URL нет случайного 200 OK, если доступ должен быть закрыт.
  • URL исчез из XML-карты сайта или больше не генерируется для индексации.
  • Канонический адрес указывает на правильную версию страницы.
  • В Search Console или Вебмастере статус URL меняется после переобхода.

Если URL всё ещё в выдаче, это не всегда ошибка настройки. Поисковику нужно время на переобход и переоценку страницы. Но если спустя несколько обходов URL остаётся доступным и индексируемым, значит один из сигналов всё ещё противоречит вашей задаче.

Частые ошибки и как их исправить

1. Запретили URL в robots.txt и ждёте удаления из индекса

Это самая распространённая ошибка. Если страница уже известна поисковику, запрет на сканирование может даже затруднить её переобход и удаление. Для удаления нужен noindex или закрытие доступа.

2. Поставили noindex, но оставили страницу в sitemap

Так поисковик получает противоречивые сигналы. Если URL не должен индексироваться, уберите его из карты сайта.

3. Закрыли только одну версию URL

Например, запретили страницу без слеша, а со слешем она доступна. Или закрыли основную запись, но оставили архив тега, где она дублируется. Проверяйте все варианты адреса.

4. Использовали кэш и не очистили его

После изменения robots-мета и канонических ссылок старый HTML может ещё отдаваться из кэша. Очистите кэш страницы, кэш объекта и, если нужно, CDN.

5. Скрыли контент только CSS-ом

Если блок просто спрятан стилями, поисковик всё равно может его увидеть в HTML. Для приватности это не решение.

Безопасность и производительность: что не стоит игнорировать

Если вы закрываете разделы сайта, не полагайтесь только на SEO-метки. Приватный контент должен быть недоступен на уровне доступа, а не только «нежелателен для индексации».

С точки зрения производительности полезно убрать из индекса и из карты сайта тонкие страницы, которые создают шум: пустые архивы, служебные страницы, дубли с параметрами. Это уменьшает количество бесполезных обходов и упрощает структуру сайта для поисковика.

Если на сайте много дублей и служебных URL, имеет смысл проверить настройки чистки и SEO-оптимизации в плагинах вроде Clearfy Pro: там удобно отключать лишние архивы, служебные страницы и дубли без ручного вмешательства в шаблоны. Но даже в этом случае проверьте итоговый HTML и карту сайта вручную — автоматические настройки не отменяют диагностику.

Когда robots.txt всё же нужен

robots.txt не бесполезен. Он нужен, чтобы не тратить краулинговый бюджет на служебные разделы, которые не должны сканироваться: внутренние поисковые результаты, технические каталоги, временные папки, если они вообще доступны извне. Но использовать его как единственный способ убрать страницу из индекса — плохая практика.

Рабочая схема обычно такая: robots.txt ограничивает лишнее сканирование, noindex закрывает от индексации, а серверный доступ защищает действительно приватные данные. Если эти уровни не противоречат друг другу, WordPress-сайт ведёт себя предсказуемо и без сюрпризов в выдаче.

Как создать оценку публикации в WordPress с помощью WPRemark
27.03.2026
Отзывы с выбором оценки в WordPress: пошаговое руководство
13.12.2025
Как сделать защиту от многократных голосов в опросах WordPress
20.04.2026
Как создать опрос с автоматическим экспортом результатов в CSV в WordPress
10.04.2026
Как запретить удаление голосов в опросах WordPress
23.04.2026