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

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

Какие страницы действительно стоит закрывать

Сначала полезно разделить URL на три группы. Это помогает не мешать индексации контента, который нужен поиску, и не закрывать лишнее.

  • Служебные страницы: внутренний поиск, страницы входа, админка, feed-ленты, технические endpoints.
  • Мусорные или бесполезные для поиска URL: параметры сортировки, фильтры, служебные архивы, если они создают дубли.
  • Страницы, которые не надо закрывать через robots.txt: важные категории, записи, страницы пагинации с полезным контентом, если они реально нужны в индексе.

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

Диагностика проблемы перед правкой

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

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

  • Откройте /robots.txt в браузере и посмотрите текущие правила.
  • Проверьте, нет ли дублирующих блоков User-agent: *.
  • Посмотрите, не закрыт ли случайно /wp-content/uploads/ или важные CSS/JS-файлы.
  • Проверьте, не добавляет ли SEO-плагин свой robots.txt поверх вашего.

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

Рабочий способ: задать robots.txt через WordPress-код

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

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

	// Разрешаем доступ к admin-ajax.php, если он нужен фронтенду.
	$lines[] = 'Allow: /wp-admin/admin-ajax.php';

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

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

Когда лучше не использовать код

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

Сравнение подходов: плагин, код или физический файл

ПодходПлюсыМинусыКогда выбирать
SEO-плагинУдобно править из админкиМожет конфликтовать с другими источниками robots.txtЕсли правит редактор или SEO-специалист
Код через robots_txtКонтроль в репозитории, повторяемостьНужен доступ к коду и понимание приоритетовДля проектов с разработкой и деплоем
Физический файл в корнеПросто и прозрачноЛегко случайно перезаписать при обновлениях или деплоеЕсли хостинг и процесс публикации это позволяют

Пошаговая настройка без лишних рисков

  1. Составьте список URL, которые реально не должны обходиться поисковиком.
  2. Проверьте, не решается ли часть задач через noindex или canonical.
  3. Выберите один источник robots.txt: код, плагин или физический файл.
  4. Добавьте только нужные правила, без «на всякий случай».
  5. Сохраните копию текущей версии файла или фрагмента кода.
  6. Проверьте итоговый /robots.txt в браузере и через инструменты для вебмастеров.

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

Как проверить, что всё сработало

Проверка должна быть не только визуальной. После внедрения откройте https://ваш-домен.ru/robots.txt и убедитесь, что:

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

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

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

Закрывают всё подряд

Ошибка выглядит как Disallow: / или слишком широкий набор правил. В результате поисковик перестаёт обходить даже нужные страницы. Исправление простое: оставьте только конкретные служебные пути и проверьте, не закрыт ли контентный раздел.

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

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

Дублируют правила из SEO-плагина

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

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

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

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

Robots.txt не защищает сайт от атак и не ускоряет сервер напрямую, но помогает сократить обход мусорных URL. Это полезно для больших сайтов, где поисковый бот тратит ресурсы на служебные страницы, фильтры и бесконечные комбинации параметров.

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

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

Добавь в закладки и поделись с друзьями:

⭐⭐⭐⭐⭐
Как использовать REST API WordPress для создания простых приложений
02.10.2026
Оценка производительности WordPress без плагинов: практические способы и примеры
02.10.2026
Как найти и убрать дубли страниц в WordPress
14.08.2026
Как удалить неиспользуемые таблицы в базе данных WordPress
02.10.2026
Как использовать хуки для автоматизации задач в WordPress
02.10.2026
×
Прокачай свой сайт WordPress!

WordPress

-20% на премиум темы и плагины

Создай сайт своей мечты ⋙