Служебные страницы WordPress часто попадают в индекс не потому, что сайт «плохо настроен», а потому что по умолчанию движок отдаёт поисковикам архивы авторов, даты, теги, страницы поиска и иногда пагинацию, которая не несёт самостоятельной ценности. В результате в отчётах появляются дубли, а в индексе — страницы, которые не должны конкурировать с основными материалами.
Если задача именно в этом, не стоит лечить её только через robots.txt. Для части URL правильнее использовать noindex, для части — каноникал, а где-то достаточно убрать ссылку из карты сайта и закрыть архив от генерации. Ниже — рабочая схема, которую можно проверить на живом сайте.
Какие страницы обычно нужно закрывать
Сначала важно не смешивать разные типы URL. У них разная логика и разный риск для SEO. Например, архив автора на блоге с одним редактором почти всегда дублирует ленту записей. Страница внутреннего поиска вообще не должна ранжироваться. А архивы рубрик могут быть полезны, если они собраны под отдельные кластеры контента и дают трафик.
Типовые кандидаты на noindex
- страницы внутреннего поиска вида
?s=; - архивы авторов на сайтах с одним автором;
- архивы по датам, если они не используются как посадочные;
- служебные страницы пагинации, если они не несут самостоятельной ценности;
- страницы вложений медиафайлов, если они индексируются отдельно и создают мусор.
Не закрывайте всё подряд. Если рубрика или тег реально собирают трафик и имеют уникальный текст, их лучше доработать, а не прятать от индексации.
Диагностика: что именно уже попало в индекс
Перед правками проверьте, какие URL уже видит поисковик. Самый быстрый способ — поиск по оператору site: и просмотр отчётов в Google Search Console или Яндекс.Вебмастере. Ищите страницы с шаблонными заголовками, пустым контентом и URL, которые не должны ранжироваться.
На стороне сайта полезно посмотреть, как WordPress отдаёт мета-теги и заголовки. Если архив автора открывается с индексируемым <meta name="robots" content="index, follow">, это уже повод менять настройку. Если страница поиска отдаёт 200 OK и полноценный HTML, поисковик может её сохранить, даже если контент там бесполезен.
// Быстрая проверка в шаблоне или через временный mu-plugin
add_action('wp_head', function () {
if (is_search() || is_author() || is_date()) {
echo "\n<!-- diagnostic: special archive detected -->\n";
}
});Этот код не решает проблему, а помогает убедиться, что нужные шаблоны действительно открываются. После теста его нужно убрать.
Пошаговое решение через код
Если у вас есть доступ к теме или небольшому плагину, самый предсказуемый вариант — управлять robots-метками на уровне шаблонов. Для этого не нужен тяжёлый костыль в robots.txt. WordPress умеет отдавать корректные мета-теги через фильтр wp_robots.
1. Закрываем внутренний поиск и архивы автора
add_filter('wp_robots', function (array $robots) {
if (is_search() || is_author()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Такой вариант подходит, если вы хотите оставить переходы по ссылкам внутри этих страниц, но не пускать их в индекс. Для поиска это обычно правильнее, чем блокировка в robots.txt: поисковик увидит запрет на индексацию прямо в HTML.
2. Убираем архивы дат, если они не нужны
add_filter('wp_robots', function (array $robots) {
if (is_date()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Если архивы дат у вас используются как навигация по новостям или журналу, не закрывайте их автоматически. Сначала проверьте, есть ли у них органический трафик и внутренние ссылки.
3. Убираем страницы вложений в основную запись
У медиафайлов часто есть отдельные страницы вложений, которые не нужны в индексе. Лучше настроить редирект на сам файл или на родительскую запись, если она есть. Для этого можно использовать фильтр attachment_redirect не нужно — такого фильтра в ядре нет. Рабочий путь проще: редирект через template_redirect.
add_action('template_redirect', function () {
if (is_attachment()) {
$parent_id = wp_get_post_parent_id(get_the_ID());
if ($parent_id) {
wp_redirect(get_permalink($parent_id), 301);
exit;
}
wp_redirect(home_url('/'), 301);
exit;
}
});Это особенно полезно для сайтов, где медиа-страницы уже накопились в индексе и создают лишние URL.
Если удобнее через плагин
Когда править код не хочется, можно использовать SEO-плагин с настройками архивов и мета-роботов. Но здесь важно понимать компромисс: плагин быстрее в настройке, зато вы зависите от его логики и интерфейса. Код проще контролировать и легче отлаживать.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Точный контроль, минимум лишнего | Нужна проверка после обновлений |
| SEO-плагин | Быстро, без разработки | Часть настроек может конфликтовать с темой или другими плагинами |
robots.txt | Просто закрыть обход | Не гарантирует удаление из индекса, если URL уже известен поисковику |
Если нужен более широкий набор инструментов для чистки дублей и служебных страниц, можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае логику закрытия лучше сверять вручную, а не включать всё подряд.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой. Нужно убедиться, что страница действительно отдаёт нужные сигналы поисковику.
- Откройте страницу поиска, архив автора и архив даты в браузере.
- Посмотрите исходный код и найдите
meta name="robots". - Проверьте HTTP-статус: служебная страница должна открываться, если вы используете
noindex, а не редирект. - В Search Console отправьте URL на проверку и посмотрите, как робот видит страницу.
- Через несколько дней проверьте, исчез ли URL из отчёта по индексированию.
Если вы закрывали страницы вложений через редирект, убедитесь, что старые URL отдают 301, а не 302. Временный редирект не решает задачу накопления дублей.
Частые ошибки и как их исправить
Закрыли URL в robots.txt и ждёте удаления из индекса
Это частая ошибка. Если поисковик уже знает страницу, запрет обхода не равен удалению из индекса. Для служебных страниц обычно нужен noindex в HTML или редирект, если URL вообще не должен существовать.
Ставят noindex на всё подряд
Иногда вместе с архивами автора закрывают рубрики, теги и пагинацию, не проверив их роль в структуре сайта. В итоге падает видимость важных страниц. Сначала смотрите на трафик и внутреннюю перелинковку, потом меняйте мета-роботы.
Делают редирект на главную для всех служебных страниц
Это выглядит аккуратно, но может ломать логику сайта. Для страниц поиска и архивов лучше использовать noindex, а не массовый редирект. Редирект уместен для вложений и совсем ненужных URL.
Не проверяют каноникал
Если шаблон страницы отдаёт неправильный rel="canonical", поисковик может игнорировать часть ваших настроек. После внедрения проверьте, что канонический URL указывает на нужную страницу, а не на сам архив или на случайный адрес.
Практические советы по безопасности и производительности
Если вы вносите код вручную, не правьте functions.php на боевом сайте без бэкапа. Лучше использовать mu-plugin или небольшой отдельный плагин: так настройка не пропадёт при смене темы. Для проверки на staging-сервере это особенно удобно.
Не добавляйте тяжёлые условия в каждый запрос. Фильтр wp_robots и редирект в template_redirect — нормальные точки входа, но только если код короткий и без лишних запросов к базе. Не нужно в этих местах делать дополнительные WP_Query или сложные обращения к метаданным.
Если на сайте много служебных архивов, имеет смысл сначала навести порядок в структуре: убрать лишние теги, пересмотреть авторские архивы, отключить страницы вложений и только потом добивать остатки мета-тегами. Такой подход обычно даёт более чистый индекс, чем точечные запреты без ревизии шаблонов.
Для сайтов, где проблема дублей и служебных страниц уже накопилась, иногда удобнее использовать готовый набор настроек, а не собирать всё вручную. Но даже тогда проверка через исходный код и Search Console остаётся обязательной: именно она показывает, сработало ли решение, а не просто сохранилась ли настройка в админке.