robots.txt в WordPress часто настраивают слишком грубо: закрывают всё подряд или, наоборот, оставляют в индексе служебные URL, которые создают мусор в обходе и мешают поисковым роботам. На практике задача обычно проще: убрать из сканирования технические разделы, но не навредить важным страницам, файлам и карте сайта.
Если у сайта уже есть дубли, лишние архивы, служебные endpoints или следы плагинов, robots.txt помогает сократить пустой crawl budget. Но это не инструмент для полного скрытия страниц из индекса: если URL уже известен поисковику, одного запрета в robots.txt может быть недостаточно. Поэтому важно понимать, что именно вы закрываете и зачем.
Когда robots.txt действительно нужен
Сначала стоит отделить технические URL от контента. В WordPress к ним обычно относятся:
/wp-admin/и служебные файлы админки;/wp-includes/и статические системные ресурсы;- страницы поиска по сайту, если они генерируют много пустых или мусорных запросов;
- служебные endpoints плагинов, которые не должны обходиться роботами;
- внутренние каталоги, если они случайно доступны публично.
При этом /wp-content/uploads/ закрывать обычно не нужно: изображения и медиа часто должны индексироваться отдельно, особенно если они дают трафик из поиска по картинкам.
Диагностика: что именно мешает индексации
Перед правкой файла полезно посмотреть, какие URL уже попадают в обход. Это можно сделать в Google Search Console, в логах сервера или через обычный поиск по сайту в выдаче. Если в индексе всплывают служебные страницы, проверьте, не открыты ли они для обхода и не отдают ли они 200 OK там, где должен быть запрет или редирект.
Что проверить вручную
- открывается ли
/robots.txtбез ошибок; - нет ли в нём конфликтующих правил;
- не закрыт ли случайно
/wp-content/uploads/или важные CSS/JS; - не блокирует ли файл карту сайта;
- не дублируются ли правила, если SEO-плагин уже генерирует robots.txt.
Если используется SEO-плагин, сначала проверьте его настройки. Частая ошибка — редактировать физический файл на сервере, а потом удивляться, что в ответе сайта показывается другой robots.txt, сгенерированный плагином.
Пошаговая настройка robots.txt в WordPress
Надёжный подход — начать с минимального набора правил и добавлять только то, что действительно нужно. Для большинства сайтов достаточно закрыть админку, системные каталоги и оставить карту сайта открытой.
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xmlЕсли на сайте есть отдельные технические разделы, добавляйте их точечно. Например, для внутреннего поиска WordPress можно закрыть URL с параметром ?s= не через robots.txt, а через настройку индексации страниц поиска или через noindex. robots.txt не умеет надёжно управлять параметрами в том виде, как это часто ожидают.
Как добавить robots.txt без ручного редактирования файлов
В WordPress можно отдать robots.txt через фильтр robots_txt. Это удобно, если вы не хотите зависеть от FTP-доступа или если конфигурация должна жить в теме или небольшом mu-plugin.
<?php
add_filter( 'robots_txt', function( $output, $public ) {
$lines = array(
'User-agent: *',
'Disallow: /wp-admin/',
'Disallow: /wp-includes/',
'Allow: /wp-admin/admin-ajax.php',
'Sitemap: https://example.com/sitemap_index.xml',
);
return implode( "\n", $lines ) . "\n";
}, 10, 2 );Этот вариант подходит, если вы уверены, что другой плагин не перезаписывает файл. Если SEO-плагин уже управляет robots.txt, лучше не дублировать логику в коде, иначе получите две разные версии правил в разных местах админки.
Сравнение подходов: файл, плагин или код
| Подход | Когда подходит | Минус |
|---|---|---|
Физический robots.txt | Простой сайт, есть доступ к корню | Легко потерять контроль при миграции или кэшировании |
| SEO-плагин | Если уже используется плагин для мета-данных и sitemap | Нужно следить, не генерирует ли он лишние правила |
Код через robots_txt | Нужна централизованная логика в теме или mu-plugin | Требует аккуратного сопровождения |
Если у вас уже стоит плагин для SEO и чистки дублей, вроде Clearfy Pro, проверьте, не создаёт ли он собственный robots.txt или отдельные правила для архивов и технических страниц. В таком случае лучше выбрать один источник правды, а не смешивать несколько.
Проверка результата после внедрения
После правки не ограничивайтесь открытием файла в браузере. Проверьте три вещи: что robots.txt отдается с нужными правилами, что нужные страницы не закрыты случайно и что карта сайта доступна для обхода.
- Откройте
https://site.ru/robots.txtи убедитесь, что правила совпадают с ожидаемыми. - Проверьте, не закрыт ли
Sitemap:и доступен ли URL карты сайта. - В Search Console отправьте проверку URL для нескольких страниц: главной, статьи и служебного раздела.
- Если закрывали технический каталог, посмотрите логи сервера или отчёт обхода через несколько дней.
Важно: если URL уже был в индексе, запрет в robots.txt не удалит его мгновенно. Для удаления из выдачи обычно нужен noindex, редирект или возврат 404/410 в зависимости от сценария.
Частые ошибки и как их исправить
Закрыли всё подряд
Самая частая проблема — правило Disallow: /. После него робот не может обходить вообще ничего, включая CSS, JS и карту сайта. Если это уже произошло, уберите правило и проверьте, не осталось ли его в кэше CDN или на уровне сервера.
Спрятали важные файлы статики
Иногда по ошибке закрывают /wp-content/ целиком. Это ломает рендеринг страниц и может ухудшить понимание сайта поисковиком. Закрывать нужно только конкретные служебные каталоги, а не весь контентный слой.
Ожидали удаления из индекса только через robots.txt
Если страница уже известна поисковой системе, robots.txt лишь ограничивает обход. Для удаления из индекса используйте noindex, редирект на релевантную страницу или статус 404/410, если контент действительно удалён.
Конфликт с SEO-плагином
Когда один плагин генерирует карту сайта, а другой — robots.txt, легко получить несогласованные правила. Решение простое: оставьте генерацию в одном месте и проверьте итоговый ответ сервера, а не только настройки в админке.
Практические советы по безопасности и производительности
robots.txt не защищает от атак и не скрывает чувствительные данные. Если каталог должен быть закрыт по-настоящему, используйте авторизацию, ограничения на уровне сервера или удалите доступ к файлам. Для производительности же полезно не закрывать лишнее, а убрать только то, что реально создаёт пустой обход.
Если сайт большой, после правки robots.txt стоит посмотреть, не уменьшилось ли количество бессмысленных запросов к служебным URL в логах. Это особенно заметно на проектах с большим количеством архивов, фильтров и технических страниц.
И ещё один практический момент: не меняйте robots.txt одновременно с массовыми редиректами и удалением страниц без плана проверки. Иначе будет сложно понять, что именно повлияло на индексацию.
Мини-чек-лист перед публикацией
- robots.txt открывается по прямому URL;
- не закрыта карта сайта;
- не заблокированы CSS и JS;
- служебные каталоги закрыты точечно, а не целиком;
- если нужен запрет на индексацию, выбран не только robots.txt, но и правильный HTTP/HTML-механизм;
- в Search Console проверены несколько типовых URL.
Если нужен более комплексный контроль дублей, архивов и служебных страниц, удобнее сначала привести в порядок правила индексации, а уже потом править robots.txt. В WordPress это почти всегда даёт более предсказуемый результат, чем попытка закрыть всё одним файлом.