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

Автор: Светлана Данилова | Опубликовано: 07.09.2026

robots.txt в WordPress часто правят «на глаз»: закрывают /wp-content/, добавляют Disallow: / для теста и потом удивляются, почему страницы выпали из сканирования или перестали нормально переобходиться. Проблема в том, что robots.txt не решает индексацию сам по себе, но легко ломает обход важных URL, если использовать его как универсальный фильтр.

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

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

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

Но есть важная граница: если страница уже попала в индекс, один только Disallow не гарантирует её удаление. Поисковик может продолжать показывать URL без сниппета. Для удаления из выдачи нужен другой механизм: noindex, canonical, редирект или удаление страницы.

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

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

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

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

Проверьте три вещи:

какие URL уже есть в индексе и в отчётах Search Console;
какие служебные страницы доступны по прямым ссылкам;
есть ли у сайта отдельные разделы, которые используют admin-ajax.php или REST API на фронтенде.

Если у вас в теме или плагинах есть AJAX-фильтры, не закрывайте всё подряд в /wp-admin/. Иногда фронтенд-скрипты обращаются к /wp-admin/admin-ajax.php, и блокировка ломает фильтрацию, подгрузку контента или формы.

Рабочий вариант robots.txt для WordPress

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

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

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

Что здесь важно:

Allow: /wp-admin/admin-ajax.php нужен, если фронтенд вызывает AJAX;
Sitemap помогает поисковику быстрее находить актуальные URL;
не стоит добавлять десятки Disallow без понимания, что именно они закрывают.

Если нужно закрыть внутренний поиск

Страницы поиска часто создают дубли и пустые выдачи. Если у вас есть URL вида /?s=..., лучше не пытаться закрывать их только robots.txt. Для таких страниц обычно используют noindex, follow на уровне шаблона или SEO-плагина, а robots.txt оставляют для обхода системных разделов.

Если всё же хотите сократить обход мусорных URL, можно добавить правило для параметра поиска, но только если вы понимаете последствия:

User-agent: *
Disallow: /*?s=
Disallow: /*&s=

Это не удалит уже проиндексированные страницы поиска. Оно лишь ограничит обход новых вариантов. Для удаления из выдачи нужен noindex или настройка SEO-плагина.

Сравнение подходов: robots.txt, noindex и canonical

Подход	Что делает	Когда использовать	Ограничение
robots.txt	Запрещает обход	Для техразделов и мусорных URL	Не гарантирует удаление из индекса
noindex	Просит не индексировать страницу	Для дублей, поиска, фильтров, архивов	Страница должна быть доступна для обхода
canonical	Указывает основную версию	Для похожих страниц и параметров	Не работает как жёсткий запрет

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

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

1. Сначала сохраните текущий файл

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

2. Уберите лишнее, а не добавляйте всё подряд

Частая ошибка — копировать чужой robots.txt с длинным списком запретов для плагинов, которых у вас нет. Это не улучшает SEO и только усложняет поддержку. Оставьте только те правила, которые относятся к вашему сайту.

3. Проверьте sitemap

Если у вас есть XML-карта сайта, укажите её в robots.txt. Это не обязательное требование, но полезная практика: поисковик быстрее находит актуальные разделы, особенно после массовых правок контента.

4. Не закрывайте CSS и JS без причины

Старые советы иногда предлагают закрыть /wp-content/ целиком. Так делать не стоит. Поисковику нужны CSS и JS, чтобы корректно рендерить страницу и понимать её структуру. Если закрыть слишком много, можно получить проблемы с рендерингом и неверной оценкой страницы.

Пример: как править robots.txt через PHP, если нет доступа к файлу

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

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

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

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

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

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

Откройте /robots.txt в браузере и убедитесь, что отдаётся актуальная версия.
Проверьте, не закрыт ли случайно важный путь, например /wp-content/uploads/ или URL с AJAX.
В Google Search Console используйте проверку robots.txt и инспекцию URL для страниц, которые должны индексироваться.
Посмотрите серверные логи: если бот продолжает ходить в закрытые разделы, возможно, правила написаны не под тот путь или сайт отдаёт другой robots.txt.

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

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

Закрыли весь сайт через `Disallow: /`

Это самая опасная ошибка. Так делают на этапе разработки и забывают убрать правило перед запуском. В результате поисковик перестаёт обходить сайт, а новые страницы не попадают в индекс. Исправление простое: убрать правило, заново отправить sitemap и проверить доступность важных URL.

Запретили `/wp-content/` целиком

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

Путают robots.txt и noindex

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

Закрывают `admin-ajax.php`

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

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

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

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

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

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

robots.txt открыт по адресу /robots.txt и отдает нужную версию;
/wp-admin/ закрыт, но admin-ajax.php доступен, если нужен;
не закрыты CSS, JS и медиа без причины;
sitemap указан и ведёт на актуальную карту сайта;
внутренний поиск и параметры не блокируют важные страницы;
проверка в Search Console показывает ожидаемое поведение.

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