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