Настройка robots.txt в WordPress для закрытия от лишнего сканирования

Если сайт на WordPress начал тратить crawl budget на служебные URL, дубли и мусорные параметры, первым делом обычно смотрят на robots.txt. Но здесь легко сделать хуже: закрыть то, что должно индексироваться, или наоборот оставить открытыми лишние пути. Ниже — практический сценарий: что именно ограничивать, как это сделать без лишнего риска и как проверить, что правила работают.

Когда проблема действительно в robots.txt

Не каждый рост числа запросов от ботов лечится через robots.txt. Этот файл помогает управлять сканированием, но не гарантирует удаление URL из индекса. Поэтому сначала стоит понять, что именно происходит.

Типичные симптомы

• в логах или в отчётах Search Console много запросов к /wp-admin/, /wp-json/, параметрам сортировки, внутреннему поиску, архивам с фильтрами;
• в индексе появляются URL с техническими параметрами, которые не нужны пользователю;
• боты часто заходят на страницы, которые не дают полезного контента, но создают нагрузку;
• после изменений в шаблоне или плагинах поисковик продолжает долго обходить старые служебные адреса.

Если проблема именно в индексации дублей, одного robots.txt может быть недостаточно. Для таких случаев обычно нужны ещё noindex, каноникал или правка генерации URL. Но для снижения лишнего обхода файл полезен почти всегда.

Что можно и что нельзя закрывать через robots.txt

Здесь важно не путать технические URL и контентные страницы. Закрывать стоит то, что не несёт самостоятельной ценности и не должно тратить ресурсы бота. Не стоит закрывать страницы, которые должны участвовать в поиске, даже если они выглядят «служебно».

Практический вывод простой: robots.txt — это про экономию обхода, а не про магическое удаление страниц из поиска.

Диагностика: какие URL реально стоит ограничить

Перед правкой файла полезно собрать список адресов, которые боты обходят без пользы. Это можно сделать по логам сервера, по отчётам Search Console или по результатам краулинга сайта.

Что проверить в первую очередь

• /wp-admin/ и служебные скрипты;
• /wp-login.php;
• /wp-json/, если API не нужен для публичного обхода;
• внутренний поиск, если он уже закрыт от индексации и не должен сканироваться;
• URL с параметрами сортировки, фильтров, UTM и других технических меток;
• архивы, которые создают много однотипных страниц без ценности.

Если у вас уже есть отдельные статьи про закрытие пагинации, авторов и поиска от индексации, не пытайтесь дублировать это в robots.txt как универсальное решение. Для индексации и сканирования это разные задачи.

Пошаговая настройка robots.txt в WordPress

В WordPress файл robots.txt может быть виртуальным, если физического файла в корне нет. Это удобно, но иногда мешает, когда нужно точно контролировать содержимое. Поэтому сначала проверьте, как файл сейчас отдаётся.

Шаг 1. Посмотреть текущий robots.txt

Откройте https://ваш-домен.ru/robots.txt и посмотрите, что реально отдаёт сайт. Если там уже есть правила от темы, SEO-плагина или хостинга, не затирайте их без проверки.

Шаг 2. Добавить только нужные директивы

Минимальный безопасный пример для типичного сайта:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /search/

Этот вариант не закрывает весь сайт и не мешает поисковику видеть контентные страницы. Но его нельзя копировать вслепую: если у вас поиск живёт не по пути /search/, а через другой шаблон, правило нужно адаптировать.

Шаг 3. Если есть фильтры и параметры, закрыть только мусорные комбинации

Универсального правила для всех параметров нет. Нельзя просто закрыть любой URL с вопросительным знаком, потому что часть параметров может быть полезной. Лучше ограничивать конкретные шаблоны, которые вы точно не хотите сканировать.

User-agent: *
Disallow: /*?orderby=
Disallow: /*?filter_
Disallow: /*?sort=
Disallow: /*&orderby=

Здесь важно понимать, что поддержка шаблонов зависит от поисковика. Для Google такие правила обычно работают ожидаемо, но это не повод строить на них всю архитектуру. Если фильтры создают много дублей, лучше решать проблему на уровне генерации ссылок и каноникал.

Шаг 4. Не закрывать то, что нужно для рендеринга

Если тема или плагин подгружает стили, скрипты или данные через отдельные пути, проверьте, не попали ли они под правило случайно. Особенно это касается /wp-json/ и AJAX-запросов. Закрыть весь REST API иногда можно, но только если вы уверены, что фронтенд и плагины не зависят от него.

Как добавить robots.txt через код, если нужен контроль в теме или плагине

Если вы не хотите держать правила в админке SEO-плагина или на уровне физического файла, можно отдать содержимое через фильтр robots_txt. Это полезно, когда правила должны собираться динамически.

<?php
add_filter( 'robots_txt', function( $output, $public ) {
	$rules = array(
		'User-agent: *',
		'Disallow: /wp-admin/',
		'Allow: /wp-admin/admin-ajax.php',
		'Disallow: /wp-login.php',
		'Disallow: /?s=',
	);

	return implode( "\n", $rules ) . "\n";
}, 10, 2 );

Такой вариант подходит, если вы точно контролируете окружение. Но для клиентских проектов чаще безопаснее хранить правила в одном месте — либо в физическом robots.txt, либо в SEO-плагине. Иначе легко получить конфликт между темой, плагином и хостингом.

Проверка результата после внедрения

После правки важно не ограничиться открытием файла в браузере. Нужно убедиться, что бот видит именно тот текст, который вы ожидаете, и что правила не ломают обход важных страниц.

Что проверить вручную

• откройте /robots.txt и убедитесь, что файл отдаётся без ошибок;
• проверьте, что нет дублирующихся директив User-agent с противоречивыми правилами;
• убедитесь, что Allow: /wp-admin/admin-ajax.php не потерялся, если он нужен;
• посмотрите, не закрыли ли вы CSS, JS или API, которые используются на публичных страницах;
• протестируйте несколько URL из списка проблемных в инструменте проверки robots.txt, если он доступен в вашей поисковой системе.

Что смотреть в логах и отчётах

Если есть доступ к серверным логам, сравните частоту запросов к закрытым путям до и после изменения. В Search Console полезно посмотреть, уменьшилось ли количество обхода мусорных URL. Резкого эффекта может не быть сразу: поисковики не обновляют поведение мгновенно.

Хороший признак — бот перестаёт активно ходить по заведомо служебным адресам, а важные страницы продолжают сканироваться без ошибок.

Частые ошибки и как их исправить

Закрыли весь сайт одной строкой

Самая грубая ошибка — Disallow: /. После этого поисковик перестаёт нормально обходить сайт, и можно получить проблемы с переобходом, обновлением сниппетов и обнаружением новых страниц. Если это уже произошло, уберите правило и заново проверьте доступность файла.

Пытаются убрать страницы из индекса только через robots.txt

Если URL уже попал в индекс, одного запрета на сканирование может быть недостаточно. Страница может оставаться в поиске без свежего обхода. В таких случаях нужен noindex или корректный редирект/каноникал, в зависимости от задачи.

Закрывают CSS и JS

Такое бывает, когда в правила попадают слишком широкие маски. В результате поисковик не может корректно отрисовать страницу и хуже понимает её содержимое. Если после правки просели результаты проверки мобильной пригодности или рендеринга, первым делом смотрите именно на доступ к статике.

Дублируют правила в нескольких местах

Когда robots.txt генерирует SEO-плагин, а ещё один набор правил добавлен в тему и третий лежит в физическом файле, итоговый текст становится непредсказуемым. Оставьте один источник правды и уберите остальное.

Практические советы по безопасности и производительности

Если цель — не только SEO, но и снижение нагрузки, robots.txt стоит сочетать с другими мерами.

• ограничьте частоту запросов к админке на уровне сервера или через защиту входа;
• уберите генерацию лишних архивов и параметров там, где это возможно;
• проверьте, не создаёт ли плагин десятки технических URL без необходимости;
• для крупных сайтов используйте логи и краулинг, а не только ручную проверку;
• не закрывайте публичные API и ассеты без понимания зависимости темы и плагинов.

Если нужен более системный подход к чистке дублей и технических хвостов, иногда удобнее использовать специализированные инструменты вроде Clearfy Pro: он помогает управлять частью SEO- и технических настроек без ручного редактирования каждого файла. Но даже в этом случае правила всё равно нужно проверять вручную.

Мини-чек-лист перед публикацией изменений

• проверили текущий robots.txt в браузере;
• убедились, что не закрыли важные публичные ресурсы;
• не использовали слишком широкие маски;
• оставили доступ к admin-ajax.php, если он нужен;
• сверили правила с логами или отчётами обхода;
• проверили, что robots.txt не конфликтует с SEO-плагином и темой.

Если после правки бот всё ещё активно ходит по закрытым URL, это не всегда ошибка файла: иногда поисковик просто ещё не пересчитал приоритеты. Но если в файле есть явные конфликты, их лучше исправить сразу, не дожидаясь следующего обхода.