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

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

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

Какие проблемы обычно решает robots.txt в WordPress

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

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

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

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

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

Быстрый чек-лист перед изменением robots.txt

• Есть ли у сайта XML-карта сайта и не закрыта ли она случайно.
• Используются ли архивы рубрик и тегов как полноценные посадочные страницы.
• Есть ли фильтры, сортировки и параметры, которые создают дубли.
• Нужны ли поисковикам изображения из /wp-content/uploads/.
• Не закрыт ли случайно CSS/JS, без которых поисковик хуже рендерит страницу.

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

Какой robots.txt подходит для большинства WordPress-сайтов

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

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /search/
Disallow: /trackback/
Disallow: /cgi-bin/

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

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

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

Не стоит бездумно запрещать доступ к /wp-content/uploads/, CSS, JS и всем архивам. Поисковик должен видеть ресурсы, которые участвуют в рендеринге страницы. Если закрыть слишком много, можно получить проблемы с индексацией и некорректным отображением в поиске.

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

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

1. Найдите, где файл уже управляется

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

2. Создайте или отредактируйте физический файл

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

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

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

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

3. Добавьте правила только для реально лишних URL

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

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

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

add_filter('robots_txt', function ($output, $public) {
    $output .= "\nUser-agent: *\n";
    $output .= "Disallow: /search/\n";
    $output .= "Disallow: /wp-login.php\n";
    $output .= "Allow: /wp-admin/admin-ajax.php\n";
    $output .= "Sitemap: " . home_url('/sitemap_index.xml') . "\n";

    return $output;
}, 10, 2);

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

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

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

1. robots.txt реально отдаётся по адресу /robots.txt и содержит нужные строки.
2. Сайт не потерял доступ к CSS/JS и основным страницам.
3. В Search Console не выросло число ошибок сканирования из-за случайно закрытых URL.

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

Что смотреть в Search Console

• Отчёт по страницам, которые исключены из-за robots.txt.
• Ошибки сканирования после обновления файла.
• Появились ли новые URL с параметрами, которые робот всё ещё обходит.

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

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

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

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

Путают Disallow и noindex

Disallow запрещает обход, но не гарантирует удаление из индекса. Если страница уже известна поисковику, одного robots.txt мало. Для таких URL нужен noindex или другая стратегия удаления.

Используют несколько источников robots.txt

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

Забывают про карту сайта

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

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

Robots.txt не защищает админку и не делает сайт безопаснее сам по себе. Для /wp-admin/ и /wp-login.php нужны нормальные меры: сложные пароли, ограничение попыток входа, обновления ядра и плагинов, при необходимости — двухфакторная аутентификация.

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

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

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