Ошибка с robots.txt в WordPress обычно выглядит одинаково: сайт вроде бы открыт для индексации, но в Search Console появляются предупреждения о заблокированных ресурсах, а страницы начинают рендериться не так, как в браузере. Чаще всего проблема не в самом файле, а в том, что в него добавили слишком широкие запреты и случайно закрыли CSS, JS, изображения или sitemap.
Ниже — практический разбор: как понять, что именно сломано, как безопасно собрать robots.txt для WordPress и как проверить, что после правки поисковый робот видит сайт так же, как пользователь.
Когда проблема действительно в robots.txt
Не каждый провал в индексации связан с этим файлом. Сначала стоит отделить блокировку обхода от других причин: noindex в мета-тегах, canonical на другую страницу, ошибки сервера, редиректы или проблемы с доступом к статике через CDN.
Признаки, что robots.txt мешает
- в Search Console есть сообщения о заблокированных ресурсах CSS/JS;
- страницы индексируются, но в сниппете или рендере видны «сломанные» блоки;
- после обновления темы часть стилей перестала учитываться поисковиком;
- в robots.txt есть правила вида
Disallow: /wp-content/или запрет на весь/wp-includes/без исключений; - sitemap.xml не указан или указан с ошибкой.
Если сайт открывается в браузере нормально, но робот видит его иначе, почти всегда стоит проверить именно доступ к статическим файлам и карту сайта.
Что должно быть в robots.txt для WordPress
У WordPress нет одного «правильного» robots.txt для всех случаев, но есть безопасная база. Она не запрещает критичные ресурсы и не мешает поисковику находить sitemap.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xmlЭтот вариант обычно достаточно аккуратный: админка закрыта, AJAX-эндпоинт доступен, карта сайта указана явно. Если у вас другой URL sitemap, подставьте фактический адрес, который генерирует ваш SEO-плагин или ядро.
Важно: не добавляйте в robots.txt запрет на /wp-content/ целиком, если не понимаете последствия. В этой папке лежат темы, стили, скрипты, изображения и загрузки. Полный запрет часто ломает рендеринг и мешает поисковику корректно оценить страницу.
Диагностика: что проверить до правки
Перед изменением файла полезно быстро пройтись по нескольким точкам. Это экономит время и помогает не чинить не ту проблему.
- Откройте
/robots.txtв браузере и проверьте, что файл реально отдается с кодом 200. - Посмотрите, не генерирует ли его SEO-плагин автоматически.
- Проверьте, нет ли в нем старых правил от предыдущего разработчика.
- Сравните путь к sitemap с фактическим адресом карты сайта.
- Проверьте, не закрыты ли CSS/JS в
wp-contentчерез слишком общийDisallow.
Если сайт использует CDN или отдельную папку для статики, проверьте и ее. Иногда проблема не в WordPress, а в том, что поисковик получает запрет уже на уровне прокси или edge-правил.
Пошаговая настройка без риска сломать рендеринг
Самый надежный путь — не редактировать robots.txt «на глаз», а сначала зафиксировать текущий вариант, потом внести минимальные изменения и проверить результат.
Шаг 1. Сохраните текущий файл
Если robots.txt лежит в корне сайта как физический файл, скачайте его копию. Если он виртуальный и генерируется WordPress или плагином, зафиксируйте содержимое в заметке или репозитории. Это нужно, чтобы быстро откатиться, если после правки что-то пошло не так.
Шаг 2. Уберите широкие запреты
Ищите правила, которые блокируют целые каталоги без необходимости. Особенно опасны такие варианты:
Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/themes/
Disallow: /wp-content/plugins/Если цель — скрыть служебные файлы, а не весь фронтенд, такие правила лучше не использовать. Поисковику нужны доступные CSS и JS, иначе он может некорректно оценить страницу.
Шаг 3. Оставьте только то, что действительно нужно закрыть
Обычно достаточно закрыть админку, служебные страницы поиска по сайту, внутренние параметры и технические разделы, которые не должны попадать в обход. Но каждое правило должно быть проверяемым. Если не можете объяснить, зачем оно нужно, лучше не добавлять его в robots.txt.
Шаг 4. Укажите sitemap явно
Это особенно полезно, если у вас несколько карт сайта или нестандартная структура. Поисковику проще и быстрее найти нужные URL, когда sitemap указан прямо в robots.txt.
Пример безопасного robots.txt для типового WordPress
Ниже — рабочая база, которую можно адаптировать под конкретный сайт. Она не закрывает статику и не мешает индексации CSS/JS.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /search/
Disallow: /?s=
Sitemap: https://example.com/sitemap_index.xmlЕсли у вас поиск работает по другому URL, замените /search/ на фактический путь. Не добавляйте шаблонные запреты, если они не соответствуют реальной структуре сайта.
Сравнение подходов: плагин, ручной файл или серверная настройка
| Подход | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин SEO | Удобно редактировать из админки, меньше риска ошибиться с путями | Зависимость от логики плагина, иногда неочевидная генерация | Если robots.txt меняют не разработчики, а редакторы или SEO-специалисты |
| Физический файл в корне | Прозрачный контроль, легко отдать нужный вариант | Можно случайно перезаписать при деплое | Если у вас есть доступ к файловой системе и понятный процесс обновления |
| Серверная настройка | Подходит для сложных схем с CDN и reverse proxy | Сложнее поддерживать, нужен доступ к конфигам | Если сайт обслуживает DevOps или есть нестандартная инфраструктура |
Как проверить, что решение сработало
После правки не ограничивайтесь открытием файла в браузере. Нужно проверить именно то, как его видит поисковый робот.
- Откройте
/robots.txtи убедитесь, что там нет лишних запретов на/wp-content/и/wp-includes/. - Проверьте, что sitemap доступен по указанному адресу и отдает 200 OK.
- В Search Console запустите проверку URL и посмотрите, не блокируются ли ресурсы страницы.
- Откройте страницу в режиме просмотра исходного кода и убедитесь, что CSS/JS подключаются из доступных путей.
- Если есть доступ к логам, посмотрите, обращается ли бот к sitemap и не получает ли 403 на статические файлы.
Хороший практический тест — открыть страницу в инструменте проверки URL и сравнить рендер с обычным браузером. Если поисковик видит страницу без критичных блоков, значит robots.txt больше не мешает.
Частые ошибки и как их исправить
Закрыли весь wp-content
Это самая частая ошибка. В результате робот не видит стили, скрипты и изображения. Исправление простое: уберите общий запрет и оставьте только точечные правила для действительно служебных путей, если они нужны.
Указали несуществующий sitemap
Если карта сайта переехала после смены SEO-плагина, старый адрес в robots.txt становится бесполезным. Проверьте фактический URL и замените его на актуальный.
Смешали robots.txt и noindex
Если страница закрыта в robots.txt, поисковик может не увидеть мета-тег noindex на самой странице. Для удаления URL из индексации это может быть критично. Сначала проверьте, что именно вы хотите: запретить обход или исключить страницу из индекса.
Правили файл, но изменения не применились
Так бывает, если robots.txt генерирует SEO-плагин, а вы редактируете физический файл, который сервер не использует. Нужно понять источник файла и менять его там, где он реально формируется.
Безопасность и производительность: что учесть
Robots.txt не защищает данные. Он лишь подсказывает роботам, что не стоит обходить. Если вам нужно скрыть админку, используйте нормальную авторизацию, ограничение доступа по IP, двухфакторную аутентификацию и актуальные права пользователей. Не рассчитывайте на robots.txt как на механизм безопасности.
С точки зрения производительности сам файл почти ничего не весит, но ошибки в нем могут косвенно ухудшить поведение поисковых систем: лишние обходы, неверный рендер, повторные проверки заблокированных ресурсов. Поэтому лучше держать файл коротким, понятным и без экспериментальных правил.
Если на сайте много технических дублей, параметров и мусорных URL, удобнее сначала навести порядок в индексации на уровне canonical, noindex и sitemap, а уже потом править robots.txt. Для этого часто используют SEO-инструменты вроде Clearfy Pro, но только если они реально нужны в вашем стекe и вы понимаете, какие правила они добавляют.
Мини-чек-лист перед публикацией изменений
- robots.txt открывается по основному домену и отдает 200;
- в файле нет запрета на весь
/wp-content/; - CSS и JS страницы доступны роботу;
- sitemap указан актуальный и открывается без ошибок;
- в Search Console нет новых сообщений о заблокированных ресурсах;
- изменения внесены в тот источник, который реально обслуживает сайт.
Если после правки страницы стали индексироваться корректнее, а предупреждения о заблокированных ресурсах исчезли, значит проблема была именно в robots.txt или в его генерации. Если нет — ищите причину в noindex, canonical, редиректах или серверных ограничениях.