В WordPress robots.txt часто правят «на глаз»: закрывают все подряд, копируют чужой файл или оставляют стандартный вариант, который не учитывает структуру сайта. В итоге в индекс попадают служебные страницы, дубли архивов, параметры поиска и лишние технические URL. При этом слишком агрессивный robots.txt может отрезать от обхода важные разделы и усложнить переобход после изменений.
Ниже — рабочий сценарий: что именно имеет смысл закрывать на типичном WordPress-сайте, как собрать robots.txt без лишних запретов и как проверить, что он действительно помогает, а не мешает.
Когда robots.txt в WordPress нужно трогать в первую очередь
Если сайт уже индексируется, начните не с правки файла, а с диагностики. robots.txt полезен не для «ускорения» как такового, а для управления обходом и отсечения мусорных URL. Особенно это актуально, если в Google Search Console или Яндекс.Вебмастере видны:
- страницы поиска по сайту вида
?s=; - архивы по датам, авторам и тегам, которые дублируют контент;
- служебные URL из
/wp-admin/,/wp-includes/,/wp-json/; - параметры сортировки, фильтров и UTM, если они создают много однотипных адресов;
- страницы вложений, если они не нужны как отдельные посадочные страницы.
Важно понимать границу: robots.txt не удаляет уже проиндексированные страницы из выдачи. Он только ограничивает обход. Если URL уже в индексе, для удаления нужен noindex, редирект или каноникал, а не один только robots.txt.
Что закрывать, а что не трогать
Для обычного WordPress-сайта разумный минимум выглядит так: закрыть технические каталоги, поиск, служебные endpoints и не блокировать CSS/JS, которые нужны для рендеринга. Ошибка многих сайтов — запретить слишком много, включая ресурсы темы и плагинов. После этого поисковик хуже видит страницу и может неверно оценить ее качество.
Базовые запреты для WordPress
Ниже пример аккуратного robots.txt. Он не универсален, но подходит как отправная точка для большинства сайтов без сложной мультиязычности и без нестандартной архитектуры.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /search/
Disallow: /*?s=
Disallow: /*?replytocom=
Disallow: /trackback/
Disallow: /feed/
Disallow: /comments/feed/
Disallow: /author/
Disallow: /tag/
Disallow: /date/
Disallow: /attachment/
Sitemap: https://example.com/sitemap_index.xmlЗдесь есть несколько важных нюансов. /wp-admin/ закрывается почти всегда, но admin-ajax.php обычно оставляют доступным, потому что его используют темы и плагины. Архивы /author/, /tag/ и /date/ имеет смысл закрывать только если они не несут самостоятельной ценности и у вас нет отдельной SEO-логики под них.
Что лучше не закрывать в robots.txt
Не стоит блокировать:
/wp-content/themes/и/wp-content/plugins/целиком, если там лежат CSS и JS, нужные для отрисовки;/wp-json/без понимания последствий — некоторые темы, блоки и интеграции используют REST API;- страницы, которые вы хотите убрать из индекса, если для них нужен
noindexили редирект; - файлы изображений, если они дают трафик из поиска по картинкам.
Если нужно скрыть от индексации конкретные служебные страницы, лучше использовать мета-тег noindex или заголовок X-Robots-Tag, а не надеяться на robots.txt.
Пошаговая настройка robots.txt без лишних рисков
Есть два нормальных пути: через SEO-плагин или вручную на уровне файла в корне сайта. Если у вас уже стоит плагин, который управляет картой сайта и мета-тегами, удобнее править robots.txt там. Если нет — можно создать физический файл robots.txt в корне WordPress.
Шаг 1. Сначала соберите список лишних URL
Откройте отчеты по индексации и выгрузите типы страниц, которые не должны попадать в поиск. Обычно это:
- поиск по сайту;
- архивы авторов на однопользовательском сайте;
- архивы дат, если они не нужны;
- страницы вложений;
- технические параметры сортировки и фильтрации;
- служебные страницы входа и админки.
Если вы не уверены, закрывать ли архивы тегов, сначала проверьте, есть ли у них уникальный контент и трафик. На многих сайтах теги полезнее не закрывать, а привести в порядок: убрать пустые, объединить дубли и добавить нормальные описания.
Шаг 2. Добавьте sitemap и проверьте синтаксис
Карта сайта должна быть указана явно. Это не обязательное требование, но на практике помогает поисковикам быстрее находить нужные URL после правок. Убедитесь, что адрес sitemap совпадает с реальным файлом, который отдает сайт.
Sitemap: https://example.com/sitemap_index.xmlЕсли у вас несколько карт сайта, обычно указывают индексную карту. Не дублируйте десятки ссылок без необходимости.
Шаг 3. Не закрывайте то, что нужно для рендеринга
После правки robots.txt откройте несколько страниц в браузере и проверьте, не блокируются ли CSS и JS в инструментах разработчика. Если поисковый бот не может загрузить стили и скрипты, это иногда приводит к некорректной оценке мобильной версии и структуры страницы.
Как проверить, что robots.txt сработал
Проверка должна быть практической, а не формальной. Сначала убедитесь, что файл доступен по адресу /robots.txt и отдает код ответа 200. Затем проверьте, что нужные запреты действительно применяются.
Проверка через браузер и curl
Самый простой тест — открыть файл в браузере. Для более точной проверки используйте curl:
curl -I https://example.com/robots.txt
curl https://example.com/robots.txtВ ответе должен быть корректный текст файла, без редиректов на HTML-страницу ошибки и без пустого ответа. Если сайт работает через CDN или кеширующий прокси, проверьте, не отдает ли он старую версию robots.txt.
Проверка в инструментах для вебмастеров
Дальше откройте инструменты для вебмастеров и проверьте, как поисковик видит файл. Ищите именно такие признаки:
- важные страницы не помечены как заблокированные;
- служебные URL действительно закрыты для обхода;
- карта сайта читается без ошибок;
- после обновления файла поисковик видит новую версию, а не старый кеш.
Если вы закрыли архивы или поиск, но они уже были в индексе, не ждите мгновенного исчезновения. Сначала поисковик перестанет их обходить, а потом они будут уходить из индекса по мере переобхода или после дополнительных сигналов.
Сравнение подходов: плагин, ручной файл или код
Выбор зависит от того, кто поддерживает сайт и как часто меняется структура. Для небольшого проекта удобнее ручной файл. Для сайта, где SEO-настройки ведутся через плагин, логичнее держать robots.txt в одном месте вместе с картой сайта и мета-данными.
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
| SEO-плагин | Если уже используется для мета-тегов и sitemap | Все настройки в одном интерфейсе | Зависимость от логики плагина |
| Физический robots.txt | Простой сайт, нужен полный контроль | Прозрачность и предсказуемость | Нужно следить за обновлениями вручную |
| Генерация через код | Если нужен динамический файл по условиям | Гибкость | Легко ошибиться и сломать доступ к нужным URL |
Если нужен динамический robots.txt
Иногда файл нужно менять в зависимости от окружения: например, на staging закрывать все от индексации, а на production — отдавать обычный набор правил. В WordPress это можно сделать через фильтр robots_txt. Ниже пример, который добавляет запрет для тестового домена и не трогает основной сайт.
add_filter('robots_txt', function ($output, $public) {
if (defined('WP_ENVIRONMENT_TYPE') && WP_ENVIRONMENT_TYPE === 'staging') {
$output .= "\nUser-agent: *\nDisallow: /\n";
}
return $output;
}, 10, 2);Такой вариант полезен, если у вас несколько окружений и вы не хотите случайно открыть тестовый сайт для индексации. Но не используйте его для сложной логики без необходимости: статический файл проще проверять и сопровождать.
Частые ошибки и как их исправить
- Закрыли весь сайт строкой
Disallow: /. Это допустимо только для staging или временной блокировки. На боевом сайте такая запись отрежет обход почти всего контента. - Запретили CSS и JS в
/wp-content/. Поисковик может не увидеть страницу так, как ее видит пользователь. Оставляйте доступ к ресурсам, которые нужны для рендеринга. - Пытаются убрать страницы из индекса только через robots.txt. Если URL уже в поиске, используйте
noindex, редирект или каноникал. - Указали неверный sitemap. В результате поисковик не находит карту сайта или получает 404. Проверьте точный URL.
- Скопировали чужой robots.txt без анализа структуры сайта. То, что подходит новостному порталу, может навредить блогу или корпоративному сайту.
- Не проверили кеш CDN. После правки старый robots.txt может еще какое-то время отдаваться из кеша.
Практические советы по безопасности и поддержке
Если сайт живет долго, robots.txt лучше хранить как часть технической документации проекта. Зафиксируйте, какие разделы закрыты и почему. Это помогает не потерять логику после смены разработчика или SEO-специалиста.
Для безопасности не полагайтесь на robots.txt как на защиту. Он не скрывает админку, не защищает от сканеров и не ограничивает доступ к файлам. Для этого нужны нормальные права доступа, авторизация, ограничение попыток входа и корректная настройка сервера.
Если вы используете плагин для SEO и чистки дублей, например Clearfy Pro, проверьте, не дублирует ли он ваши ручные правила. Важно, чтобы robots.txt, мета-теги и карта сайта работали согласованно, а не конфликтовали друг с другом.
Что должно получиться после внедрения
После настройки robots.txt у вас должны остаться в обходе только те разделы, которые реально нужны поисковику. Служебные страницы перестанут создавать лишний шум, а карта сайта будет подсказывать поисковым системам приоритетные URL. Проверяйте не только сам файл, но и отчеты по индексации: если количество мусорных страниц не снижается, значит, проблема не в robots.txt, а в архитектуре ссылок, каноникализации или мета-тегах.