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

Автор: Маргарита Игнатьева | Опубликовано: 15.08.2026

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

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

Что обычно ломают в robots.txt

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

Обычно проблемы выглядят так:

в индекс попадают страницы внутреннего поиска вида ?s=;
дублируются архивы автора и даты;
в выдаче всплывают вложения изображений;
закрывают /wp-admin/ и потом удивляются, что сломались сервисные запросы;
запрещают /wp-content/uploads/ целиком, а потом поисковик перестаёт нормально видеть картинки;
путают Disallow в robots.txt и noindex в мета-тегах — это разные механизмы.

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

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

Проверьте эти типы страниц

внутренний поиск: / ?s=;
архивы автора: /author/;
архивы дат: /2024/01/ и похожие;
вложения: /attachment/ или страницы медиафайлов;
технические URL плагинов: страницы фильтров, тегов, параметров сортировки;
служебные страницы входа и админки — их не индексируют, но и закрывать нужно аккуратно.

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

Как собрать robots.txt без лишних запретов

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

Для типичного WordPress-сайта разумный стартовый вариант выглядит так:

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

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

Здесь есть несколько важных оговорок:

/wp-admin/ закрываем, но admin-ajax.php оставляем доступным, иначе можно сломать фронтенд-скрипты и некоторые формы;
/search/ и параметр ?s= закрывают внутренний поиск, который почти всегда создаёт мусор;
/author/, /date/, /tag/ стоит закрывать только если эти архивы не несут самостоятельной ценности;
/attachment/ полезно закрыть, если страницы вложений не используются как посадочные;
строка Sitemap помогает поисковику быстрее найти карту сайта.

Когда не стоит закрывать теги и архивы

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

То же касается архивов автора на медиа-проектах, где у каждого автора есть полноценная страница с подборкой материалов. Закрывать их по привычке не стоит.

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

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

<?php
add_filter( 'robots_txt', function( $output, $public ) {
    $rules = array(
        'User-agent: *',
        'Disallow: /wp-admin/',
        'Allow: /wp-admin/admin-ajax.php',
        'Disallow: /wp-login.php',
        'Disallow: /search/',
        'Disallow: /*?s=',
        'Disallow: /author/',
        'Disallow: /date/',
        'Disallow: /attachment/',
        'Sitemap: ' . home_url( '/sitemap_index.xml' ),
    );

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

Такой подход удобен, если:

robots.txt должен собираться из кода темы или мини-плагина;
нужно менять правила в зависимости от среды, например на staging;
вы хотите хранить конфигурацию в репозитории.

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

Сравнение подходов

Подход	Когда подходит	Минус
Физический robots.txt в корне	Нужен простой и прозрачный контроль	Легко забыть обновить после изменений сайта
Фильтр `robots_txt`	Нужна генерация из кода или условий среды	Сложнее отлаживать при конфликте с плагинами
SEO-плагин	Нужны UI-настройки и карта сайта в одном месте	Можно случайно закрыть лишнее через шаблонные настройки

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

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

Откройте /robots.txt в браузере и убедитесь, что отдаётся именно нужная версия.
Проверьте, что в файле есть строка с картой сайта.
Убедитесь, что /wp-admin/admin-ajax.php не закрыт.
Проверьте несколько URL вручную: поиск, автор, дата, вложение.
В Search Console используйте проверку URL и посмотрите, не блокируется ли важная страница.

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

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

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

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

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

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

Использовали robots.txt для приватного контента

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

Забыли про виртуальный robots.txt

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

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

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

С точки зрения производительности не закрывайте лишние ресурсы, если они нужны для корректной индексации. Поисковик должен видеть CSS и JS, иначе он может неверно оценить страницу. А вот служебные URL, которые создают шум, лучше закрыть сразу.

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

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