Как правильно настроить robots.txt в WordPress

Автор: Антон Панин | Опубликовано: 06.10.2026

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

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

Что должен делать robots.txt на WordPress-сайте

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

Типовая задача robots.txt для WordPress — разрешить обход полезных страниц и ограничить доступ к техническим и служебным адресам. Обычно речь идёт о таких разделах:

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

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

Базовый рабочий вариант robots.txt для WordPress

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

Ниже пример, с которого можно начать. Он не универсален на 100%, но подходит для типового сайта на WordPress, если у вас нет особых технических ограничений и нестандартных разделов:

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

Здесь важно понимать логику:

User-agent: * задаёт правила для всех роботов;
Disallow: /wp-admin/ ограничивает обход админ-раздела;
Allow: /wp-admin/admin-ajax.php оставляет доступ к AJAX-эндпоинту, который часто нужен теме и плагинам;
Disallow: /wp-login.php уменьшает бессмысленный обход страницы входа.

Если ваш сайт использует нестандартную логику авторизации, кэширования или AJAX-запросов, проверьте, не завязаны ли на admin-ajax.php публичные функции темы или плагинов. Этот адрес обычно оставляют открытым именно поэтому.

Что обычно закрывают, а что лучше не трогать

В WordPress часто хочется закрыть всё подряд: /wp-content/, /wp-includes/, страницы поиска, архивы, параметры и даже весь сайт. Так делать не стоит без понимания последствий.

Практически полезный подход такой:

Что делать	Когда уместно	Что учитывать
Закрывать `/wp-admin/`	Почти всегда	Оставляйте доступ к `admin-ajax.php`, если он нужен сайту
Закрывать служебные страницы входа	Если нет причины отдавать их роботам	Это не защита от взлома, а только ограничение обхода
Закрывать внутренний поиск	Если он создаёт много мусорных URL	Проверьте, не используются ли эти страницы в навигации
Закрывать каталоги с дублями	Если они действительно порождают лишние URL	Не путайте дубли с важными страницами сайта

А вот что часто закрывают зря:

/wp-content/ целиком — внутри могут быть изображения, CSS, JS и другие ресурсы, которые поисковику полезно видеть;
/wp-includes/ — это техническая часть WordPress, но массово закрывать её без причины обычно не нужно;
страницы категорий, тегов и архивов — если они участвуют в структуре сайта и дают трафик;
URL с параметрами, если они используются для нормальной навигации или фильтров.

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

Как создать и разместить robots.txt в корне сайта

Файл должен лежать в корневой директории сайта и открываться по адресу https://site.ru/robots.txt. Для WordPress это обычно каталог рядом с wp-config.php, wp-admin и wp-content.

Создать файл можно любым удобным способом:

через файловый менеджер хостинга;
по FTP/SFTP;
через панель управления сервером;
локально с последующей загрузкой на сервер.

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

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

Как не сломать сайт неправильной директивой

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

Особенно осторожно нужно обращаться с такими правилами:

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

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

Проверка после настройки

После правки robots.txt не ограничивайтесь тем, что файл «сохранился». Нужно проверить три вещи: доступность файла, корректность правил и отсутствие побочных эффектов.

Минимальная проверка выглядит так:

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

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

Частые ошибки в robots.txt для WordPress

На практике проблемы повторяются из раза в раз. Вот самые типичные:

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

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

Когда robots.txt недостаточно

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

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

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