В WordPress часто путают две разные задачи: запретить обход файла поисковым роботом и убрать страницу из индекса. Из-за этого в robots.txt начинают закрывать то, что должно оставаться доступным для сканирования, а потом удивляются, почему в выдаче остаются дубли, а нужные страницы выпадают. На практике схема проще: служебные URL и мусорные параметры — в robots.txt, а страницы, которые должны открываться, но не индексироваться, — через noindex.
Ниже разберём типичный сценарий: в индексе всплывают страницы поиска, архивы, технические файлы или дубли с параметрами, а в Search Console появляются предупреждения про «проиндексировано, хотя запрещено robots.txt» или «страница просканирована, но не проиндексирована». Это не одна проблема, а несколько разных, и лечатся они по-разному.
Что именно нужно закрывать: сначала диагностика
Перед правками проверьте, какие URL реально создаёт сайт. В WordPress чаще всего лишними оказываются:
- страницы внутреннего поиска вида
/?s=...; - архивы тегов и авторов, если они не несут ценности;
- страницы пагинации архивов, если они плодят тонкие дубли;
- служебные файлы и каталоги:
/wp-admin/,/wp-includes/,/wp-content/plugins/; - URL с параметрами сортировки, фильтров, UTM и прочих трекинговых хвостов;
- медиа-страницы вложений, если они индексируются отдельно от файла.
Проверка начинается не с правки robots.txt, а с факта: откройте несколько проблемных URL в браузере и посмотрите, что это за тип страниц. Если страница должна открываться пользователю, но не нужна в поиске, robots.txt не подходит — поисковик может не увидеть мета-тег noindex, если вы запретите обход раньше.
Когда нужен robots.txt, а когда noindex
| Сценарий | Что использовать | Почему |
|---|---|---|
| Технические каталоги и файлы | robots.txt | Их не нужно обходить и индексировать |
| Страница должна открываться, но не попадать в индекс | noindex | Робот должен увидеть директиву на самой странице |
| Дубли с параметрами | каноникал + настройка параметров + иногда robots.txt | Один robots.txt не решает проблему дублей |
| Поиск по сайту | noindex,follow | Страница полезна пользователю, но не для выдачи |
Если у вас уже есть SEO-плагин, сначала проверьте его настройки. Многие плагины умеют ставить noindex на архивы, теги, автора и страницы поиска без ручного кода. Но robots.txt всё равно часто приходится править отдельно, особенно если нужно убрать обход служебных путей.
Пошаговое решение для WordPress
1. Приведите robots.txt к минимально безопасному виду
В WordPress robots.txt можно отдавать виртуально или как физический файл в корне сайта. Если файл уже существует, проверьте, не закрывает ли он лишнее. Слишком агрессивные правила ломают сканирование CSS, JS и изображений, а это уже влияет на рендеринг и оценку страницы поисковиком.
Базовый вариант для большинства сайтов выглядит так:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /trackback/
Disallow: /feed/
Disallow: /comments/feed/
Это не универсальный шаблон, а отправная точка. Например, Disallow: /feed/ нужен не всегда: если у вас есть внешние подписчики на RSS, закрывать фиды без понимания последствий не стоит. А вот /wp-admin/admin-ajax.php закрывать нельзя, если тема или плагины используют AJAX на фронтенде.
Если нужно закрыть конкретный каталог или набор параметров, делайте это точечно. Не пишите в robots.txt всё подряд, особенно если не уверены, как именно формируются URL.
2. Для страниц, которые должны открываться, добавьте noindex
Если архив тегов, авторов или результаты поиска должны быть доступны пользователю, но не нужны в индексе, ставьте noindex на уровне HTML. В WordPress это можно сделать через SEO-плагин или кодом. Кодовый вариант полезен, когда нужно закрыть только часть шаблонов.
Пример для functions.php или небольшого mu-plugin:
add_action('wp_head', function () {
if (is_search() || is_tag() || is_author()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1);
Этот вариант простой, но его нужно использовать аккуратно. Если у вас уже стоит SEO-плагин, не дублируйте мета-теги из двух источников. Иначе в HTML можно получить два разных robots-указания, а это лишний шум для поисковика и для отладки.
3. Уберите дубли через canonical, а не только через запрет обхода
Если проблема не в служебных страницах, а в дублях с параметрами, одного robots.txt мало. Например, URL с ?utm_source= или сортировкой могут вести на ту же страницу, но поисковик всё равно увидит отдельный адрес. В таких случаях нужен канонический URL и, по возможности, нормализация параметров на уровне шаблона или плагина.
Проверяйте, что на странице есть корректный rel="canonical" и он указывает на чистый URL без лишних параметров. Если каноникал уже есть, но ведёт на неправильную страницу, сначала исправьте источник генерации — тему, плагин или SEO-настройку.
4. Если нужно закрыть вложения, отключите отдельные attachment-страницы
У медиафайлов в WordPress есть отдельные страницы вложений, и именно они часто создают мусор в индексе. Пользователь кликает на картинку, а вместо файла получает пустую или почти пустую страницу attachment. Для SEO это обычно бесполезный дубль.
Самый безопасный путь — редиректить attachment-страницы на сам файл или на родительскую запись. Если у вас нет готового решения в SEO-плагине, можно сделать это кодом:
add_action('template_redirect', function () {
if (is_attachment()) {
$parent = wp_get_post_parent_id(get_the_ID());
if ($parent) {
wp_safe_redirect(get_permalink($parent), 301);
} else {
$file = wp_get_attachment_url(get_the_ID());
if ($file) {
wp_safe_redirect($file, 301);
}
}
exit;
}
});
Это не закрывает индексацию напрямую, но убирает отдельную тонкую страницу из обхода и выдачи. Для сайта с большим количеством изображений это часто практичнее, чем пытаться вручную управлять каждым attachment URL.
Как проверить, что решение сработало
После правок не ограничивайтесь просмотром файла robots.txt в браузере. Нужна проверка на трёх уровнях: ответ сервера, HTML страницы и поведение в Search Console.
- Откройте
/robots.txtи убедитесь, что файл отдается без ошибок и содержит только нужные директивы. - Проверьте проблемный URL в браузере: страница должна открываться, если вы рассчитываете на
noindex. - Посмотрите исходный код страницы и найдите
<meta name="robots" content="noindex,follow" />. - В Google Search Console используйте проверку URL и убедитесь, что робот видит актуальную версию страницы.
- Проверьте, не остались ли в индексе старые URL через поиск по сайту или оператор
site:— это не точный инструмент, но он помогает увидеть явные хвосты.
Если вы закрывали служебный каталог в robots.txt, убедитесь, что это действительно каталог, а не путь, который нужен для фронтенда. Например, не стоит бездумно закрывать /wp-content/ целиком: там лежат стили, скрипты и изображения, которые поисковик должен уметь обходить.
Частые ошибки и как их исправить
Закрыли robots.txt то, что должно быть noindex
Классическая ошибка: страницу поиска или архив закрывают в robots.txt, а потом жалуются, что она всё равно висит в индексе. Если робот уже знает URL, запрет обхода не всегда помогает быстро убрать его из выдачи. Для страниц, которые должны открываться, но не индексироваться, нужен noindex и нормальная внутренняя перелинковка.
Перекрыли CSS и JS
Иногда в robots.txt по привычке закрывают слишком широкий путь, и в результате поисковик не может нормально отрендерить страницу. Это особенно заметно после правок темы или установки кэширующего плагина. Если в отчётах появляются проблемы с рендерингом, проверьте, не заблокированы ли файлы в /wp-content/themes/ и /wp-content/plugins/.
Сделали два источника robots-мета
Если SEO-плагин уже выводит noindex, а вы добавили свой код в wp_head, в HTML может появиться конфликт. В лучшем случае поисковик выберет одну директиву, в худшем — вы сами не поймёте, почему страница ведёт себя нестабильно. Оставьте один источник управления: либо плагин, либо код.
Поставили noindex на важные страницы
Это случается после массовых настроек архивов и таксономий. Перед сохранением проверьте, что не затронуты записи, страницы услуг, категории с трафиком и посадочные страницы. Если сомневаетесь, сначала применяйте правило к одной таксономии или одному шаблону и проверяйте результат на тестовом URL.
Практика безопасности и производительности
Чистка индекса — это не только SEO. Чем меньше мусорных URL обходят роботы, тем меньше лишней нагрузки на сайт и логов на сервере. Но не стоит пытаться решить всё через robots.txt: это не средство защиты, а подсказка для роботов.
Для безопасности полезно помнить несколько вещей:
- robots.txt не скрывает конфиденциальные данные, он только просит роботов не ходить по пути;
- если файл или каталог должен быть приватным, закрывайте его на уровне сервера или авторизации;
- не прячьте от индексации страницы с полезным контентом, если они должны ранжироваться;
- после изменений проверьте кэш плагина и серверный кэш, чтобы старый robots.txt не продолжал отдаваться.
Если на сайте много технических дублей, иногда проще один раз навести порядок в SEO-настройках, чем вручную править robots.txt. В таких задачах помогают плагины, которые умеют отключать архивы, чистить служебные страницы и управлять мета-тегами без самописного кода. Например, у Clearfy Pro есть набор функций для удаления дублей и чистки сайта: https://wpshop.ru/plugins/clearfy.
Если нужен более точный контроль, оставляйте код только для узких случаев: кастомные типы записей, нестандартные архивы, attachment-страницы или специфические параметры URL. Всё остальное лучше решать на уровне шаблона, SEO-плагина и нормальной структуры ссылок.