В WordPress часто индексируются не те URL, которые реально нужны сайту: архивы автора, страницы поиска, служебные параметры, вложения медиафайлов, иногда даже технические разделы темы или плагинов. На небольшом сайте это выглядит как «мусор в индексе», на большом — как размывание краулингового бюджета и дубли в отчётах Search Console.
Если задача не в том, чтобы «запретить всё подряд», а в том, чтобы аккуратно убрать лишнее и не задеть важные страницы, начинать нужно с диагностики. robots.txt — это не универсальный замок, а инструкция для роботов. Он помогает ограничить обход, но не всегда гарантирует выпадение URL из индекса, если на них уже есть внешние ссылки или они доступны по другим путям.
Что именно обычно попадает в лишнюю индексацию
У WordPress есть несколько типовых источников мусора. Часть из них создаёт сам движок, часть — тема или плагины. Проблема в том, что владельцы сайта часто закрывают только /wp-admin/ и забывают про остальное.
- страницы поиска вида
/?s=...; - архивы автора на сайтах с одним редактором;
- страницы вложений медиафайлов;
- служебные параметры сортировки и фильтров;
- технические URL плагинов, если они доступны публично;
- дубли с пагинацией, если структура сайта настроена неаккуратно.
Когда robots.txt действительно помогает
Если поисковик ещё не успел активно обходить раздел, запрет в robots.txt экономит crawl budget и снижает шум в логах. Это полезно для страниц поиска, архивов и некоторых служебных путей. Но если URL уже в индексе, одного запрета мало: поисковик может оставить его в выдаче без сниппета, пока не увидит явный сигнал на удаление или noindex.
Диагностика проблемы перед правкой robots.txt
Сначала нужно понять, что именно индексируется и почему. Иначе легко закрыть нужный раздел или, наоборот, оставить в индексе то, что давно мешает.
- Откройте отчёт «Страницы» в Google Search Console и посмотрите, какие URL помечены как обнаруженные, просканированные или исключённые.
- Проверьте, есть ли в индексе страницы поиска, архивы автора и вложения медиафайлов.
- Посмотрите исходный код проблемных страниц: есть ли
meta robotsсnoindex, canonical и корректные ли они. - Проверьте, не генерирует ли тема отдельные архивы или страницы фильтров.
- Оцените, не блокирует ли текущий robots.txt важные CSS/JS-файлы, которые нужны для рендеринга.
Если сайт уже давно в работе, полезно проверить и серверные логи: какие URL чаще всего запрашивают боты. Это помогает отличить реальную проблему от единичных попаданий.
Пошаговое решение: аккуратный robots.txt для WordPress
Базовый файл robots.txt для WordPress не должен быть перегружен. Задача — закрыть только то, что не нужно обходить, и не мешать индексации контента.
1. Сначала сохраните текущую версию
Если robots.txt уже существует в корне сайта, скачайте его и сохраните копию. На хостинге с виртуальным robots.txt изменения могут быть неочевидны, а откат нужен быстро.
2. Добавьте только проверенные запреты
Ниже пример, который подходит для типового сайта без сложных фильтров и без публичного поиска по сайту.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /author/
Disallow: /attachment/
Disallow: /feed/
Disallow: /comments/feed/
Disallow: /trackback/
Disallow: /xmlrpc.php
Sitemap: https://example.com/sitemap_index.xmlЗдесь есть важная оговорка: Disallow: /?s= работает не во всех случаях одинаково, потому что поисковые параметры могут формироваться с разной кодировкой и дополнительными параметрами. Если у вас есть отдельная страница поиска, лучше закрывать её ещё и через noindex на уровне шаблона.
3. Не закрывайте CSS и JS без причины
Старый совет «закрыть всё в /wp-content/» давно вреднее, чем полезнее. Если поисковик не может загрузить стили и скрипты, он хуже рендерит страницу. Это особенно заметно на темах с динамическими блоками и отложенной загрузкой контента.
4. Если нужно убрать страницу из индекса, используйте не только robots.txt
Для уже проиндексированных URL правильнее сочетать несколько сигналов: noindex, canonical на основную страницу, удаление внутренних ссылок и, при необходимости, 404/410 для реально ненужных страниц. robots.txt здесь — вспомогательный инструмент, а не единственный.
Пример: закрываем архивы автора и страницы поиска через код
Если тема или плагин не дают нормально управлять мета-тегами, можно добавить точечную настройку в functions.php дочерней темы или в собственный мини-плагин. Это удобнее, чем править шаблоны вручную после каждого обновления.
add_action('wp_head', function () {
if (is_search() || is_author() || is_attachment()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1);
add_filter('wp_robots', function ($robots) {
if (is_search() || is_author() || is_attachment()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Такой подход лучше, чем пытаться закрыть эти URL только через robots.txt. Поисковик увидит явный сигнал на уровне страницы, а не только запрет на обход.
Сравнение подходов: robots.txt, noindex и удаление страницы
| Подход | Когда использовать | Плюс | Ограничение |
|---|---|---|---|
| robots.txt | Нужно ограничить обход служебных URL | Быстро и просто | Не гарантирует удаление из индекса |
| noindex | Страница доступна, но не должна индексироваться | Явный сигнал поисковику | Страница должна быть доступна для обхода |
| 404/410 | Страница больше не нужна | Чётко удаляет URL из обхода | Нельзя применять к полезным страницам |
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой файла. Нужно убедиться, что поисковик и браузер видят именно то, что вы задумали.
- Откройте
/robots.txtв браузере и проверьте, что файл отдаётся без редиректов и ошибок. - В Search Console используйте проверку URL для нескольких страниц: главной, поиска, архива автора, вложения.
- Посмотрите исходный код страниц и убедитесь, что на служебных URL появился
noindex, если вы его добавляли. - Проверьте, не исчезли ли из индекса важные разделы после правки.
- Сравните логи сервера до и после: уменьшилось ли число запросов к закрытым путям.
Если сайт использует XML-карту сайта, убедитесь, что в ней остались только канонические страницы. Иначе robots.txt будет работать против sitemap: вы запретите обход, но продолжите подсказывать поисковику лишние URL.
Частые ошибки и как их исправить
Закрыли слишком много
Самая частая ошибка — запретить целые каталоги, не проверив, что внутри. Например, Disallow: /wp-content/ может задеть изображения, стили и скрипты. Исправление простое: уберите широкий запрет и оставьте только точечные пути.
Пытаются удалить URL только через robots.txt
Если страница уже в индексе, запрет обхода не всегда решает задачу. Нужен noindex или удаление страницы с корректным кодом ответа. Иначе URL может ещё долго висеть в выдаче без содержимого.
Забывают про canonical
Когда на сайте есть дубли с параметрами, canonical часто важнее robots.txt. Если canonical указывает на сам дубль или на несуществующую страницу, поисковик получает противоречивые сигналы.
Оставляют открытыми страницы вложений
Медиафайлы WordPress часто создают отдельные attachment-страницы, которые почти никогда не нужны в поиске. Если они уже индексируются, лучше либо перевести их на noindex, либо редиректить на файл или родительскую запись, если это соответствует логике сайта.
Практические советы по безопасности и производительности
robots.txt не защищает сайт от атак и не скрывает чувствительные данные. Если в корне есть приватные файлы, их нужно убирать из публичного доступа на уровне файловой системы и прав. Для безопасности это важнее, чем любые директивы для ботов.
С точки зрения производительности полезно держать robots.txt коротким и понятным. Чем меньше в нём экспериментальных правил, тем проще отлаживать поведение поисковых роботов. Если на сайте много технических дублей, иногда выгоднее подключить плагин для чистки SEO-артефактов, например Clearfy Pro, но только после проверки, какие именно URL он закрывает и не конфликтует ли это с темой.
Если вы правите код вручную, делайте это в дочерней теме или в отдельном мини-плагине. Так вы не потеряете изменения после обновления темы и сможете быстро отключить логику, если что-то пошло не так.
Хороший практический критерий простой: после внедрения в индексе остаются только те URL, которые реально должны приносить трафик или обслуживать пользователей. Всё остальное либо закрыто от обхода, либо получает явный сигнал на удаление.