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

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

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

Когда robots.txt нужен, а когда он не поможет

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

Файл полезен, когда нужно:

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

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

Диагностика: что именно закрывать

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

• служебные адреса ядра: /wp-admin/, /wp-includes/;
• страницы внутреннего поиска: /?s= и поисковые URL темы;
• архивы автора, даты, тегов, если они не нужны в поиске;
• медиа-страницы вложений, если они индексируются отдельно;
• технические папки плагинов, которые не должны обходиться;
• URL с параметрами сортировки, фильтрации и служебными GET-параметрами.

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

Что оставить открытым

Не стоит закрывать:

• CSS и JS, если они нужны для рендеринга страниц;
• изображения, если они участвуют в поиске по картинкам;
• основные записи и страницы сайта;
• /wp-admin/admin-ajax.php, если тема или плагин используют AJAX на фронтенде.

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

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

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

Вариант 1: правка через SEO-плагин

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

Пример базового набора правил:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /tag/
Disallow: /author/
Disallow: /cgi-bin/
Sitemap: https://example.com/sitemap_index.xml

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

Вариант 2: физический файл в корне

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

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /feed/
Sitemap: https://example.com/sitemap_index.xml

Обратите внимание на /feed/: закрывать RSS имеет смысл не всегда. Если у вас есть подписчики или внешние сервисы, которые используют ленту, запрет может создать побочные эффекты. Сначала проверьте, нужен ли feed вообще.

Если нужно закрыть только часть служебных URL

Иногда достаточно убрать один проблемный раздел, а не переписывать весь файл. Например, если сайт генерирует много мусорных URL внутреннего поиска, можно закрыть только их:

User-agent: *
Disallow: /?s=
Disallow: /search/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xml

Такой подход лучше, чем массово запрещать всё подряд. Чем меньше правил, тем проще поддержка и меньше риск случайно перекрыть важный путь.

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

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

Если нужен robots.txt через код

Иногда файл формируют программно, например, чтобы добавить правила в зависимости от окружения. В WordPress для этого есть фильтр robots_txt. Он позволяет дописать или изменить содержимое виртуального файла.

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);

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

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

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

• Откройте https://ваш-домен/robots.txt и убедитесь, что отдается нужная версия файла.
• Проверьте, не блокируются ли CSS и JS, которые нужны для отрисовки страниц.
• Посмотрите, не закрыт ли admin-ajax.php, если на сайте есть фронтенд-формы, фильтры или динамические блоки.
• Проверьте проблемные URL в инструменте проверки robots.txt в Google Search Console, если сайт уже подключен.
• Сравните список закрытых URL с sitemap: закрытое не должно одновременно быть важной страницей из карты сайта.

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

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

Закрыли в robots.txt то, что нужно удалить из индекса

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

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

Иногда в файл случайно попадает Disallow: /. После этого поисковик перестает обходить почти весь сайт. Если это уже произошло, уберите правило, проверьте доступность страниц и дождитесь повторного обхода.

Забыли про конфликт плагина и физического файла

Если SEO-плагин генерирует виртуальный robots.txt, а вы положили свой файл в корень, итоговое поведение зависит от конфигурации сервера и плагина. Сначала выясните, какой источник отдается наружу, и оставьте один.

Закрыли CSS, JS или изображения

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

Использовали robots.txt вместо настройки индексации

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

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

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

С точки зрения производительности полезно не пытаться закрыть всё подряд. Лучше убрать из обхода только то, что реально создаёт шум: внутренний поиск, технические архивы, ненужные feed-URL, служебные разделы плагинов. Это делает обход сайта чище и проще для поддержки.

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

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

• Проверили, какой robots.txt реально отдается по URL.
• Не закрыли CSS, JS и admin-ajax.php без причины.
• Сверили правила с sitemap.
• Убедились, что закрытые URL не являются важными страницами.
• Проверили файл в Search Console или аналогичном инструменте.
• Не использовали robots.txt как замену noindex или редиректу.

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