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

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

Для WordPress типичный набор — /wp-admin/, внутренние поисковые страницы, технические параметры, иногда архивы автора или дат. Но список зависит от структуры сайта. Если закрыть лишнее, можно случайно спрятать CSS/JS, изображения или полезные разделы от поисковых роботов.

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

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

Что обычно закрывают в WordPress

• /wp-admin/ — административная часть, кроме /wp-admin/admin-ajax.php;
• внутренний поиск вида /?s= или отдельные страницы поиска темы;
• технические каталоги плагинов и кэша, если они доступны по URL;
• служебные параметры, которые создают мусорные дубли;
• архивы, которые не несут ценности и дублируют контент.

Но не надо закрывать всё подряд. Например, если тема или плагин грузит стили из /wp-content/, а вы запретите этот путь целиком, поисковик может хуже рендерить страницу и неверно оценивать её качество.

Диагностика: что именно мешает индексации

Перед правкой robots.txt проверьте, какие URL реально создают шум. Откройте отчёты в Google Search Console, посмотрите страницы с пометками «Просканировано, но не проиндексировано», «Дубликат, Google выбрал другой канонический URL» и «Заблокировано robots.txt». Если в списке много служебных адресов, значит закрытие обхода действительно имеет смысл.

Полезно также проверить текущий robots.txt в браузере: https://ваш-домен.ru/robots.txt. На живых сайтах нередко встречаются конфликты между правилами плагина SEO, кэширующего плагина и ручной правкой в functions.php. В итоге файл выглядит корректно, но фактически отдаётся не тот вариант, который вы ожидали.

Мини-чек-лист перед изменениями

• есть ли у сайта уже опубликованный robots.txt;
• не закрыт ли случайно /wp-content/uploads/ или CSS/JS;
• есть ли в индексе служебные URL, которые нужно не просто закрыть, а удалить;
• не конфликтует ли robots.txt с noindex и canonical;
• не создаёт ли тема отдельные страницы поиска, тегов или архивов без ценности.

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

Самый безопасный путь — начать с минимального набора правил и расширять его только по факту. Для большинства сайтов достаточно закрыть админку и внутренний поиск, а остальное уже проверять по логам обхода и отчётам Search Console.

Вариант 1. Ручной robots.txt в корне сайта

Если у вас есть доступ к файлам сайта, создайте или отредактируйте robots.txt в корне. Пример базовой конфигурации:

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

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

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

Вариант 2. Через код темы или плагина

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

<?php
add_filter('robots_txt', function ($output, $public) {
    $lines = [];
    $lines[] = 'User-agent: *';
    $lines[] = 'Disallow: /wp-admin/';
    $lines[] = 'Allow: /wp-admin/admin-ajax.php';
    $lines[] = 'Disallow: /?s=';
    $lines[] = 'Sitemap: ' . home_url('/sitemap_index.xml');

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

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

Вариант 3. Через SEO-плагин

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

Подход	Плюсы	Минусы
Файл в корне	Прозрачно, просто проверить	Нужен доступ к файловой системе
Фильтр robots_txt	Удобно в коде, можно версионировать	Зависит от темы/плагина
SEO-плагин	Удобно для редакторов	Легко получить конфликт настроек

Что нельзя закрывать без проверки

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

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

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

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

Дополнительно можно проверить ответ сервера через curl:

curl -I https://example.com/robots.txt
curl https://example.com/robots.txt

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

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

Закрыли страницы, которые должны ранжироваться

Такое случается, когда в robots.txt по шаблону добавляют слишком общий Disallow. Исправление простое: убрать лишнее правило и проверить, не дублируется ли ограничение в мета-теге noindex или в HTTP-заголовке.

Ожидали удаления из индекса только через robots.txt

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

Сломали рендеринг из-за запрета CSS и JS

Проверьте, не закрыт ли путь, из которого тема или плагины грузят ресурсы. Если в Search Console появились проблемы с рендерингом, откройте исходный код страницы и посмотрите, какие файлы подключаются из /wp-content/. Закрывать нужно точечно, а не целую директорию.

Получили конфликт между плагином и ручным файлом

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

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

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

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

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

Что должно быть в финальной проверке

• robots.txt открывается по прямому URL и содержит актуальные правила;
• публичные страницы не закрыты случайно;
• админка и служебные разделы не обходятся без необходимости;
• в Search Console нет новых массовых ошибок обхода;
• не сломаны CSS, JS и изображения;
• для уже проиндексированных URL выбран отдельный способ удаления, а не только Disallow.

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