Как настроить robots.txt в WordPress для открытых и закрытых разделов

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

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

Когда robots.txt действительно нужен

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

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

Что обычно оставляют открытым

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

Диагностика: что проверить до правки файла

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

Посмотрите текущий robots.txt по адресу /robots.txt.
Проверьте, не генерируется ли он автоматически плагином SEO или самим WordPress.
Сравните, какие папки реально существуют на сервере: /wp-content/uploads/, /wp-includes/, каталоги плагинов, служебные подпапки.
Откройте отчёты в Google Search Console: есть ли страницы, которые вы хотите убрать из обхода, но они всё ещё активно сканируются.
Проверьте, не закрыт ли уже нужный ресурс в robots.txt случайно через wildcard или слишком общий Disallow.

Если сайт уже давно живёт с неправильным robots.txt, не меняйте всё сразу. Сначала зафиксируйте текущую версию файла и сделайте копию, чтобы можно было быстро откатиться.

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

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

Способ	Когда подходит	Плюс	Минус
SEO-плагин	Если сайт ведётся через админку и нужен быстрый контроль	Удобно править без доступа к FTP	Зависимость от логики плагина
Файл на сервере	Если нужен прямой контроль и понятный деплой	Прозрачное поведение	Можно случайно перезаписать при обновлении процессов
Код	Если robots.txt должен формироваться динамически	Гибкость	Сложнее сопровождать

Вариант 1: правка через SEO-плагин

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

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

Вариант 2: физический файл robots.txt в корне

Самый предсказуемый способ — положить robots.txt в корень сайта. Для WordPress это обычно означает, что файл будет доступен по https://example.com/robots.txt. Пример базовой, аккуратной конфигурации:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /cgi-bin/

Sitemap: https://example.com/sitemap_index.xml

Этот вариант не пытается закрыть всё подряд. Он оставляет доступ к admin-ajax.php, который нужен многим темам и плагинам, и явно указывает карту сайта.

Вариант 3: динамическая генерация через WordPress

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

<?php
add_filter( 'robots_txt', function( $output, $public ) {
	$output .= "\n# Custom rules\n";
	$output .= "Disallow: /tmp/\n";
	$output .= "Disallow: /test/\n";
	$output .= "Sitemap: https://example.com/sitemap_index.xml\n";

	return $output;
}, 10, 2 );

Такой код лучше размещать в дочерней теме или в небольшом site-specific плагине, а не в functions.php активной темы, если тема может меняться.

Какие разделы закрывать, а какие нет

Для WordPress обычно есть несколько типовых зон риска. Ниже — практическая логика, а не универсальный шаблон.

Чаще всего закрывают

/wp-admin/ — административную часть;
тестовые и временные каталоги, если они случайно доступны публично;
служебные папки плагинов, если они реально открыты и не должны обходиться;
внутренние технические разделы, которые не несут ценности пользователю.

Обычно не закрывают

/wp-content/uploads/ целиком, если изображения должны индексироваться;
CSS и JS-файлы темы;
публичные записи и страницы;
страницы, которые вы хотите убрать из индекса, но при этом поисковик должен видеть их содержимое для корректной оценки — тут нужен noindex, а не robots.txt.

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

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

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

Откройте /robots.txt в браузере и убедитесь, что файл отдаётся с кодом 200.
Проверьте, что в нём нет дублирующихся блоков User-agent с противоречивыми правилами.
В Google Search Console используйте проверку URL или отчёт по страницам, чтобы увидеть, не заблокирован ли важный раздел.
Если вы закрывали служебный каталог, проверьте, что он действительно перестал обходиться, но при этом не исчезли ресурсы, нужные для рендеринга страниц.

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

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

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

Ошибка выглядит так: Disallow: /. После этого робот перестаёт обходить сайт почти полностью. Если это не staging-окружение, такое правило обычно вредно. Исправление простое: убрать общий запрет и оставить только точечные исключения.

Путают robots.txt и noindex

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

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

Иногда в robots.txt по ошибке запрещают целые каталоги /wp-content/ или /wp-includes/. В результате поисковик не видит стили и скрипты, а это мешает оценке страницы. Исправление: убрать общий запрет и закрывать только действительно лишние подпапки.

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

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

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

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

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

Если на сайте много технического мусора, иногда выгоднее сначала навести порядок в генерации URL, а уже потом править robots.txt. В этом случае помогают инструменты для чистки дублей и служебных элементов, например Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином логика остаётся той же: сначала понять, что именно закрываем, потом проверить, как это влияет на обход и индексацию.

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

robots.txt доступен по /robots.txt и отдаёт 200;
нет общего Disallow: /, если это не staging;
не закрыты CSS и JS, нужные для рендеринга;
указана актуальная карта сайта;
нет конфликта между физическим файлом и настройками плагина;
проверено поведение в Search Console;
понятно, что именно должно быть закрыто от обхода, а что — от индексации.

Если после правки нужные страницы всё ещё не индексируются или, наоборот, служебные URL продолжают всплывать в выдаче, проблема, скорее всего, не в robots.txt как таковом. Тогда нужно смотреть на мета-теги, canonical, внутренние ссылки и фактическую структуру сайта.