Если в WordPress внезапно полезли в индекс служебные URL, это не всегда проблема «плохого SEO». Чаще всего причина проще: поисковик видит то, что ему вообще не нужно обходить — /wp-admin/, служебные параметры, внутренние результаты поиска, страницы с фильтрами и технические каталоги плагинов. В такой ситуации помогает не «магический» robots.txt, а аккуратная настройка с пониманием, что именно вы закрываете и зачем.
Ниже разберём рабочий сценарий: какие разделы имеет смысл ограничить, как не сломать индексацию важных страниц и как проверить, что файл действительно отрабатывает так, как вы ожидаете.
Какая проблема решается robots.txt, а какая — нет
Robots.txt управляет обходом, а не удалением страниц из индекса. Это важное различие. Если URL уже попал в поиск, одной директивы Disallow может быть недостаточно: робот перестанет заходить на страницу, но сам URL может ещё какое-то время оставаться в выдаче без сниппета. Для удаления уже проиндексированных страниц обычно нужны noindex, редирект, 404/410 или ручная работа через инструменты поисковой системы.
Robots.txt полезен, когда нужно:
- сократить обход мусорных URL;
- не тратить краулинговый бюджет на служебные разделы;
- закрыть от обхода внутренний поиск, параметры сортировки, временные каталоги;
- не пускать робота в административные и системные области.
Но не стоит использовать его как универсальную кнопку «убрать из индекса». Если страница уже индексируется и должна исчезнуть, сначала проверьте, не нужен ли другой механизм.
Диагностика: что именно закрывать в WordPress
Перед правкой файла полезно посмотреть, какие URL реально создают шум. В WordPress это обычно один из нескольких сценариев.
Служебные и административные разделы
Их трогать проще всего: /wp-admin/ поисковикам не нужен, а служебные запросы к admin-ajax.php обычно не несут ценности для индексации. При этом полностью закрывать /wp-admin/ нужно аккуратно: роботам не нужен интерфейс админки, но некоторые плагины могут генерировать публичные endpoints через AJAX. Поэтому лучше закрывать именно то, что точно служебное.
Внутренний поиск и параметры
Страницы вида /?s=... часто создают бесконечное количество вариантов. Если поиск на сайте нужен пользователям, это не значит, что его результаты должны индексироваться. То же касается параметров сортировки, фильтров, UTM-меток и прочих query string, которые плодят дубли.
Технические каталоги плагинов и тем
Некоторые плагины создают публичные папки с файлами, которые не должны попадать в поиск. Но закрывать их стоит только после проверки: иногда в этих каталогах лежат CSS, JS или медиафайлы, которые должны быть доступны браузеру. Если запретить слишком широко, можно сломать фронтенд.
Пошаговая настройка robots.txt в WordPress
Самый безопасный путь — сначала посмотреть текущий файл, потом добавить только нужные директивы, а не переписывать всё с нуля. В WordPress robots.txt может быть виртуальным, если физического файла нет. Тогда его генерирует сам сайт или SEO-плагин.
Шаг 1. Проверьте текущий robots.txt
Откройте https://ваш-домен.ru/robots.txt и посмотрите, что уже там есть. Если файл отдаёт 404, значит, его нет физически и, возможно, используется виртуальная версия. Если robots.txt уже существует, не удаляйте старые правила без понимания, кто их добавил: SEO-плагин, тема, хостинг или ручная настройка.
Шаг 2. Добавьте только базовые запреты
Для большинства сайтов достаточно ограничить админку, системные файлы и внутренний поиск. Пример аккуратного robots.txt:
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /search/
Disallow: /*?replytocom=
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xmlЗдесь важно не копировать шаблон вслепую. Например, /search/ есть не на каждом сайте. Если у вас поиск работает через другой URL, подставьте свой вариант. А если sitemap у вас генерирует не sitemap_index.xml, а другой файл, укажите реальный адрес.
Шаг 3. Закройте только те параметры, которые создают дубли
Если на сайте есть фильтры, сортировка и пагинация с параметрами, можно ограничить конкретные шаблоны URL. Но здесь легко переборщить. Например, запрет Disallow: /*?* может отрезать слишком много, включая полезные страницы с нормальными параметрами. Лучше сначала собрать список реальных мусорных параметров из логов, Search Console или аналитики.
Пример более точечного запрета:
User-agent: *
Disallow: /*?orderby=
Disallow: /*?filter=
Disallow: /*?sort=
Disallow: /*?utm_
Disallow: /*?replytocom=
Allow: /wp-admin/admin-ajax.phpТакой вариант подходит не всем, но показывает принцип: закрываем конкретные шаблоны, а не весь сайт по маске.
Как задать robots.txt через код, если файл генерируется WordPress
Если вы не хотите держать физический файл в корне, можно отдать содержимое через фильтр robots_txt. Это удобно, когда правила должны жить в теме или мини-плагине и не теряться при деплое.
<?php
add_filter( 'robots_txt', function( $output, $public ) {
$lines = array(
'User-agent: *',
'Disallow: /wp-admin/',
'Disallow: /wp-login.php',
'Disallow: /?s=',
'Allow: /wp-admin/admin-ajax.php',
'Sitemap: https://example.com/sitemap_index.xml',
);
return implode( "\n", $lines ) . "\n";
}, 10, 2 );Такой подход полезен, если сайт разворачивается из репозитория и вы хотите хранить SEO-настройки рядом с кодом. Но если robots.txt уже управляется SEO-плагином, сначала проверьте, не перезапишет ли он ваши правила при обновлении настроек.
Сравнение подходов: файл, плагин или код
| Подход | Когда удобен | Риск |
|---|---|---|
| Физический robots.txt | Нужен полный контроль и простая проверка | Можно случайно сломать правила при ручном редактировании |
| Через SEO-плагин | Удобно для редактора без доступа к серверу | Плагин может менять файл при обновлении настроек |
Через фильтр robots_txt | Файл должен жить в коде проекта | Нужно следить за конфликтами с другими плагинами |
Если сайт небольшой, физический файл обычно проще. Если проект поддерживается разработчиком и деплоится из Git, фильтр в коде часто надёжнее. Плагин — компромисс для редакторской команды, но его поведение надо проверять после обновлений.
Проверка результата после внедрения
После правки не ограничивайтесь открытием файла в браузере. Проверьте несколько вещей:
- robots.txt отдаётся с кодом ответа 200;
- в нём нет лишних запретов на важные разделы;
- сайт по-прежнему открывает CSS, JS и изображения;
- внутренний поиск и служебные URL не попадают в обход;
- в Search Console или аналогичном инструменте нет ошибок, связанных с блокировкой нужных страниц.
Минимальная ручная проверка может выглядеть так:
curl -I https://example.com/robots.txt
curl https://example.com/robots.txtЕсли вы работаете на сервере и хотите быстро убедиться, что файл не перезаписывается, проверьте, нет ли физического robots.txt в корне сайта и кто его генерирует. На некоторых хостингах виртуальный robots.txt может вести себя иначе, чем ожидается, если одновременно есть и файл, и фильтр в WordPress.
Частые ошибки и как их исправить
Закрыли слишком много
Самая частая ошибка — запретить всё подряд, а потом обнаружить, что поисковик не видит важные страницы или не может добраться до ресурсов темы. Если после правки просели страницы в индексе, первым делом проверьте, не закрыли ли вы /wp-content/ целиком или шаблон, который цепляет полезные URL.
Путают robots.txt и noindex
Если страница уже в индексе, robots.txt не всегда решает задачу быстро. Для удаления из поиска нужен другой механизм. Если цель — не допустить обхода, robots.txt подходит. Если цель — убрать уже проиндексированную страницу, используйте noindex или редирект.
Закрывают CSS и JS
Иногда в попытке «усилить SEO» закрывают папки, где лежат стили и скрипты. Это плохая идея: поисковики должны видеть страницу так, как её видит браузер. Если ресурсы заблокированы, могут появиться проблемы с рендерингом и оценкой качества страницы.
Дублируют правила из нескольких источников
Когда robots.txt одновременно правится вручную, через плагин и через код, итоговый файл становится непредсказуемым. Выберите один источник истины. Если нужен контроль в коде, отключите генерацию в плагине или хотя бы проверьте, кто имеет приоритет.
Практические советы по безопасности и производительности
Robots.txt не защищает данные. Если в папке лежит что-то действительно приватное, закрывать это от индексации недостаточно — нужен нормальный контроль доступа, а не директива для роботов. Не рассчитывайте, что запрет в robots.txt скроет чувствительные файлы от людей или ботов, которые robots.txt игнорируют.
С точки зрения производительности полезно не только закрыть мусорные URL, но и сократить генерацию самих дублей. Если на сайте много технических страниц, посмотрите, не проще ли убрать их источник: отключить лишние архивы, ограничить параметры фильтрации, настроить canonical и убрать ненужные публичные endpoints. В этом месте иногда помогает комплексная чистка SEO-настроек, например через Clearfy Pro, если вам нужен набор точечных переключателей без ручной правки каждого шаблона.
Но даже с плагином логика остаётся той же: сначала понять, какие URL создают шум, потом закрыть только их, а затем проверить результат по факту, а не по ощущению.
Что проверить после публикации изменений
- robots.txt открывается без редиректов и ошибок;
- в нём нет запрета на важные разделы сайта;
- поиск по сайту не создаёт индексируемые мусорные URL;
- страницы с параметрами не размножаются без необходимости;
- внешние ресурсы темы не оказались заблокированы;
- в Search Console нет новых сообщений о недоступности важных страниц.
Если после правки всё выглядит нормально, но индекс всё равно не меняется, не ищите проблему только в robots.txt. Проверьте canonical, мета-теги, внутренние ссылки и то, как именно формируются дубли на уровне шаблонов WordPress.