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

Автор: Виктор Попов | Опубликовано: 19.08.2026

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

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

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

robots.txt не удаляет страницы из индекса и не защищает контент от просмотра. Его задача — подсказать роботам, куда не ходить. Это полезно для:

служебных URL WordPress, которые не должны тратить краулинговый бюджет;
дублей архивов и параметров, если они уже контролируются canonical или мета-тегами;
админских и системных разделов, которые не нужны в выдаче;
файлов и каталогов, которые не должны обходиться ботами.

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

Диагностика: что именно мешает индексации или создаёт дубли

Перед правкой файла стоит понять, с чем вы работаете. Откройте в браузере /robots.txt и проверьте, что там уже есть. На WordPress файл может формироваться как физический, так и виртуальный — это важно, если вы редактируете его через хостинг, а сайт отдаёт другой вариант.

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

Есть ли в robots.txt директива Sitemap: и корректный ли там адрес карты сайта.
Не закрыт ли случайно /wp-content/uploads/ или весь /wp-content/.
Нет ли слишком широких правил вроде Disallow: / для всех роботов.
Не дублируются ли правила, которые конфликтуют между собой.
Не пытаетесь ли вы через robots.txt закрыть URL с параметрами, которые уже должны решаться canonical.

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

Какие правила обычно безопасны для WordPress

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

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

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

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

Что можно закрыть дополнительно, если это действительно служебные URL

/wp-json/ — только если вы понимаете последствия и у вас нет публичных сценариев REST API;
служебные каталоги плагинов, если они отдают индексируемые HTML-страницы;
архивы авторов, дат и тегов, если они не несут ценности и уже закрыты другими способами.

С REST API лучше быть осторожным: полное закрытие /wp-json/ может мешать интеграциям, мобильным приложениям и некоторым плагинам. Если задача — убрать из индекса только отдельные эндпоинты, robots.txt не лучший инструмент.

Пошаговое решение: как настроить robots.txt без лишнего риска

Ниже — практичный порядок действий, который помогает не сломать сайт и не закрыть важные страницы.

Шаг 1. Сделайте текущую копию файла

Если robots.txt физический, сохраните его содержимое. Если файл виртуальный, скопируйте правила из текущего ответа сервера. Это пригодится, если после правки что-то пойдёт не так.

Шаг 2. Уберите слишком широкие запреты

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

Шаг 3. Оставьте только то, что реально служебное

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

Шаг 4. Добавьте карту сайта

Указывайте только актуальный sitemap. Если у вас несколько карт, лучше ссылаться на индексную карту, которую отдаёт SEO-плагин или WordPress-решение, а не на случайный XML-файл.

Шаг 5. Проверьте, что robots.txt отдается с кодом 200

Файл должен открываться без редиректов и без 404. Если там 403 или 500, поисковик не сможет его прочитать.

Пример более аккуратного robots.txt для типового сайта

Если на сайте есть блог, страницы, медиа и стандартная админка, можно начать с такого варианта:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /trackback/
Disallow: /comments/feed/
Disallow: /feed/

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

Но не копируйте этот блок вслепую. Например, /feed/ закрывают не всегда: если у вас есть подписка на RSS или важные фиды для внешних сервисов, это правило может быть лишним.

Если нужен контроль через код, а не через файл

Иногда robots.txt генерируется плагином или сервером, и править его вручную неудобно. В WordPress можно добавить свои правила через фильтр robots_txt. Это полезно, если вы хотите держать логику в теме или небольшом mu-plugin.

<?php
add_filter( 'robots_txt', function( $output, $public ) {
    $lines = array(
        'User-agent: *',
        'Disallow: /wp-admin/',
        'Allow: /wp-admin/admin-ajax.php',
        'Disallow: /wp-login.php',
        'Sitemap: https://example.com/sitemap_index.xml',
    );

    return implode( "\n", $lines ) . "\n";
}, 10, 2 );

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

Сравнение подходов: файл, плагин, код

Подход	Плюсы	Минусы	Когда выбирать
Физический robots.txt	Просто, прозрачно, легко проверить	Можно случайно перезаписать при деплое	Небольшие сайты и ручное управление
SEO-плагин	Удобно для редактора, меньше ручной работы	Не всегда ясно, кто именно генерирует правила	Если robots.txt меняют не разработчики
Фильтр `robots_txt`	Гибко, можно привязать к окружению	Нужен код и контроль за темой/плагином	Проекты с деплоем и несколькими средами

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

Проверка нужна не только после правки, но и через несколько дней, когда робот снова обойдёт сайт. Смотрите на конкретные признаки:

https://site.ru/robots.txt открывается с кодом 200;
в файле нет случайного Disallow: / или закрытия важных каталогов;
Search Console не показывает ошибки чтения robots.txt;
в отчётах по сканированию уменьшается число обходов служебных URL;
страницы, которые должны индексироваться, остаются доступными для обхода.

Если вы закрывали только служебные разделы, а в индексе всё ещё есть старые URL, это нормально: robots.txt не удаляет уже известные страницы мгновенно. Для удаления из выдачи нужен отдельный процесс — обычно через noindex, 404/410 или инструмент удаления в Search Console.

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

Закрыли слишком много

Самая частая проблема — блокируют /wp-content/, /uploads/ или даже весь сайт. После этого ломаются изображения, стили, скрипты или индексация важных страниц. Исправление простое: вернуть доступ к публичным ресурсам и проверить, не исчезли ли стили на фронтенде.

Путают robots.txt и noindex

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

Забывают про sitemap

Без ссылки на карту сайта поисковику сложнее быстро переобойти новые страницы. Особенно это заметно на сайтах с частыми обновлениями. Добавляйте актуальный sitemap и проверяйте, что он не ведёт на 404.

Правят не тот файл

На части хостингов robots.txt генерируется виртуально, а физический файл в корне игнорируется. Если правка не применяется, проверьте, какой вариант реально отдаёт сервер.

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

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

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

Если нужен более широкий набор инструментов для SEO-чистки WordPress, можно посмотреть в сторону Clearfy Pro, но даже в этом случае правила robots.txt стоит проверять вручную: автоматическая настройка не отменяет проверку на конкретном сайте.

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

robots.txt открывается по HTTPS и отдаёт 200.
Закрыты только служебные разделы, а не публичные ресурсы.
Есть актуальная ссылка на sitemap.
Не блокируется admin-ajax.php, если он нужен теме или плагинам.
Проверено поведение в Search Console после переобхода.
Не перепутаны задачи robots.txt и noindex.

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

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