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

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

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

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

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

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

Что обычно имеет смысл ограничить

• служебные разделы админки и системные пути;
• внутренний поиск по сайту;
• страницы с параметрами, если они создают мусорные дубли;
• технические каталоги плагинов и тем, если они доступны извне;
• медиа-страницы вложений, если они не нужны в поиске.

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

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

Минимальный чек перед изменениями:

• посмотреть текущий robots.txt по адресу /robots.txt;
• проверить, нет ли там правил от плагина SEO или кэша;
• сравнить, какие URL реально индексируются в поиске;
• открыть проблемные страницы и посмотреть их мета-теги и canonical;
• убедиться, что нужные разделы не закрываются случайно через Disallow.

Если у вас уже есть статьи с noindex и canonical для дублей, robots.txt не должен дублировать эту работу без причины. Иначе вы усложните диагностику: страница перестанет сканироваться, но останется в индексе, и будет непонятно, почему поисковик не видит обновления.

Какой robots.txt подходит для WordPress на практике

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

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

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

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

• Disallow: /wp-content/ — сломает доступ к изображениям и файлам;
• Disallow: /wp-includes/ — может задеть ресурсы, которые нужны фронтенду;
• массовые запреты по параметрам без понимания, как они используются;
• закрытие рубрик и меток только ради «чистоты», если они дают трафик.

Пошаговое решение: как настроить robots.txt в WordPress

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

Способ	Плюсы	Минусы
Плагин	Удобно редактировать из админки, меньше риска ошибиться с доступом к файлам	Плагин может перезаписать файл или добавить свои правила
Ручной файл	Прозрачно, предсказуемо, не зависит от настроек плагина	Нужен доступ к FTP/хостингу и аккуратность при редактировании
Комбинированный подход	Подходит для сложных сайтов с SEO-плагином и нестандартными правилами	Нужно следить, кто именно генерирует итоговый robots.txt

Шаг 1. Определите источник robots.txt

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

Шаг 2. Добавьте только нужные директивы

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

<?php
// Пример: если нужен собственный robots.txt через WordPress-фильтр.
add_filter( 'robots_txt', function( $output, $public ) {
    $lines = array(
        'User-agent: *',
        'Disallow: /wp-admin/',
        'Allow: /wp-admin/admin-ajax.php',
        'Disallow: /wp-login.php',
        'Disallow: /search/',
        'Disallow: /?s=',
    );

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

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

Шаг 3. Сохраните и проверьте доступность файла

После изменения откройте /robots.txt в браузере. Файл должен отдаваться без редиректов на HTML-страницу, без 404 и без лишней авторизации. Если вместо текста вы видите страницу темы или ошибку, значит сервер или плагин не отдает robots.txt корректно.

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

Проверять нужно не только сам файл, но и поведение робота. Иначе можно получить красивый robots.txt, который фактически ничего не решает.

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

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

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

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

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

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

Не удалит. Если URL уже в индексе, запрет на сканирование не равен удалению. Для удаления нужен noindex, корректный canonical или ответ сервера, в зависимости от задачи.

Плагин SEO перезаписывает файл

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

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

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

Безопасность и производительность: что важно не упустить

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

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

Если нужен более системный подход к технической чистке WordPress, удобно сначала убрать дубли, служебные страницы и лишние элементы через один инструмент, а потом уже точечно допиливать robots.txt. В таких задачах часто помогает Clearfy Pro: https://wpshop.ru/plugins/clearfy.

Короткий чек-лист перед публикацией изменений

• robots.txt открывается по /robots.txt без ошибок;
• не закрыты /wp-admin/admin-ajax.php и публичные страницы;
• нет широких запретов на /wp-content/ и /wp-includes/;
• служебные URL закрыты точечно, а не «на глаз»;
• страницы, которые нужно удалить из индекса, закрываются не только через robots.txt;
• после изменения проверены Search Console и фактический обход важных URL.

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