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

Автор: Руслан Федоров | Опубликовано: 10.09.2026

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

Но robots.txt — не кнопка «скрыть от Google». Он управляет обходом, а не гарантией удаления из индекса. Поэтому настраивать его нужно аккуратно: закрывать только то, что действительно не должно тратить краулинговый бюджет, и не блокировать важные CSS, JS или публичные страницы по ошибке.

Что именно стоит закрывать в WordPress

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

Типичные кандидаты на запрет

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

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

Диагностика: как понять, что проблема именно в robots.txt

Перед правкой проверьте, какие URL реально индексируются и какие из них технические. Не стоит закрывать всё подряд только потому, что «так советуют в интернете».

На что смотреть в первую очередь

отчёт «Страницы» в Google Search Console;
URL с параметрами вроде ?s=, ?orderby=, ?filter=;
архивы тегов и авторов, которые дублируют основной контент;
служебные страницы /feed/, если они не нужны для вашей модели индексации;
ошибки обхода, связанные с блокировкой ресурсов темы или плагинов.

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

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

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

Вариант 1. Редактирование файла robots.txt

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

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

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

Этот пример не универсален. Например, если у вас поиск на сайте нужен для индексации или отдельные ленты используются как канал распространения, строку Disallow: /feed/ лучше не добавлять без проверки.

Вариант 2. Генерация robots.txt через фильтр

Если сайт живёт в Git или вы не хотите править файл руками, можно отдать robots.txt через WordPress-фильтр. Это удобно, когда правила должны быть частью темы или mu-plugin.

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

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

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

Вариант 3. Через SEO-плагин

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

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

Что не стоит блокировать

Самая дорогая ошибка — закрыть ресурсы, которые нужны для рендеринга страницы. Если поисковик не может загрузить CSS или JS, он может хуже понимать мобильную версию, интерактивные элементы и поведение шаблона.

не блокируйте папки с темой и плагинами, если они отдаются публично и нужны для отрисовки;
не закрывайте /wp-content/uploads/ целиком, если изображения должны индексироваться;
не запрещайте доступ к важным страницам только потому, что они «не для людей» — если они участвуют в логике сайта, проверьте, нужен ли им noindex вместо запрета обхода;
не добавляйте десятки строк с параметрами, если проблему можно решить каноникалом или нормализацией URL.

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

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

Минимальный чек-лист

откройте /robots.txt в браузере и проверьте, что файл отдаётся без редиректов и ошибок;
проверьте, что sitemap указан корректно и ведёт на существующий файл;
в Google Search Console используйте проверку URL для нескольких типовых страниц;
убедитесь, что закрытые URL не блокируют важные ресурсы темы;
посмотрите логи сервера или отчёты краулера, если у вас есть доступ к ним;
сравните количество мусорных URL в индексе через несколько переобходов, а не в тот же день.

Если вы используете командную строку, быстро проверить ответ сервера можно так:

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

Первая команда покажет статус и заголовки, вторая — содержимое файла. Если вместо ожидаемого текста приходит HTML-страница темы, значит robots.txt генерируется не там, где вы думаете, или его перехватывает другой слой.

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

Закрыли всё через `Disallow: /`

Это самый грубый сценарий. Сайт становится закрытым для обхода целиком, и если правило попало в production по ошибке, поисковик быстро перестаёт нормально переобходить страницы. Исправление простое: убрать правило, затем проверить доступность ключевых URL и запросить переобход в Search Console.

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

Если страница уже в индексе, запрет обхода не всегда решает задачу быстро. Для удаления используйте noindex, редирект на релевантную страницу или канонический URL, если дубль должен быть объединён с основной страницей.

Заблокировали CSS и JS

Это часто случается, когда пытаются «почистить» сайт слишком агрессивно. В результате поисковик видит страницу без части стилей и скриптов. Исправление: уберите блокировки ресурсов темы и проверьте рендеринг в инструменте проверки URL.

Правили не тот robots.txt

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

Когда лучше использовать не robots.txt, а другие инструменты

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

ставить noindex, follow на шаблон или конкретный тип страниц;
настраивать canonical на основную версию;
делать 301-редирект, если дубль не нужен вообще;
сокращать генерацию лишних URL на уровне темы или плагина.

Если вам нужен комплексный контроль дублей, индексации и технической чистки, иногда проще собрать это в одном инструменте, чем вручную поддерживать набор разрозненных настроек. Например, для части задач по SEO и чистке сайта может подойти Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае логику индексации лучше понимать руками, а не полагаться на кнопку «исправить всё».

Практический ориентир для безопасной настройки

Хороший robots.txt в WordPress не пытается спрятать сайт целиком. Он убирает из обхода только то, что создаёт шум: вход в админку, служебные страницы, бесполезные поисковые URL и дубли, которые уже решены на уровне canonical или noindex. Если после правки вы видите меньше мусорных URL в отчётах, а важные страницы продолжают нормально обходиться и индексироваться, значит настройка сделана правильно.