Служебные архивы в WordPress часто попадают в индекс не потому, что сайт «сломался», а потому что поисковик видит их как обычные страницы: архивы авторов, даты, рубрики, теги, страницы пагинации. Если на сайте мало уникального контента в таких разделах, они начинают конкурировать с основными материалами и размывают качество индексации.
Задача здесь не в том, чтобы «спрятать всё подряд», а в том, чтобы аккуратно разделить страницы на две группы: те, которые должны приносить трафик, и те, которые нужны только для навигации. Для второй группы обычно достаточно noindex на уровне HTML и корректной настройки robots.txt там, где это действительно уместно.
Когда проблема уже видна в поиске
Первый сигнал — в отчёте по индексированию появляются URL вида /author/..., /date/..., /tag/... или служебные страницы поиска. Второй сигнал — в выдаче есть архивы, а нужные статьи ранжируются хуже, чем должны. Третий — в Search Console растёт число страниц без трафика, которые не несут самостоятельной ценности.
Перед правками проверьте, какие именно типы страниц индексируются. Это можно сделать вручную через site:example.com author или через отчёты Search Console. Если архивы уже получают переходы, не закрывайте их механически: сначала оцените, есть ли у них поисковый спрос и уникальный контент.
Что именно стоит закрывать, а что нет
Обычно в зоне риска находятся:
- архивы авторов на сайтах с одним редактором;
- архивы дат, если они не несут самостоятельной ценности;
- страницы внутреннего поиска;
- тонкие теги и рубрики с 1–2 записями;
- страницы пагинации, если они дублируют структуру и не нужны в индексе.
При этом сами записи, важные рубрики и посадочные страницы лучше не трогать. Если закрыть всё подряд, можно потерять полезные точки входа и ухудшить внутреннюю перелинковку.
Диагностика: где именно WordPress отдаёт лишнюю индексацию
В WordPress на индексацию влияют сразу несколько слоёв: тема, SEO-плагин, шаблоны архивов и robots.txt. Поэтому сначала нужно понять, откуда именно берётся проблема. Если на странице автора в HTML уже есть <meta name="robots" content="index,follow">, значит, закрывать нужно на уровне шаблона или SEO-плагина. Если в robots.txt открыт доступ к служебным путям, это отдельная настройка, но она не заменяет meta robots.
Проверка простая: откройте исходный код страницы архива и найдите meta robots. Затем проверьте robots.txt по адресу /robots.txt. Если там есть запрет, но в HTML стоит index, поисковик всё равно может видеть URL как индексируемый, если на него ведут ссылки.
Сравнение подходов
| Подход | Когда подходит | Ограничение |
|---|---|---|
| SEO-плагин | Нужно быстро закрыть архивы без кода | Зависит от плагина и его шаблонов |
| Код в теме/плагине | Нужен точечный контроль | Требует аккуратного обновления и тестов |
| robots.txt | Нужно ограничить обход служебных URL | Не заменяет noindex для уже известных URL |
Пошаговое решение без лишних побочных эффектов
Если у вас есть SEO-плагин, сначала проверьте его настройки архивов. Во многих случаях этого достаточно. Но если нужен контроль на уровне кода, можно добавить фильтры в дочернюю тему или в небольшой mu-plugin.
1. Закрываем архивы авторов и дат через meta robots
Ниже пример, который меняет robots-мета для архивов авторов и дат. Он не трогает записи и страницы сайта.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_author() || is_date() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
unset( $robots['index'] );
}
return $robots;
} );Этот вариант работает на современных версиях WordPress, где используется фильтр wp_robots. Если у вас уже подключён SEO-плагин, проверьте, не переопределяет ли он мета-теги позже по цепочке.
2. Добавляем noindex для страниц внутреннего поиска
Страницы поиска почти всегда создают мусорный индекс, особенно если пользователи вводят одноразовые запросы. Их лучше закрыть отдельно.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['nofollow'] = true;
unset( $robots['index'] );
}
return $robots;
} );Если вам важно сохранить переходы по внутренним ссылкам, nofollow для поиска можно не ставить. Но для большинства сайтов это лишняя страница, и закрытие её от индексации оправдано.
3. Ограничиваем обход служебных URL в robots.txt
robots.txt полезен для снижения лишнего обхода, но его не стоит использовать как единственный способ закрытия от индексации. Он помогает убрать из обхода внутренний поиск, служебные параметры и некоторые архивы, если они не нужны роботам.
<?php
add_filter( 'robots_txt', function( $output, $public ) {
$output .= "\nDisallow: /?s=\n";
$output .= "Disallow: /search/\n";
$output .= "Disallow: /author/\n";
$output .= "Disallow: /date/\n";
return $output;
}, 10, 2 );Здесь важно не переусердствовать. Если у вас есть полезные архивы авторов или даты с реальной ценностью, не закрывайте их в robots.txt без анализа. Для некоторых сайтов лучше оставить доступ роботу, но поставить noindex в HTML.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой. Откройте HTML страницы архива и убедитесь, что в head появился нужный robots-мета-тег. Затем проверьте robots.txt и посмотрите, не блокирует ли он лишние URL.
- архив автора должен отдавать
noindex; - страница поиска должна отдавать
noindex; - важные записи и рубрики не должны получить лишние ограничения;
- в Search Console нужно отправить страницу на повторную проверку после обновления;
- через несколько обходов проверьте, исчез ли URL из отчётов по индексированию.
Если используете кэш, очистите его после правок. Иначе вы можете проверять старую версию HTML и решить, что код не сработал.
Как быстро убедиться, что всё работает
Самый надёжный способ — открыть исходный код страницы и найти строку с robots. Если вы видите noindex, значит, шаблон отрабатывает. Для robots.txt достаточно открыть его в браузере и проверить, что директивы попали в файл без лишних переносов и дублей.
Если у вас есть доступ к консоли, можно проверить заголовки и HTML через curl, но для большинства редакционных сайтов достаточно браузера и Search Console.
Частые ошибки и как их исправить
Самая распространённая ошибка — закрыть страницу в robots.txt и считать задачу решённой. Если URL уже известен поисковику, он может оставаться в индексе без обхода, особенно если на него ведут внешние или внутренние ссылки. В таких случаях нужен именно noindex в HTML.
Вторая ошибка — закрыть архивы, которые реально приносят трафик. Это часто случается с рубриками и тегами: их отключают по шаблону, не посмотрев аналитику. Перед изменениями проверьте, есть ли у архива переходы и уникальное содержание.
Третья ошибка — конфликт с SEO-плагином. Если плагин уже управляет robots-мета, ваш код может не дать ожидаемого эффекта или, наоборот, создать дублирующие директивы. В таком случае оставьте один источник правды: либо настройки плагина, либо код.
Четвёртая ошибка — забыть про кэш страницы и CDN. После внедрения правок старый HTML может ещё какое-то время отдаваться из кэша, и проверка будет вводить в заблуждение.
Практические советы по безопасности и производительности
Если вы добавляете код вручную, лучше делать это в дочерней теме или в небольшом mu-plugin, а не в основной теме. Тогда обновление шаблона не затрёт правки. Для сайтов с несколькими редакторами полезно документировать, какие типы архивов закрыты и почему, чтобы не вернуть их случайно при следующем редизайне.
Если задача шире и вам нужно одновременно убрать дубли, почистить служебные архивы и настроить каноникал, удобнее разделить работу: часть решить настройками SEO-плагина, а часть — точечным кодом. В таких сценариях иногда проще использовать инструменты вроде Clearfy Pro, если нужен набор типовых SEO- и cleanup-настроек без ручной сборки каждого правила, но даже тогда стоит проверять итоговый HTML и robots.txt вручную.
Не закрывайте от индексации всё, что выглядит «техническим» на глаз. В WordPress много страниц, которые кажутся служебными, но реально собирают трафик: отдельные рубрики, авторские страницы в медиа-проектах, архивы по темам. Решение должно опираться на данные, а не на шаблон.