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

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

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

Какие страницы WordPress обычно стоит закрыть

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

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

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

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

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

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

Что проверить вручную

• поиск в Google по site:example.com с запросами вроде site:example.com inurl:?s=;
• страницы автора, архивы дат, теги и вложения в индексе;
• наличие дублей с параметрами в адресе;
• файл /robots.txt в текущем виде;
• нет ли в CMS или SEO-плагине автоматической генерации собственных правил.

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

Быстрая проверка через браузер и curl

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

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

Какой способ настройки выбрать: файл, плагин или код

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

Способ	Когда подходит	Плюс	Минус
Файл в корне сайта	Простой сайт, есть доступ к FTP/SSH	Прозрачно и предсказуемо	Нужно следить, чтобы его не переопределял плагин
SEO-плагин	Уже используется Yoast, Rank Math или аналог	Удобно править без доступа к серверу	Легко забыть, что файл генерируется не с диска
Код в теме или плагине	Нужна автоматизация или нестандартная логика	Можно собирать правила программно	Нужна аккуратность и тестирование

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

Шаг 1. Создайте базовый безопасный файл

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

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

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

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

Шаг 2. Не блокируйте CSS и JS без причины

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

Особенно осторожно нужно относиться к правилам вида Disallow: /wp-content/ или Disallow: /wp-includes/. Это слишком грубо для современного сайта и часто приносит больше вреда, чем пользы.

Шаг 3. Если нужно закрыть параметры, делайте это точечно

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

User-agent: *
Disallow: /*?sort=
Disallow: /*?filter=
Disallow: /*?replytocom=

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

Как добавить правила через код, если файл генерируется автоматически

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

<?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',
        'Disallow: /?s=',
        'Sitemap: ' . home_url( '/sitemap_index.xml' ),
    );

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

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

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

После правки важно не просто открыть файл в браузере, а проверить поведение бота и индексацию в целом.

• откройте /robots.txt в браузере и убедитесь, что видите нужный текст;
• проверьте ответ через curl и сравните с тем, что отображается в браузере;
• в Search Console посмотрите, нет ли ошибок сканирования по закрытым URL;
• проверьте, не исчезли ли из обхода важные CSS/JS-файлы;
• поиском site: убедитесь, что служебные страницы постепенно уходят из выдачи, если они были проиндексированы ранее.

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

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

Закрыли важные ресурсы темы

Симптом: страницы открываются, но в отчётах поисковика появляются проблемы с рендерингом. Причина обычно в слишком широком запрете на каталоги с CSS и JS. Решение — убрать грубые правила и оставить только точечные запреты.

Редактировали не тот robots.txt

Симптом: файл на сервере изменён, но в браузере и при запросе бот видит старую версию. Причина — виртуальная генерация через плагин или кэш. Решение — проверить настройки SEO-плагина и очистить кэш, если он есть.

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

Симптом: страница по-прежнему находится в поиске. Причина — robots.txt не удаляет уже известные URL. Решение — использовать noindex, удалить внутренние ссылки на страницу и дождаться переобхода.

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

Симптом: после правки резко упал обход сайта. Причина — запрет на широкие маски вроде Disallow: / или блокировка целых директорий без анализа. Решение — откатить изменения и собрать правила заново, начиная с минимального набора.

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

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

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

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

Мини-чек-лист перед публикацией

• проверен текущий источник robots.txt;
• не закрыты CSS и JS без необходимости;
• сохранён доступ к /wp-admin/admin-ajax.php, если он нужен сайту;
• карта сайта указана корректно;
• служебные URL не дублируют полезные страницы;
• после правки файл проверен через браузер и curl;
• в Search Console нет новых ошибок сканирования.

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