Как закрыть от индексации архивы дат в WordPress без потери обхода сайта

Автор: Юлия Романова | Опубликовано: 22.08.2026

Архивы дат в WordPress часто появляются сами по себе: /2024/08/, /2024/08/15/ и похожие URL. На небольших блогах они редко дают пользу, зато легко создают дубли, размывают релевантность и забирают краулинговый бюджет на страницы, которые не нужны в поиске. При этом полностью удалять архивы не всегда удобно: на них могут вести старые ссылки, а внутри сайта они иногда участвуют в навигации.

Ниже — рабочий сценарий: как понять, нужны ли вам архивы дат, как закрыть их от индексации, что делать с уже проиндексированными страницами и как проверить, что всё сработало.

Когда архивы дат действительно мешают

Проблема не в самих URL, а в том, что архивы дат часто дублируют контент, который уже есть в рубриках, тегах или на главной ленте. Поисковик видит несколько страниц с очень похожим набором записей и не всегда выбирает ту, которая вам нужна.

Типичные признаки

в индексе есть страницы вида /2023/, /2023/11/, /2023/11/07/;
в Search Console появляются страницы без трафика, но с обходом;
в выдаче всплывают архивы вместо рубрик или самих записей;
на сайте есть плагин или тема, которые автоматически выводят ссылки на архивы по датам.

Если архивы дат используются как реальная навигация для пользователей, например в новостном проекте, решение может быть мягче: закрыть от индексации, но оставить доступными для обхода. Если они не нужны вообще, лучше убрать ссылки и при необходимости отдать 404 или 410 только после проверки логики сайта.

Диагностика: что именно индексируется

Сначала проверьте, какие архивы дат уже попали в поиск. Самый простой способ — поиск по сайту и Search Console. Если доступа к консоли нет, можно посмотреть HTML-код страниц архива и понять, стоит ли там noindex или каноникал указывает на другую страницу.

Что проверить вручную

Откройте несколько URL архивов дат в браузере.
Посмотрите исходный код страницы и найдите meta name="robots".
Проверьте, есть ли в шапке rel="canonical".
Убедитесь, что архивы не закрыты случайно через robots.txt без необходимости.

Если страница закрыта в robots.txt, но уже проиндексирована, поисковик может не увидеть noindex на самой странице. Для уже существующих URL это слабое решение. Надёжнее сначала отдать страницу с noindex, а затем при необходимости убрать её из выдачи через переобход.

Как закрыть архивы дат от индексации

Есть три нормальных подхода: через SEO-плагин, через код темы или через комбинацию обоих вариантов. Если у вас уже стоит плагин для SEO, проще использовать его настройки. Если нужен точечный контроль без лишнего интерфейса — добавьте фильтр в functions.php дочерней темы или в свой мини-плагин.

Способ	Плюс	Минус
SEO-плагин	Быстро, без кода	Зависимость от интерфейса и настроек плагина
Код	Точный контроль	Нужно аккуратно тестировать после обновлений темы
robots.txt	Просто запретить обход	Не решает проблему уже проиндексированных страниц

Вариант 1: через SEO-плагин

Если вы используете плагин с настройками архивов, найдите раздел, где можно отключить индексацию архивов дат. В большинстве случаев вам нужен именно noindex, follow, а не полная блокировка обхода. Так поисковик не будет держать архив в индексе, но сможет проходить по ссылкам на записи.

Если плагин позволяет отключить сами архивы дат, проверьте, не ломает ли это хлебные крошки, ссылки в теме и страницы пагинации. После изменения настроек обязательно откройте HTML-код страницы и убедитесь, что robots-мета реально поменялась.

Вариант 2: через код

Если нужен контроль без плагинов, можно добавить noindex для архивов дат через фильтр wp_robots. Это современный и безопасный способ для WordPress 5.7+.

<?php
add_filter( 'wp_robots', function( array $robots ) {
	if ( is_date() ) {
		$robots['noindex'] = true;
		$robots['follow']  = true;
	}

	return $robots;
} );

Этот вариант не трогает остальные типы страниц. Он сработает только на архивных страницах по дате: год, месяц и день. Если у вас есть отдельная логика для архивов автора или рубрик, её лучше держать отдельно, чтобы не смешивать правила.

Если нужно убрать архивы дат совсем

Иногда архивы не должны существовать вообще. Тогда можно не только закрыть их от индексации, но и убрать ссылки из шаблона или виджетов. Делайте это только после проверки, что на архивы нет полезного трафика и внутренних переходов.

<?php
add_action( 'template_redirect', function() {
	if ( is_date() ) {
		wp_safe_redirect( home_url( '/' ), 301 );
		exit;
	}
} );

Редирект на главную — не универсальное решение. Если архивы дат уже имеют внешние ссылки, иногда лучше перенаправлять их на ближайшую рубрику или страницу архива записей. Иначе пользователь попадёт не туда, куда ожидал.

Пошаговое решение без лишнего риска

Сделайте резервную копию файлов темы или подготовьте дочернюю тему.
Определите, нужны ли архивы дат как навигация.
Если нужны — оставьте доступ, но добавьте noindex, follow.
Если не нужны — уберите ссылки из темы и добавьте редирект или отдачу 404/410 по согласованной логике.
Проверьте HTML-мета robots и canonical на нескольких URL.
Отправьте важные страницы на переобход в Search Console, если они уже были в индексе.

Как проверить, что решение сработало

Проверка должна быть не формальной, а по факту ответа сервера и HTML. Откройте архив даты и посмотрите исходный код. В нём должно быть что-то вроде noindex, follow. Если вы делали редирект, убедитесь, что сервер отдаёт именно 301, а не 302.

Мини-чек-лист проверки

страница архива открывается без фатальных ошибок;
в исходном коде есть noindex для архивов дат;
canonical не указывает на случайную страницу;
внутренние ссылки на записи продолжают работать;
пагинация рубрик и главная лента не изменились неожиданно;
в Search Console страница помечается как исключённая или неиндексируемая после переобхода.

Если используете кэш-плагин или серверный кэш, очистите кэш после правок. Иначе вы можете смотреть на старую версию HTML и решить, что код не работает.

Частые ошибки и как их исправить

Закрыли архив в robots.txt и ждёте исчезновения из индекса

Это распространённая ошибка. Запрет обхода не равен удалению из индекса. Если URL уже известен поисковику, он может оставаться в выдаче без актуального контента. Для таких страниц сначала нужен noindex или редирект.

Ставят `noindex` на всё подряд

Иногда фильтр пишут слишком широко и случайно закрывают рубрики, поиск по сайту или даже главную. Проверяйте условие is_date() и тестируйте на нескольких типах страниц.

Редиректят архивы на главную без анализа

Это ухудшает пользовательский сценарий, если ссылка ведёт на конкретный период. Лучше сначала понять, есть ли у архивов входящий трафик и внешние ссылки. Если есть, редирект должен быть осмысленным.

Забывают про кэш

После изменения robots-мета старый HTML может продолжать отдаваться из кэша. Очистите кэш страницы, объектный кэш и, если нужно, CDN.

Безопасность и производительность

Если вы вносите правки кодом, не редактируйте родительскую тему напрямую. Используйте дочернюю тему или мини-плагин. Так обновление темы не затрёт изменения. Для точечных SEO-правок это особенно важно: такие изменения редко должны жить в шаблоне навсегда.

Если на сайте много технических дублей, архивы дат — только часть картины. Имеет смысл отдельно проверить архивы авторов, пагинацию, теги и страницы поиска. В некоторых проектах удобнее собрать всё в одном SEO-инструменте, чтобы не держать набор разрозненных правок. Например, для чистки дублей и технических настроек можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy.

Если после внедрения архивы дат всё ещё появляются в поиске, не спешите менять стратегию. Сначала проверьте, не остались ли старые URL в sitemap, внутренних ссылках или в кэше. В WordPress технические проблемы часто живут не в одном месте, а в связке темы, плагина и кэширования.

⭐⭐⭐⭐⭐