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

Автор: Игорь Титов | Опубликовано: 11.09.2026

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

Что обычно нужно закрывать в WordPress

Сначала полезно отделить служебные адреса от контентных. В robots.txt обычно ограничивают обход таких разделов:

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

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

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

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

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

Если проблема только в индексации, а не в обходе, сначала проверьте мета-теги, HTTP-заголовки и канонические адреса. Закрывать всё подряд в robots.txt — плохая практика: можно случайно спрятать CSS, JS или API, которые нужны для рендеринга и проверки страниц.

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

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

1. Создайте или откройте robots.txt в корне сайта

Файл должен лежать в корне домена: https://example.com/robots.txt. Если файла нет, WordPress может показать виртуальную версию, но для точной настройки лучше создать свой.

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

Базовый вариант для типового сайта выглядит так:

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

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

Здесь важно не закрыть admin-ajax.php, если тема или плагины используют его на фронтенде. Полное закрытие /wp-admin/ без исключения этого файла иногда ломает формы, фильтры и динамические элементы.

3. Не закрывайте ресурсы, нужные для рендеринга

Если у вас есть строгая цель по SEO, не добавляйте в robots.txt запреты на CSS и JS только потому, что они «технические». Современные поисковые системы используют эти файлы для оценки страницы. Закрывать их имеет смысл только если вы точно понимаете последствия и проверили, что это не мешает рендерингу.

4. Укажите карту сайта

Директива Sitemap помогает поисковикам быстрее находить актуальные URL. Указывайте только реальную карту сайта, которая отдаёт 200 OK и содержит индексируемые страницы.

Пример более точной настройки для служебных разделов

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

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

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

Но строка Disallow: /?s= не заменяет нормальную настройку поиска на сайте. Если у вас уже есть отдельная статья поиска, лучше закрывать её через noindex и логику шаблона, а не только через robots.txt. Иначе поисковик может продолжить видеть URL как известный, но недоступный для обхода.

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

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

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

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

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

Как проверить, что настройка сработала

Проверка должна быть не визуальной, а технической. Смотрите на три вещи:

открывается ли /robots.txt по HTTP 200;
нет ли в файле лишних запретов на важные ресурсы;
не изменился ли статус обхода в Search Console после переобхода.

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

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

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

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

В ответе должен быть 200 OK. Если вместо этого приходит редирект на несуществующий адрес, 404 или HTML-страница темы, значит robots.txt не настроен корректно.

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

Закрывают сайт от индексации через robots.txt

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

Перекрывают важные файлы темы и плагинов

Иногда в robots.txt по ошибке закрывают каталоги с CSS, JS или изображениями. После этого поисковик хуже рендерит страницу, а в инструментах проверки появляются предупреждения. Исправление простое: уберите лишние запреты и проверьте, какие ресурсы реально нужны для фронтенда.

Делают несколько источников robots.txt

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

Ожидают мгновенного эффекта

После изменения robots.txt поисковик не обязан сразу пересканировать сайт. Сначала обновится обход, потом — отчёты. Проверяйте не только сам файл, но и журналы обхода, а также статус важных URL в Search Console.

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

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

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

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

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

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

Если после настройки robots.txt у вас остались сомнения, проверьте реальный список заблокированных URL в Search Console и сравните его с тем, что вы ожидали закрыть. Это самый надёжный способ понять, работает ли правило так, как задумано.