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

Автор: Дарья Журавлева | Опубликовано: 15.08.2026

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

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

Что обычно нужно закрыть в robots.txt

Смысл robots.txt не в том, чтобы «спрятать сайт», а в том, чтобы сократить обход технических URL. Для WordPress это чаще всего:

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

При этом не стоит закрывать /wp-content/uploads/ только потому, что там лежат изображения. Если картинки нужны в поиске, закрытие может ухудшить видимость медиа.

Диагностика: почему robots.txt не дает ожидаемого эффекта

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

Проверьте, какой robots.txt сейчас отдается

Откройте https://ваш-домен/robots.txt и посмотрите:

есть ли там ваши правила;
не дублирует ли их SEO-плагин;
не добавлены ли лишние директивы, которые закрывают важные разделы;
нет ли синтаксических ошибок, например пустых Disallow: с неверным путем.

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

Проверьте, не закрыт ли контент через noindex вместо robots.txt

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

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

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

Вариант 1. Настроить через SEO-плагин

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

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

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

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

Вариант 2. Создать физический robots.txt в корне

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

Минимальный рабочий пример:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Sitemap: https://example.com/sitemap_index.xml

Строку Sitemap стоит указывать только если у вас уже есть рабочая карта сайта. Иначе вы просто добавите несуществующий адрес.

Вариант 3. Отдать robots.txt через WordPress-фильтр

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

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

Этот вариант полезен, если вы хотите хранить правила в коде проекта и не зависеть от ручных правок на сервере. Но если у вас уже есть SEO-плагин, сначала проверьте, не перезаписывает ли он вывод.

Что лучше: плагин, файл или код

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

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

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

Откройте /robots.txt и убедитесь, что видите нужные директивы.
Проверьте, что /wp-admin/ и /wp-login.php закрыты для обхода, а /wp-admin/admin-ajax.php разрешен.
Если у вас есть sitemap, убедитесь, что ссылка на него корректна и отдается без редиректов.
Посмотрите логи сервера или отчеты краулера, если нужно понять, перестал ли бот ходить в служебные разделы.

Для быстрой проверки можно использовать curl:

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

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

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

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

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

Дублируются правила из плагина и файла

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

Закрыли страницу логина, но забыли про AJAX

Если закрыть /wp-admin/ без исключения /wp-admin/admin-ajax.php, часть фронтенд-функций может начать вести себя странно. Это особенно заметно на сайтах с формами, фильтрами и динамическими блоками.

Пытаются скрыть конфиденциальные данные через robots.txt

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

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

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

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

Если вам нужно регулярно чистить сайт от дублей, мусорных архивов и технических страниц, удобно сочетать ручную настройку robots.txt с инструментами для технической оптимизации. Например, в Clearfy Pro есть набор функций для чистки WordPress и удаления лишних дублей, но использовать его стоит только там, где вы понимаете, что именно отключаете: https://wpshop.ru/plugins/clearfy?utm_source=wpmeta.ru&utm_medium=article&utm_campaign=kak-nastroit-robots-txt-v-wordpress-dlya-zakrytiya-ot-indecksa-tehnicheskih-stranic

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