Как настроить robots.txt в WordPress, чтобы не закрыть важный контент

robots.txt в WordPress часто правят «на глаз»: добавляют пару строк из чужой статьи и получают обратный эффект — поисковик перестаёт тратить краулинговый бюджет на мусор, но вместе с ним пропадают важные разделы или ломается обход CSS и JS. На небольшом сайте это заметно не сразу, а на проекте с фильтрами, архивами и служебными страницами ошибка быстро вылезает в индексации.

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

Какая проблема обычно возникает

В WordPress robots.txt чаще всего используют для трёх задач: убрать служебные URL из обхода, не тратить краулинг на дубли и не пускать роботов в технические каталоги. Проблема в том, что многие смешивают Disallow с noindex, закрывают целые директории темы или плагинов и потом удивляются, почему страницы в индексе выглядят «пустыми» или почему Google пишет про проблемы с ресурсами страницы.

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

Диагностика перед правкой robots.txt

Сначала проверьте, что именно вы хотите решить. Для WordPress это обычно один из таких сценариев:

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

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

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

• Есть ли отдельный физический файл robots.txt в корне сайта.
• Не закрыты ли каталоги /wp-content/ или /wp-includes/ целиком.
• Не запрещён ли обход файлов статики: .css, .js, изображений.
• Нет ли конфликтующих директив от нескольких плагинов SEO.

Какой вариант настройки выбрать

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

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

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

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /search/
Disallow: /?s=
Sitemap: https://example.com/sitemap_index.xml

Здесь есть важный нюанс: строка Disallow: /?s= не всегда работает так, как ожидают. Поисковые роботы по-разному трактуют параметры URL, поэтому внутренний поиск лучше дополнительно закрывать на уровне шаблона, а не полагаться только на robots.txt.

Если сайт использует SEO-плагин, проверьте, не создаёт ли он свой robots.txt. В Yoast SEO и Rank Math можно редактировать файл из админки, но после этого не стоит параллельно править физический файл на сервере — получите путаницу, какой вариант реально отдаётся поисковику.

Когда стоит добавить правила для служебных URL

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

Если у вас есть технические страницы, которые не должны обходиться, добавляйте точечные запреты, а не маску на весь каталог. Например, закрыть можно внутренний поиск, страницы входа и админку, но не трогать /wp-content/uploads/, если изображения должны индексироваться и участвовать в поиске по картинкам.

Настройка через код, если нужен контроль в теме или плагине

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

add_filter( 'robots_txt', function( $output, $public ) {
	$lines = array(
		'User-agent: *',
		'Disallow: /wp-admin/',
		'Allow: /wp-admin/admin-ajax.php',
		'Disallow: /wp-login.php',
		'Sitemap: ' . home_url( '/sitemap_index.xml' ),
	);

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

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

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

Проверять нужно не только наличие файла, но и его влияние на обход сайта. Минимальный чек-лист выглядит так:

• откройте https://site.ru/robots.txt и убедитесь, что файл отдается без редиректов и ошибок;
• проверьте, что /wp-admin/ закрыт, а admin-ajax.php доступен;
• убедитесь, что sitemap указан корректно;
• посмотрите в Search Console, нет ли роста ошибок сканирования после правки;
• проверьте, не исчезли ли из обхода CSS и JS, если сайт рендерится клиентом.

Для быстрой проверки можно использовать curl:

curl -I https://example.com/robots.txt
curl https://example.com/robots.txt

Если файл отдаётся, но правила не совпадают с ожидаемыми, ищите конфликт в SEO-плагине, кэше сервера или CDN. Иногда старый robots.txt кэшируется на уровне reverse proxy, и вы смотрите не на актуальную версию.

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

Закрывают весь /wp-content/

Это одна из самых вредных ошибок. Внутри /wp-content/ лежат темы, плагины и uploads. Если запретить каталог целиком, можно сломать рендеринг страниц или убрать из индекса изображения. Закрывать нужно только то, что действительно не должно обходиться, и очень точечно.

Путают robots.txt и noindex

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

Добавляют слишком много правил

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

Оставляют конфликтующие версии файла

Физический robots.txt в корне и генерация через плагин — плохая комбинация. Выберите один источник правды. Иначе при следующем обновлении плагина или темы правила могут измениться без вашего ведома.

Безопасность и производительность: что учитывать

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

С точки зрения производительности полезно не закрывать ресурсы, которые нужны для рендеринга страниц. Если поисковик не видит CSS и JS, он может хуже понимать страницу, а это уже влияет на качество обхода и диагностику в инструментах для вебмастеров.

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

Когда robots.txt лучше не трогать

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

Рабочий ориентир простой: если вы не можете объяснить, зачем нужна каждая строка в robots.txt, файл ещё не готов к публикации.