Если в Search Console растут страницы-дубли, а в индексе болтаются архивы тегов, дат и авторов, проблема обычно не в «плохом SEO», а в том, что WordPress по умолчанию публикует слишком много служебных URL. Их не всегда нужно удалять полностью: часто достаточно правильно расставить noindex, не трогая навигацию и канонические ссылки.
Ниже — рабочий сценарий для типичного сайта на WordPress: что именно закрывать, чем это делать, как не сломать пагинацию и как проверить результат после внедрения.
Когда архивы действительно мешают индексации
Не каждый архив нужно закрывать. Категории часто полезны для структуры сайта, а вот теги, архивы по датам, страницы автора на небольшом сайте и служебные таксономии нередко создают тонкие дубли. Особенно это заметно, если:
- в индексе есть страницы вида
/tag/...,/author/...,/2026/..., но они не дают трафик; - один и тот же контент доступен через категорию, тег и архив автора;
- в Search Console появляются URL с параметрами или пагинацией, которые не должны ранжироваться отдельно;
- тема или плагин выводят на архивных страницах почти тот же текст, что и на страницах записей.
Что обычно закрывают, а что оставляют
Практика такая: категории чаще оставляют индексируемыми, если они реально помогают навигации и содержат уникальный текст. Теги, архивы дат и авторов — кандидаты на noindex, если они не несут самостоятельной ценности. Но это не правило «на все сайты»: у новостных проектов архивы дат могут быть полезны, а у блога-одиночки — почти всегда лишние.
| Вариант | Что делает | Плюс | Минус |
|---|---|---|---|
| Плагин SEO | Добавляет noindex и canonical через интерфейс | Быстро и безопасно | Меньше контроля над логикой |
| Код в теме/плагине | Точечно управляет мета-тегами | Гибко для сложных кейсов | Нужно тестировать после обновлений |
| robots.txt | Запрещает обход | Просто | Не решает индексацию уже известных URL так же надежно, как noindex |
Диагностика проблемы перед изменениями
Сначала посмотрите, какие именно страницы уже попали в индекс и как они выглядят в выдаче. Не начинайте с массового закрытия всего подряд: потом сложно понять, что именно помогло или сломалось.
- Откройте отчеты Search Console по страницам и исключенным URL.
- Проверьте, есть ли в индексе архивы тегов, авторов и дат.
- Посмотрите исходный код проблемной страницы: есть ли там
<meta name="robots" content="noindex,follow">и корректный canonical. - Сравните заголовок и описание архива с заголовками записей: если они почти одинаковые, это типичный дубль.
Если у вас уже стоит SEO-плагин, сначала проверьте его настройки. Часто проблема решается без кода: архивы закрыты не были просто потому, что опция осталась в значении по умолчанию.
Пошаговое решение: закрываем лишние архивы через код
Если нужен точечный контроль, удобнее добавить фильтры в мини-плагин или в functions.php дочерней темы. Ниже пример для WordPress, который ставит noindex,follow на архивы тегов, авторов и дат, но оставляет категории открытыми.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_tag() || is_author() || is_date() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Этот вариант использует стандартный фильтр wp_robots, который есть в современных версиях WordPress. Он предпочтительнее ручной вставки мета-тега в шаблон, потому что не завязан на конкретный файл темы.
Если нужно закрыть только часть архивов
Иногда авторские архивы нужны, а теги — нет. Тогда фильтр можно сузить:
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_tag() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Если у вас SEO-плагин уже добавляет robots-мета, не дублируйте его кодом. Иначе в HTML можно получить два разных набора директив, а поисковик выберет не то, что вы ожидали.
Как не сломать canonical и пагинацию
Самая частая ошибка — закрыть архивы, но оставить на страницах пагинации некорректный canonical. В результате /category/page/2/ может канонизироваться на первую страницу архива, а это нормально не всегда. Для большинства архивов это допустимо, но важно понимать логику: если страница 2 не несет самостоятельной ценности, canonical на первую страницу обычно уместен. Если же у вас длинный каталог материалов и страницы пагинации реально нужны пользователю, не стоит делать из них отдельные посадочные.
Проверьте, что тема не подменяет canonical вручную. В WordPress canonical обычно выводится через ядро или SEO-плагин. Если в шаблоне есть самописный <link rel="canonical">, он может конфликтовать с плагином.
Что проверить в HTML
- на архиве тегов есть
noindex,follow; - canonical указывает на саму страницу архива или на первую страницу, если это ваша осознанная логика;
- на пагинации нет случайного
noindex, если вы хотите, чтобы поисковик проходил по ссылкам дальше; - внутренние ссылки на важные разделы не исчезли из-за слишком агрессивной настройки.
Проверка результата после внедрения
После изменения не ориентируйтесь только на «посмотрел страницу в браузере». Нужна проверка по исходнику и по индексации.
- Откройте архив в режиме просмотра исходного кода.
- Найдите строку с robots-мета и убедитесь, что директива действительно добавилась.
- Проверьте canonical.
- В Search Console отправьте URL на повторную проверку, если страница уже была в индексе.
- Через несколько дней сравните статус URL в отчете по страницам.
Если у вас есть доступ к серверу, можно быстро проверить заголовки и HTML через curl:
curl -s https://example.com/tag/sample/ | grep -iE 'robots|canonical'Для более аккуратной проверки лучше смотреть не только наличие строки, но и итоговое значение. Иногда тема или плагин выводят noindex только на части шаблонов, а на пагинации — нет.
Частые ошибки и как их исправить
Закрыли архивы в robots.txt вместо noindex
Это не одно и то же. Запрет в robots.txt мешает обходу, но не всегда убирает URL из индекса, если поисковик уже знает адрес. Для удаления дублей надежнее использовать noindex.
Поставили noindex на все архивы подряд
Так можно случайно закрыть полезные категории. Если категории дают трафик и помогают навигации, не трогайте их без анализа.
Сломали canonical в теме
Если в шаблоне прописан свой canonical, он может конфликтовать с SEO-плагином. Уберите ручной вывод и оставьте один источник правды.
Ожидали мгновенного исчезновения из поиска
После изменения индексация обновляется не сразу. Это нормальная задержка, а не ошибка настройки. Сначала проверьте исходник, потом статус в Search Console.
Практические советы по безопасности и производительности
Если вы вносите код, не редактируйте родительскую тему напрямую. Используйте дочернюю тему или небольшой mu-plugin. Так настройка не пропадет после обновления.
Для сайтов с большим количеством дублей иногда удобнее часть работы отдать SEO-плагину, а часть оставить в коде. Например, можно использовать Clearfy Pro для чистки служебных дублей и управления частью технических настроек, если это уже вписывается в ваш стек. Но даже в этом случае проверяйте итоговый HTML: важно не название опции, а то, что реально отдает сервер.
Если архивов много, не пытайтесь решить все одним правилом «закрыть всё». Сначала определите, какие страницы реально нужны пользователю, а какие только размывают структуру сайта и расходуют краулинговый бюджет.
Короткий чек-лист перед публикацией изменений
- Проверены архивы тегов, авторов и дат.
- Понятно, какие категории оставляем открытыми.
- В HTML есть один корректный robots-мета, без дублей.
- Canonical не конфликтует с SEO-плагином или темой.
- Пагинация ведет себя так, как вы задумали.
- После правок сделана повторная проверка в Search Console.
Если задача не в том, чтобы «спрятать страницы», а в том, чтобы убрать технический шум из индекса, такой подход обычно дает более предсказуемый результат, чем массовое отключение архивов без анализа.