Архивы по датам в WordPress часто остаются в индексе просто потому, что их никто не трогал. На небольшом сайте это выглядит безобидно, но на практике такие страницы дают дубли, размывают релевантность и создают лишние точки обхода для поисковых роботов. При этом отключать их «в лоб» нельзя: если архивы уже участвуют во внутренней навигации или на них завязаны хлебные крошки, можно получить побочные эффекты.
Ниже — рабочий сценарий: как понять, нужны ли вам архивы дат, как закрыть их от индексации, когда лучше отдать 404 или 410, и как проверить, что после правки сайт не потерял полезные страницы.
Когда архивы дат действительно мешают
Проблема обычно проявляется не в отчётах «на глаз», а в конкретных сигналах:
- в поиске появляются страницы вида
/2024/05/или/2024/05/12/вместо самих записей; - в sitemap или внутренних ссылках есть архивы, которые не несут самостоятельной ценности;
- в Google Search Console растёт число «Просканировано — не проиндексировано» для датированных архивов;
- на сайте есть новостной формат, но архивы по датам дублируют рубрики и страницы пагинации.
Если архивы дат используются как реальная навигация по контенту, например в медиа-архиве или журнале, их нельзя просто удалять. В этом случае обычно достаточно закрыть их от индексации и оставить доступными для пользователей.
Диагностика: что именно у вас сейчас открыто
Сначала проверьте, какие URL WordPress вообще отдаёт для дат. По умолчанию это архивы по году, месяцу и дню. Их наличие зависит от структуры постоянных ссылок и темы, но сами маршруты обычно существуют всегда.
Быстрая проверка через браузер и Search Console
Откройте несколько типовых адресов:
/2024//2024/05//2024/05/12/
Если страницы открываются с контентом, значит архивы доступны. Дальше проверьте, как они индексируются: в Search Console найдите такие URL по отчёту о страницах или через проверку конкретного адреса.
Проверка заголовков ответа
Если вы уже пытались закрывать архивы через плагин или вручную, важно понять, какой ответ отдаёт сервер. Для этого удобно использовать curl:
curl -I https://example.com/2024/05/Ищите:
200 OK— страница открыта;301/302— есть редирект;X-Robots-Tag— закрытие на уровне заголовка;noindexв HTML-мета-теге — закрытие через разметку.
Если архивы уже отдаются с noindex, но всё равно попадают в индекс, проблема может быть не в настройке, а в том, что поисковик ещё не переобходил страницы или видит на них сильные внутренние ссылки.
Как отключить архивы дат: три рабочих подхода
Выбор зависит от того, что именно вы хотите получить: убрать страницы из индекса, полностью отключить маршруты или оставить их доступными только для пользователей.
| Способ | Что делает | Когда подходит | Компромисс |
|---|---|---|---|
noindex | Страница открывается, но не должна индексироваться | Если архивы нужны для навигации | URL остаётся доступным и может обходиться роботом |
| 404/410 | Страница считается отсутствующей | Если архивы не нужны вообще | Нужно убрать все внутренние ссылки на них |
| Редирект на релевантную страницу | Перенаправляет пользователя и робота | Если есть явная замена, например страница блога | Нужно аккуратно выбрать цель редиректа |
Вариант 1: закрыть архивы дат от индексации
Самый безопасный путь, если архивы используются как навигация. Можно добавить noindex, follow для архивов года, месяца и дня через wp_robots:
add_filter( 'wp_robots', function( array $robots ) {
if ( is_date() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Этот вариант не ломает доступ к страницам, но просит поисковик не включать их в индекс. Для большинства сайтов это лучший старт.
Вариант 2: отдавать 404 или 410 для датированных архивов
Если архивы дат не нужны ни пользователям, ни поиску, можно сделать их недоступными. Важно: не используйте этот способ, если на архивы ведут меню, хлебные крошки или старые статьи.
add_action( 'template_redirect', function() {
if ( is_date() ) {
global $wp_query;
$wp_query->set_404();
status_header( 404 );
nocache_headers();
include get_query_template( '404' );
exit;
}
} );Если вы хотите именно удалить URL из индекса быстрее, иногда используют 410 Gone. Но это имеет смысл только тогда, когда вы уверены, что архивы больше никогда не понадобятся.
Вариант 3: редирект на страницу архива записей или рубрику
Если у вас есть понятная замена, например страница блога или раздел новостей, можно перенаправить архивы дат туда. Это лучше, чем вести пользователя на главную без контекста.
add_action( 'template_redirect', function() {
if ( is_date() ) {
wp_safe_redirect( home_url( '/blog/' ), 301 );
exit;
}
} );Но здесь есть важное условие: цель редиректа должна быть действительно релевантной. Иначе вы просто склеите неродственные страницы и получите плохой пользовательский сигнал.
Пошаговое решение без лишнего риска
- Определите, используются ли архивы дат в навигации и внутренних ссылках.
- Если используются — ставьте
noindex, а не 404. - Если не используются — уберите ссылки на них из темы, виджетов и хлебных крошек.
- После этого либо отдайте 404/410, либо сделайте редирект на релевантную страницу.
- Обновите sitemap, если архивы туда попадали через плагин или кастомный код.
Если вы правите тему или плагин, лучше вынести код в дочернюю тему или в небольшой mu-plugin. Так настройка не слетит после обновления.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Нужны как минимум три уровня контроля.
1. Ответ сервера
Снова проверьте URL архивов через curl -I. Для noindex ищите заголовок X-Robots-Tag или мета-тег в HTML. Для 404/410 должен быть соответствующий статус.
2. Исходный код страницы
Откройте архив в браузере и посмотрите, есть ли в <head>:
<meta name="robots" content="noindex,follow" />Если тег не появился, значит фильтр не сработал или его перебивает SEO-плагин.
3. Поисковая консоль
После переобхода URL должен сменить статус. Для noindex это обычно не мгновенно, поэтому важно смотреть динамику, а не ждать немедленного исчезновения из отчёта.
Частые ошибки и как их исправить
- Закрыли архивы дат, но оставили ссылки на них в меню. Робот и пользователь продолжают ходить по этим URL. Уберите ссылки или замените их на страницу блога.
- Поставили 404 на архивы, которые используются в хлебных крошках. Это ломает навигацию и может ухудшить UX. В таком случае лучше вернуть
noindex. - Ожидали, что
noindexсразу уберёт URL из индекса. Поисковик должен переобойти страницу. На это нужно время. - Сделали редирект на главную. Это частая ошибка: вместо релевантной замены получается мягкая ошибка для пользователя и поисковика.
- Не проверили sitemap. Если архивы туда попали, поисковик будет продолжать их находить. Уберите их из генерации карты сайта.
Безопасность и производительность
Если вы добавляете код вручную, не вставляйте его в файл темы без резервной копии. Ошибка в functions.php может положить сайт в белый экран. Для теста лучше использовать staging-копию или хотя бы временно подключить код через mu-plugin.
Для сайтов, где нужно регулярно чистить дубли, технические архивы и лишние элементы SEO, удобнее использовать профильный инструмент вроде Clearfy Pro: он закрывает часть типовых задач без ручного кода. Но даже в этом случае логику сайта всё равно нужно проверить вручную — особенно если тема нестандартная и архивы используются в навигации.
Что делать, если архивы дат уже в индексе
Если URL уже попали в поиск, не ждите, что одна правка решит всё сразу. Сначала выберите правильную стратегию: noindex, 404/410 или редирект. Затем уберите внутренние ссылки, обновите sitemap и отправьте важные страницы на переобход. Только после этого можно оценивать результат по отчётам Search Console.
В реальной практике самый предсказуемый вариант для большинства сайтов — оставить архивы доступными, но закрыть их от индексации через wp_robots. Это не ломает навигацию и не создаёт лишних ошибок, если архивы уже встроены в структуру сайта.