Как настроить robots.txt в WordPress для запрета индексации отдельных разделов

Автор: Полина Лебедева | Опубликовано: 18.08.2026

Если в индексе появились служебные страницы, архивы с дублями или лишние технические URL, первым делом обычно проверяют robots.txt. Но здесь есть важная оговорка: этот файл не удаляет страницы из поиска сам по себе, а только подсказывает роботам, куда не ходить. Поэтому задача решается не «одной строкой», а связкой из правильных директив, настроек WordPress и проверки в Search Console.

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

Когда robots.txt действительно нужен

На практике файл полезен, если нужно убрать из обхода:

/wp-admin/ и служебные файлы админки;
страницы поиска по сайту с параметром ?s=;
служебные URL плагинов, если они создают мусорный обход;
архивы, которые не должны индексироваться, но продолжают расходовать crawl budget;
временные разделы, которые ещё не готовы к публикации.

При этом не стоит пытаться через robots.txt закрыть всё подряд. Если страница уже в индексе, запрет на обход не гарантирует её исчезновение. Для удаления из поиска обычно нужен noindex или корректный ответ сервера, а не только Disallow.

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

Перед правкой файла полезно понять, что вы исправляете. Иначе легко закрыть не тот раздел и получить обратный эффект.

Проверьте текущий robots.txt

Откройте https://ваш-домен/robots.txt и посмотрите, не добавляет ли его тема, SEO-плагин или хостинг. В WordPress файл часто виртуальный, то есть физически его может не быть в корне сайта, но сервер всё равно отдаёт содержимое.

Если там уже есть правила, обратите внимание на такие ошибки:

запрещён весь сайт через Disallow: /;
закрыт каталог с медиафайлами, хотя изображения должны индексироваться;
дублируются директивы от разных плагинов;
в Sitemap указан неверный адрес.

Сверьте, что реально нужно закрыть

Частая ошибка — закрывать архивы категорий, теги и поиск без анализа. Если у вас на этих страницах есть полезный контент и они дают трафик, запрет только навредит. Если же архивы пустые, дублируют записи или создают тысячи тонких страниц, их действительно имеет смысл убрать из обхода и дополнительно пометить как noindex через SEO-плагин или код.

Подход	Когда использовать	Минус
robots.txt	Нужно сократить обход служебных URL	Не удаляет уже проиндексированные страницы
noindex	Страница должна быть доступна, но не в поиске	Нужно, чтобы робот мог зайти и увидеть мета-тег
404/410	Страница больше не нужна совсем	Нужно аккуратно проверить внутренние ссылки

Пошаговая настройка robots.txt в WordPress

Если задача типовая, можно обойтись без плагинов и прописать файл вручную в корне сайта. Это самый прозрачный вариант: вы точно знаете, что отдаёт сервер.

Шаг 1. Создайте или отредактируйте файл

В корне сайта должен лежать robots.txt. Минимальный безопасный шаблон для WordPress выглядит так:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/sitemap_index.xml

Здесь закрывается админка, но разрешается admin-ajax.php, потому что его используют фронтенд-скрипты и некоторые плагины. Без этого можно случайно сломать формы, фильтры или динамические элементы.

Шаг 2. Добавьте точечные запреты

Если нужно убрать поиск по сайту и технические параметры, добавляйте только конкретные правила. Например:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /*?replytocom=
Disallow: /tag/

Sitemap: https://example.com/sitemap_index.xml

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

Шаг 3. Если нужен не robots.txt, а noindex

Для страниц поиска, архивов автора или пустых таксономий часто правильнее не Disallow, а noindex. В WordPress это обычно делают через SEO-плагин или фильтры темы. Пример для архивов тегов:

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

Это не заменяет SEO-плагин, но показывает принцип: если страница должна открываться пользователю, но не попадать в индекс, noindex надёжнее, чем запрет обхода.

Как не сломать важные страницы

Самая частая проблема — слишком широкий запрет. Например, кто-то закрывает /category/, а потом обнаруживает, что из поиска исчезли рабочие страницы рубрик. Или закрывает весь /wp-content/, после чего поисковики перестают видеть изображения.

Проверьте три вещи:

не закрыт ли путь, который нужен для CSS, JS или медиа;
не попали ли в запрет страницы, которые должны индексироваться;
совпадает ли sitemap с реальной структурой сайта.

Если вы используете SEO-плагин, не дублируйте его правила вручную без необходимости. Два источника правды в robots.txt часто приводят к конфликтам: один плагин добавляет sitemap, другой перезаписывает файл, и в итоге робот получает неполный или некорректный набор директив.

Проверка результата после внедрения

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

Что проверить вручную

Откройте /robots.txt и убедитесь, что файл отдается без редиректов и ошибок.
Проверьте, что sitemap доступен по указанному адресу.
Откройте несколько URL, которые должны быть закрыты, и убедитесь, что они не исчезли из сайта для обычных пользователей.
Если используете noindex, проверьте исходный код страницы и наличие мета-тега.

Что проверить в Search Console

В Google Search Console используйте проверку URL и отчёт по индексированию. Если страница закрыта через robots.txt, робот может показать, что она недоступна для сканирования. Это нормально для служебных URL, но не для важных страниц. Если страница должна быть удалена из индекса, а не просто скрыта от обхода, меняйте стратегию.

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

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

Закрыли весь сайт

Ошибка выглядит так: Disallow: /. Это блокирует обход почти всего сайта. Исправление простое — удалить правило и оставить только точечные запреты. После этого заново отправить sitemap и дождаться повторного обхода.

Запретили CSS и JS

Если в robots.txt закрыт /wp-content/ целиком, поисковик может хуже рендерить страницу. Правильнее закрывать только конкретные служебные каталоги, а не весь путь.

Пытаются убрать страницу из индекса только через Disallow

Если URL уже в поиске, одного запрета мало. Нужен noindex, удаление страницы или корректный редирект. Иначе страница может оставаться в индексе как «запрещённая к сканированию».

Дублируют правила плагином и вручную

Если SEO-плагин уже управляет robots.txt, не редактируйте его содержимое в двух местах. Выберите один источник: либо файл в корне, либо настройки плагина. Иначе при обновлении можно потерять часть директив.

Практические советы по безопасности и производительности

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

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

канонические URL;
архивы тегов и авторов;
страницы поиска;
параметры фильтров;
наличие sitemap только с нужными URL.

Если нужен более широкий аудит дублей и технических настроек, удобнее сначала собрать список проблем, а потом уже менять robots.txt. В таких задачах часто помогает Clearfy Pro: он закрывает типовые SEO- и технические дубли без ручного редактирования десятков файлов, но использовать его стоит только если вам действительно нужен плагин, а не разовая правка.

Короткий чек-лист перед публикацией

Файл robots.txt открывается по прямому URL.
Не закрыт /wp-admin/admin-ajax.php.
Sitemap указан корректно.
Не заблокированы CSS, JS и изображения без необходимости.
Страницы, которые должны исчезнуть из поиска, помечены не только через Disallow, но и через noindex или удаление.
Проверка в Search Console показывает ожидаемое поведение.

Если после правки сайт стал хуже индексироваться, не ищите проблему только в robots.txt. Чаще всего причина в сочетании нескольких факторов: неверный sitemap, конфликт SEO-плагинов, случайный noindex в шаблоне или закрытый ресурс, без которого страница не рендерится нормально.