Файл robots.txt определяет, какие разделы сайта поисковые роботы могут сканировать, а какие — нет. Для сайтов на WordPress настройка robots.txt становится обязательным шагом технического SEO. Правильно составленный robots.txt WordPress помогает управлять краулинговым бюджетом, исключает дублирующийся контент из индекса и защищает служебные страницы от попадания в выдачу. В этой статье разберём, как создать, где разместить и как проверить корректный robots.txt для WordPress с учётом версий CMS 6.7+ и современных требований поисковых систем в 2026 году.
Зачем нужен robots.txt для WordPress
Поисковые роботы ограничены в ресурсах, которые они готовы потратить на сканирование одного сайта. Этот лимит называют краулинговым бюджетом. Для интернет-магазинов на WooCommerce с каталогом 15 000 товаров или новостных порталов с тысячами публикаций бюджет становится критичным. Если робот тратит квоту на страницы входа, RSS-ленты, технические дубли, он не успеет добраться до важных посадочных страниц. WordPress по умолчанию генерирует множество служебных URL, которые индексировать не нужно.
Грамотный robots.txt для WordPress решает три задачи:
- Блокирует непубличные и технические разделы: админку, системные файлы, скрипты.
- Исключает динамический мусор: страницы поиска, фиды, трекбеки.
- Экономит краулинговый бюджет, оставляя его для целевых страниц, карточек товаров и статей.
При этом robots.txt — не панацея от индексации. Директива Disallow не гарантирует, что страница не попадёт в индекс, если на неё ведут внешние ссылки. Для полного исключения из поиска лучше применять метатег noindex. Подробнее о комплексной SEO-оптимизации читайте в статье SEO-оптимизация WordPress сайта.
Где находится и как редактировать robots.txt в WordPress
В стандартной установке WordPress физический файл robots.txt в корневой директории отсутствует. CMS генерирует так называемый виртуальный robots.txt. При обращении к /robots.txt WordPress перехватывает запрос и отдаёт динамический ответ со стандартным содержимым, зависящим от настроек приватности. Но у такого подхода есть нюансы — отсутствие полного контроля и неудобство правок.
Альтернатива — создать физический файл robots.txt в корне сайта через FTP или файловый менеджер хостинга. Физический файл имеет приоритет над виртуальным: если сервер видит статический документ, он отдаёт его, игнорируя логику WordPress. Это позволяет полностью управлять содержимым, но требует внимания при обновлении плагинов, которые могут добавлять или изменять директивы виртуального файла.
На мультисайтовых установках WordPress каждый подсайт имеет собственный виртуальный robots.txt. Физический файл в корне будет применяться ко всей сети, поэтому для мультисайта предпочтительнее редактировать robots.txt через плагины для каждого сайта отдельно.
Через SEO-плагин
Самый удобный способ управления robots.txt в WordPress — использование SEO-плагинов, таких как Yoast SEO, RankMath, All in One SEO. Они предоставляют встроенный редактор и автоматически добавляют важные директивы, например путь к файлу sitemap.
В Yoast SEO (версии 22.x и выше для WordPress 6.7) перейдите в раздел «SEO» → «Инструменты» → «Редактор файлов». Здесь вы увидите поле для robots.txt. Плагин автоматически собирает базовый контент на основе параметров сайта, но можно вносить ручные правки. После сохранения изменения вступают в силу мгновенно — Yoast перехватывает запрос и отдаёт ваш вариант.
В RankMath (версия 1.0.220+) путь отличается: «Rank Math» → «Общие настройки» → «Редактировать robots.txt». Интерфейс позволяет переключаться между простым и продвинутым режимами, а также тестировать файл перед публикацией. Если на сайте установлен физический файл, плагин может предупредить о конфликте и предложить удалить его для активации виртуального.
Через файловый менеджер или FTP
Для создания физического robots.txt подключитесь к серверу по FTP (с помощью FileZilla, WinSCP) или через файловый менеджер панели управления хостингом. В корневой папке сайта (обычно public_html или www) создайте текстовый файл с именем robots.txt. Кодировка — UTF-8 без BOM. Убедитесь, что права доступа позволяют серверу читать этот файл (обычно 644).
После загрузки проверьте доступность файла по адресу https://ваш-сайт.ru/robots.txt. Если виртуальный robots.txt настраивался плагином, он перестанет работать. Это нормально, но имейте это в виду, если планируете в будущем управлять robots.txt через админку — физический файл нужно будет удалять вручную.
Оптимальный robots.txt для WordPress: пример и пояснение директив
Ниже готовый шаблон, проверенный на проектах с разной архитектурой — от блогов до магазинов. Комментарии даны после символа #. Этот код можно скопировать в редактор плагина или в физический файл.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-json/
Disallow: /?s=
Disallow: /feed/
Disallow: /trackback/
Disallow: /xmlrpc.php
Sitemap: https://example.com/sitemap_index.xmlРазберём каждую строку.
Закрытие /wp-admin/
Директория /wp-admin/ содержит файлы административной панели WordPress. Она не несёт ценности для посетителей из поиска, а её попадание в индекс — признак уязвимости или неверной конфигурации. Поэтому блокировка обязательна. Однако внутри /wp-admin/ находится файл admin-ajax.php, через который работают важные интерфейсные функции: обновление корзины WooCommerce, подгрузка товаров, обработка контактных форм. Если закрыть доступ к нему полностью, некоторые динамические элементы могут лишиться возможности обновления для поисковых роботов. Строка «Allow: /wp-admin/admin-ajax.php» открывает к нему доступ, снимая ограничение.
Закрытие /wp-includes/
/wp-includes/ хранит ядро CMS: классы, функции, скрипты. Доступ к этим файлам напрямую не требуется ни пользователям, ни роботам. Сканирование этой папки бессмысленно тратит бюджет. В редких случаях отдельные JavaScript-файлы из этой директории могут запрашиваться для рендеринга страниц. По состоянию на 2026 год Google уже не требует прямого доступа к ресурсам из /wp-includes/ для корректной обработки Core Web Vitals, поэтому безопасно закрывать её полностью.
Нужно ли закрывать /wp-content/plugins/
Вопрос дискуссионный. Часть специалистов рекомендует закрыть, потому что в папках плагинов могут находиться файлы readme.txt, скриншоты, технические каталоги, индексация которых не нужна. Другие предостерегают: многие плагины хранят CSS, JS и шрифты, необходимые для фронтенда. Блокировка /wp-content/plugins/ полностью может привести к тому, что поисковые системы не увидят стили и скрипты, а это чревато ошибками в отчёте Google Search Console по удобству мобильных и ухудшением восприятия страницы.
На практике мы столкнулись с кейсом: робот Google не мог загрузить скрипт плагина кэширования, который добавлял inline-стили, и страницы начали получать статус «Неоптимальный рендеринг». После удаления Disallow: /wp-content/plugins/ проблема ушла. Рекомендация: если сайт небольшой и краулинговый бюджет не исчерпан, лучше не закрывать всю директорию. Если бюджет ограничен — закройте только отдельные подпапки с readme или скриншотами, которые известны и не влияют на фронтенд. Либо используйте мета-теги noindex для конкретных типов контента, как описано в руководстве WordPress — SEO и индексация.
Дополнительные блокировки
/wp-json/ — эндпоинт REST API WordPress. В ответе могут быть служебные данные, не предназначенные для индексации. Поисковики обычно не индексируют JSON, но для перестраховки его блокируют.
/?s= — внутренний поиск. Страницы вида example.com/?s=запрос создают дубликаты и раздувают структуру сайта. Закрываем.
/feed/ — RSS-ленты. Они генерируют множество URL с частичными дублями контента. Если только вы не используете фиды как основной источник распространения, лучше закрыть.
/trackback/ — трекбек-ссылки. В 2026 году технология практически не используется, но WordPress продолжает создавать соответствующие ссылки. Закрываем для экономии бюджета.
/xmlrpc.php — файл для удалённой публикации. Часто является целью атак, для роботов интереса не представляет. Блокировка полезна с точки зрения безопасности, хотя не является прямым сигналом.
Директива Sitemap и Host
Директива Sitemap указывает путь к файлу карты сайта. Поисковые системы используют её как подсказку для нахождения всех важных URL. В WordPress плагины генерируют sitemap автоматически; для Yoast это обычно sitemap_index.xml, для RankMath — sitemap.xml. Пишем полный URL: Sitemap: https://example.com/sitemap_index.xml. Рекомендуется размещать директиву в конце файла. Создание правильного sitemap для WordPress подробно разбирается в статье Как создать sitemap для WordPress сайта.
Директива Host ранее использовалась для указания главного домена в Яндексе. С 20 марта 2018 года Яндекс объявил о прекращении поддержки Host в robots.txt и перевёл управление главным зеркалом в интерфейс Яндекс.Вебмастера. Несмотря на это, старые руководства до сих пор рекомендуют её добавлять. По состоянию на 2026 год директива Host не обрабатывается ни Яндексом, ни Google, ни Bing. Указывать её не нужно. Если в файле осталась строка с Host, удалите — она не приносит пользы и может смущать при аудите.
Частые ошибки при настройке robots.txt в WordPress
Разберём проблемы, которые мы регулярно видим при аудитах сайтов.
Блокировка CSS и JavaScript файлов
Запрет на сканирование папок с темами, плагинами или даже /wp-includes/ может перекрыть доступ к .css и .js. Googlebot должен загрузить эти ресурсы для корректного рендеринга страниц. Если рендеринг нарушен, поисковая система может понизить позиции страницы или вовсе исключить её из выдачи. В Google Search Console в отчёте «Основные интернет-показатели» вы увидите ошибки LCP, CLS, связанные с заблокированными ресурсами. Убедитесь, что директории, содержащие файлы шаблона и важные скрипты, не закрыты Disallow. Для проверки используйте инструмент «Проверка robots.txt» в GSC, указав URL конкретного CSS-файла.
Запрет Googlebot через User-agent
Иногда в файле можно встретить строку:
User-agent: Googlebot
Disallow: /Это полностью блокирует Googlebot от сканирования. Часто такое случается, когда разработчик на время тестирования поставил запрет и забыл убрать. Результат — полное выпадение из индекса Google. Для Яндекса аналогичная блокировка создаётся через User-agent: YandexBot. Всегда проверяйте, что для основных поисковых роботов нет полного Disallow. Если требуется временная блокировка, используйте noindex.
Забытый Disallow: /
Директива Disallow: / означает запрет на сканирование всего сайта. На тестовых или staging-сайтах это стандартная практика. Но при переносе на боевой домен файл часто остаётся без изменений. Убедитесь, что в корневом robots.txt вашего продакшн-сайта нет строки «Disallow: /» без последующего Allow. Регулярная проверка через панель веб-мастера позволит обнаружить такую ошибку до падения трафика.
Crawl-delay: нужен ли он
Crawl-delay задаёт задержку между запросами в секундах. Googlebot не поддерживает эту директиву — регулировка скорости сканирования для Google выполняется только через Search Console. Яндекс поддерживал Crawl-delay, но приоритетным способом управления является Яндекс.Вебмастер. В 2026 году ставить Crawl-delay в robots.txt для Яндекса не запрещено, но официальная документация рекомендует использовать настройки в вебмастере. Bing также не поддерживает директиву. Поэтому в общем случае Crawl-delay не требуется.
Проверка robots.txt
После внесения изменений обязательно протестируйте файл. Google Search Console содержит инструмент «Проверка robots.txt». Он показывает, как Googlebot интерпретирует ваш файл на текущий момент, и позволяет протестировать доступ к любому URL. Введите адрес важной страницы (например, товара или статьи) и убедитесь, что она разрешена. Затем введите путь к файлу CSS или JS, чтобы удостовериться, что они не заблокированы.
Яндекс.Вебмастер также имеет анализатор robots.txt. Он покажет, как Яндекс-робот видит файл, и предупредит о синтаксических ошибках или устаревших директивах. Bing Webmaster Tools предоставляет аналогичный функционал. Дополнительно можно использовать сторонние онлайн-сервисы, вводя URL своего robots.txt, но официальные инструменты надёжнее, поскольку они работают с реальными агентами поисковиков.
Проверяйте robots.txt после:
- переноса сайта на новый домен или хостинг;
- смены SEO-плагина;
- изменения структуры постоянных ссылок;
- обнаружения резкого падения индексации.
Часто задаваемые вопросы
Можно ли закрыть страницы пагинации и архивов в robots.txt?
Можно, но не рекомендуется. Страницы пагинации (/page/2/) и архивы дат или авторов могут нести полезный трафик. Лучше управлять их индексацией через canonical на основную страницу либо закрывать мета-тегом noindex в плагине SEO. Прямая блокировка в robots.txt лишит поисковика возможности найти внутренние ссылки на статьи, что замедлит переобход контента.
Что делать, если после изменения robots.txt пропала индексация?
Откатить файл к предыдущей версии. Если использовался виртуальный robots.txt через плагин — вернуть старые настройки. Если физический — восстановить из резервной копии. Затем проверить, не появились ли директивы Disallow: / или запрет для основных User-agent. Отправить страницы на переобход через Google Search Console и Яндекс.Вебмастер. Если индексация не восстанавливается, подключите сервис мгновенной индексации Index-Now.ru, который ускорит оповещение поисковых систем об изменениях.
Нужно ли закрывать файл wp-login.php?
Файл входа /wp-login.php не несёт ценности для поиска. Рекомендуется добавить его в robots.txt: Disallow: /wp-login.php. Однако для надёжной блокировки индексации дополнительно настройте редирект для неавторизованных пользователей или используйте плагин безопасности, который меняет URL входа.
Как robots.txt влияет на безопасность WordPress?
robots.txt — не инструмент безопасности. Запрет на сканирование уязвимых директорий не скроет их от злоумышленников, которые могут прямо обратиться по URL. Тем не менее, файл позволяет не светить некоторые технические пути в результатах поиска, что снижает поверхность для автоматических атак, ищущих уязвимости через выдачу.
Как настроить robots.txt для мультиязычного сайта с поддоменами?
Если разные языки вынесены на поддомены (en.example.com, de.example.com), robots.txt должен быть у каждого поддомена свой. В WordPress Multilingual (WPML) для каждого языка создаётся виртуальный robots.txt с учетом настроек. Если используются физические файлы, создайте отдельный robots.txt в корне каждого поддомена, прописав в них соответствующие Sitemap и учитывая особенности структуры.
После настройки корректного robots.txt и создания карты сайта стоит позаботиться об оперативном информировании поисковиков о новых и обновлённых страницах. Стандартный переобход может занимать дни или недели. Сервис Index-Now.ru использует протокол IndexNow, поддерживаемый Яндексом, Bing и экспериментально Google, и позволяет отправлять запросы на индексацию сразу после публикации. Это сокращает путь контента в выдачу и помогает поддерживать актуальность сниппетов. Настройка занимает несколько минут и не заменяет robots.txt, а дополняет стратегию технического SEO.