В WordPress-блогах robots.txt часто правят по одному и тому же сценарию: кто-то копирует готовый шаблон из статьи, добавляет туда Disallow: /wp-content/ и потом удивляется, почему в поиске пропали изображения, стили или полезные страницы. На практике задача проще и уже: не «закрыть всё лишнее», а аккуратно подсказать роботам, куда не ходить, не ломая обход важных разделов блога.
Если блог уже живёт, публикуется регулярно и получает трафик из поиска, robots.txt нужен не для магии, а для дисциплины обхода. Он не убирает страницы из индекса сам по себе, но помогает не тратить краулинговый бюджет на служебные URL и не провоцировать лишние обходы мусорных путей.
Когда robots.txt действительно нужен блогу
Сначала стоит понять, есть ли у вас вообще проблема, которую этот файл решает. Для небольшого блога без тысяч страниц robots.txt не заменяет нормальную структуру сайта и не чинит дубли. Зато он полезен, если в логах или в отчётах Search Console видно, что робот регулярно ходит в служебные каталоги, параметры поиска, внутренние скрипты или технические URL, которые не должны конкурировать с контентом.
Типичные симптомы
- в отчётах обхода много запросов к
/wp-admin/,/wp-includes/, служебным параметрам и внутреннему поиску; - в индексе всплывают страницы с параметрами, которые вы не хотите продвигать;
- робот тратит время на неважные URL, а новые статьи индексируются медленнее обычного;
- в robots.txt уже есть старые правила, добавленные «на всякий случай», и никто не помнит, зачем они нужны.
Если у вас проблема именно с индексацией конкретных страниц, robots.txt не всегда лучший инструмент. Для закрытия от индексации чаще нужен noindex или корректная настройка мета-тегов, а не запрет обхода. Это важное различие: robots.txt управляет доступом робота, но не гарантирует удаление URL из индекса.
Что закрывать, а что не трогать
Для блога на WordPress обычно имеет смысл закрывать только служебные и технические пути. Не стоит бездумно запрещать целые каталоги, если внутри есть файлы, которые участвуют в отображении сайта или нужны для корректного рендеринга страниц.
| Подход | Что делает | Когда уместен | Риск |
|---|---|---|---|
| Плагин | Генерирует robots.txt и помогает не ошибиться в синтаксисе | Если не хотите править файл вручную | Легко добавить лишние правила по шаблону |
| Ручной файл | Полный контроль над директивами | Если нужен точный и короткий набор правил | Ошибки синтаксиса и случайные блокировки |
| Комбинированный подход | Базовый файл вручную, точечные правки через плагин | Для живого блога с регулярными правками | Нужно следить, кто именно перезаписывает файл |
Что обычно можно закрыть
/wp-admin/— кромеadmin-ajax.php, если он нужен фронтенду;- внутренний поиск, если он создаёт мусорные URL и не нужен в выдаче;
- служебные файлы и каталоги, которые не должны участвовать в обходе;
- тестовые и временные пути, если они реально существуют на сайте.
Не закрывайте /wp-content/uploads/ целиком, если изображения блога должны индексироваться и попадать в поиск по картинкам. Не закрывайте CSS и JS, если это может помешать Google корректно отрисовать страницу. И не пытайтесь через robots.txt решить задачу, где нужен noindex или редирект.
Пошаговая настройка robots.txt для WordPress-блога
Самый надёжный вариант — начать с минимального файла и добавлять только то, что вы можете объяснить. Для большинства блогов достаточно короткого набора правил.
Шаг 1. Проверьте текущий robots.txt
Откройте https://ваш-домен.ru/robots.txt и посмотрите, кто его формирует. В WordPress файл может быть физическим, а может генерироваться на лету. Если там уже есть правила от SEO-плагина, не дублируйте их вручную без необходимости.
Шаг 2. Соберите только нужные запреты
Ниже пример аккуратного файла для типичного блога. Он не пытается «закрыть весь WordPress», а только убирает очевидные служебные обходы.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Sitemap: https://example.com/sitemap_index.xmlЕсли у вас другой формат карты сайта, укажите реальный URL. Не копируйте sitemap_index.xml вслепую: у некоторых сайтов карта генерируется по другому адресу.
Шаг 3. Если нужен отдельный запрет для ботов
Иногда блог перегружается от агрессивных ботов, и тогда можно точечно ограничить конкретного user-agent. Но это уже не базовая SEO-настройка, а техническая защита от лишнего трафика. Делайте это только если понимаете, кого именно блокируете.
User-agent: BadBot
Disallow: /
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.phpТакой вариант не нужен большинству блогов. Если вы не видите явного вреда, лучше не плодить исключения.
Как править robots.txt в WordPress без лишнего риска
Есть два рабочих пути: через файл на сервере или через SEO-плагин. Ручной способ даёт полный контроль, но требует аккуратности. Плагин удобнее, если файл часто меняется и за ним следят несколько человек.
Ручная правка через FTP или файловый менеджер
Если на сервере уже есть физический robots.txt, откройте его и внесите минимальные изменения. Перед правкой сохраните копию. Это банально, но именно здесь чаще всего ломают сайт не из-за WordPress, а из-за одной лишней строки.
Если файла нет, WordPress может отдавать виртуальный robots.txt. Тогда физический файл в корне сайта начнёт его перекрывать. Это удобно, но важно помнить: после создания файла вы берёте ответственность за его содержимое полностью на себя.
Через SEO-плагин
Если вы уже используете SEO-плагин, проверьте, не редактируется ли robots.txt из его интерфейса. Это удобно для блога, где контент-редакторы не должны лезть в FTP. Но не смешивайте два источника правды: если правила есть и в файле, и в плагине, потом сложно понять, что именно отдаётся роботам.
Если нужен более широкий набор технических настроек для блога, иногда удобнее держать их в одном месте вместе с чисткой дублей и служебных страниц. В таких случаях полезно смотреть в сторону инструментов вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но и здесь правило одно: сначала понять, что вы закрываете, потом включать настройку.
Проверка результата после внедрения
После правки не ограничивайтесь тем, что файл открывается в браузере. Нужно проверить, что robots.txt не блокирует важные страницы и что поисковый робот видит именно то, что вы задумали.
- Откройте
/robots.txtи убедитесь, что файл отдаётся с кодом ответа 200. - Проверьте, что в нём нет случайных
Disallow: /или слишком широких масок. - Посмотрите, доступна ли главная, рубрики и отдельные статьи для обхода.
- В Search Console проверьте, не появились ли ошибки, связанные с блокировкой важных ресурсов.
- Если меняли правила для поиска, убедитесь, что внутренний поиск блога больше не создаёт лишний шум в обходе.
Полезно отдельно проверить, не закрыли ли вы CSS и JS. Если поисковик не может отрисовать страницу, он хуже понимает её содержимое. Для блога это особенно заметно на страницах с блоками, таблицами, встроенными видео и сложной версткой.
Частые ошибки и как их исправить
Закрыли слишком много
Самая частая ошибка — запретить каталоги, которые нужны для нормальной работы сайта. Если после правки упали стили, исчезли изображения или сломалась админка, первым делом откатывайте изменения и проверяйте, не закрыт ли /wp-content/ или важные статические ресурсы.
Путают robots.txt и noindex
Если задача — убрать страницу из индекса, robots.txt не всегда помогает. Робот может не попасть на страницу, но URL всё равно останется в индексе как «известный, но недоступный». Для таких случаев нужен другой механизм: мета-robots, заголовок X-Robots-Tag или редирект, если страница больше не нужна.
Оставили старые правила после миграции
После переезда блога часто забывают удалить запреты для старых путей, тестового домена или каталога staging. В результате робот продолжает видеть мусорные директивы, а вы потом ищете проблему в sitemap или canonical. После миграции robots.txt нужно пересматривать вручную, а не оставлять «как было».
Смешали несколько источников
Если файл редактируется и в плагине, и через FTP, и ещё где-то в теме, вы почти гарантированно получите путаницу. Должен быть один источник, который считается главным. Для блога с несколькими редакторами обычно проще держать всё в одном SEO-плагине или в одном физическом файле.
Практические советы по безопасности и производительности
robots.txt сам по себе не защищает сайт, но может снизить лишнюю нагрузку от роботов и случайных обходов. Не используйте его как замену нормальной защите админки, лимитам запросов или обновлениям WordPress. Это вспомогательный файл, а не щит.
Если блог активно растёт, держите robots.txt коротким. Чем меньше в нём ручных исключений, тем ниже шанс сломать обход после очередной правки. И не добавляйте туда правила «на будущее»: если проблема не подтверждена, правило лучше не писать.
Для контентных сайтов полезно периодически сверять robots.txt с реальной структурой блога: появились новые рубрики, изменилась карта сайта, добавились служебные страницы, подключился поиск по сайту. То, что было уместно полгода назад, сейчас может мешать индексации новых материалов.
Если хотите, чтобы технические настройки блога не расползались по разным местам, заранее определите, где вы управляете индексированием, дублями и служебными страницами. Тогда robots.txt станет частью общей схемы, а не отдельным файлом, который правят по памяти.