Архивы по датам в WordPress часто появляются сами по себе: /2024/05/, /2024/05/15/ и похожие страницы начинают индексироваться, хотя реальной пользы для сайта не дают. На небольших и средних проектах это обычно приводит к дублям, размыванию веса и лишним страницам в обходе. При этом просто закрыть их в robots.txt — плохая идея: URL останутся в индексе как мусорные, а поисковик не получит нормального сигнала, что с ними делать.
Ниже разберём, как отключить архивы дат аккуратно: что именно выключать, где чаще всего ломают сайт и как проверить, что решение сработало.
Когда архивы дат действительно мешают
Проблема не в самом факте существования архивов, а в том, как они ведут себя на реальном сайте. Если у вас блог с публикациями, архивы по месяцам и дням часто дублируют ленту записей, категории и теги. Поисковик видит несколько страниц с почти одинаковым набором материалов и не всегда выбирает ту, которая нужна вам.
Типичный сценарий:
- страницы архивов дат доступны по ЧПУ и отдают
200 OK; - в теме есть ссылки на архивы в виджетах или хлебных крошках;
- в sitemap попадают страницы, которые вы не хотите продвигать;
- в индексе копятся URL вида
/2023/11/и/2023/11/07/.
Как понять, что это именно ваш случай
Проверьте три вещи: есть ли такие URL в индексе, есть ли на них входящие ссылки внутри сайта и не дублируют ли они другие разделы. Если архивы дат не используются как навигация для пользователей, их почти всегда можно убрать без потери функциональности.
Диагностика: что смотреть до изменений
Сначала убедитесь, что архивы дат не используются в теме или плагинах как обязательный элемент. Иногда разработчики выводят их в сайдбаре, в блоке «Архивы» или в хлебных крошках. Если просто отключить архивы на уровне шаблона, а ссылки останутся, вы получите 404 или цепочку редиректов.
Проверьте:
- есть ли в теме виджет «Архивы»;
- используются ли ссылки на архивы дат в меню или футере;
- отдаёт ли архив дату в заголовке страницы и мета-тегах;
- не включены ли архивы дат в XML sitemap через SEO-плагин или кастомный код.
Если на сайте уже есть трафик на такие страницы, не удаляйте их молча. Лучше сначала перевести их на noindex и только потом убрать из навигации или сделать редирект на более полезный раздел.
Рабочие способы отключить архивы дат
Есть три нормальных варианта: через SEO-плагин, через код в теме или через редирект на более общий архив. Выбор зависит от того, хотите ли вы просто убрать страницы из индекса или полностью закрыть их для пользователей.
| Способ | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Если архивы дат уже управляются через Yoast/Rank Math и нужен быстрый контроль | Не всегда убирает сам URL из навигации |
| Код в теме или плагине | Если нужен точный контроль без лишних настроек | Нужно аккуратно тестировать шаблоны |
| Редирект | Если архивы дат не нужны вообще и есть замена, например категория или главная блога | Нельзя редиректить всё подряд без логики |
Вариант 1: отключить архивы дат через код
Если тема использует стандартные архивы WordPress, можно убрать их из маршрутизации и сразу отправлять пользователя на более полезную страницу. Для этого удобно использовать template_redirect. Пример ниже редиректит архивы по дате на архив записей.
<?php
add_action( 'template_redirect', function () {
if ( is_date() ) {
wp_safe_redirect( home_url( '/blog/' ), 301 );
exit;
}
} );Если у вас нет страницы /blog/, замените адрес на категорию, рубрику или главную страницу записей. Важно, чтобы редирект вёл на реально полезный URL, а не на случайную страницу.
Вариант 2: убрать архивы дат из индекса, но оставить доступными
Иногда архивы нужны пользователям, но не нужны в поиске. Тогда лучше не ломать доступ, а добавить noindex и не выводить их в sitemap. Это более мягкий сценарий, особенно если на архивы есть внутренние ссылки.
<?php
add_filter( 'wp_robots', function ( array $robots ) {
if ( is_date() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Этот вариант не удаляет URL из сайта, но даёт поисковику понятный сигнал не индексировать страницу. Если у вас уже есть SEO-плагин, проверьте, не конфликтует ли он с этим фильтром и не перезаписывает ли robots-мета.
Вариант 3: отключить архивы дат на уровне шаблона
Если в теме есть отдельные шаблоны для архивов, можно отдать 404 или перенаправление только для date archive. Но делать это стоит осторожно: 404 оправдан только тогда, когда вы точно не хотите сохранять старые URL и на них нет внешних ссылок.
<?php
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;
}
} );На практике редирект обычно безопаснее, чем 404, если архивы уже были в индексе. 404 имеет смысл только для совсем новых сайтов или для URL, которые никогда не должны были существовать.
Пошаговое решение без лишних рисков
- Соберите список URL архивов дат из Search Console, логов сервера или внутреннего поиска по сайту.
- Проверьте, есть ли на них внутренние ссылки из меню, виджетов, хлебных крошек и футера.
- Выберите стратегию: редирект,
noindexили 404. - Внесите изменение в дочернюю тему или в небольшой mu-plugin, а не в основной файл темы.
- Очистите кеш страницы, объектный кеш и CDN, если они используются.
- Переобойдите несколько URL вручную и проверьте код ответа.
Как проверить, что всё сработало
После внедрения не ограничивайтесь визуальной проверкой в браузере. Нужны именно технические признаки.
- URL архивов дат открывается с нужным кодом ответа:
301,404или200сnoindex— в зависимости от выбранного сценария; - в исходном коде страницы нет лишнего индексационного сигнала, если вы его отключали;
- страницы архивов не попадают в XML sitemap;
- внутренние ссылки на архивы дат либо удалены, либо ведут на новый адрес;
- в Search Console не растёт число обнаруженных, но не проиндексированных URL этого типа.
Проверить код ответа можно через DevTools, curl или любой HTTP-клиент. Например:
curl -I https://example.com/2024/05/Если вы ставили редирект, убедитесь, что он одинарный и не превращается в цепочку. Если ставили noindex, откройте HTML страницы и проверьте наличие мета-тега robots или заголовка X-Robots-Tag, если он используется на сервере.
Частые ошибки и как их исправить
Закрывают архивы в robots.txt
Это самая частая ошибка. Запрет в robots.txt не удаляет URL из индекса, если он уже известен поисковику. В итоге страница остаётся в базе как «запрещённая к обходу», но не исчезает из выдачи быстро и предсказуемо.
Ставят 404 на все старые даты без анализа
Если на архивы есть внешние ссылки или они уже получили сигналы, массовый 404 может ухудшить поведение сайта в поиске. В таких случаях лучше сначала сделать 301 на ближайший релевантный раздел.
Забывают про sitemap
Даже если вы убрали архивы из шаблона, они могут продолжать попадать в карту сайта через SEO-плагин или кастомный генератор. Тогда поисковик снова и снова видит ненужные URL.
Ломают хлебные крошки и виджеты
После отключения архивов дат иногда остаются ссылки в блоках темы. Пользователь кликает по ним и получает редирект или 404. Это не критично, но создаёт лишний шум и ухудшает UX.
Что учесть для безопасности и производительности
Если вы вносите код вручную, не правьте основной файл темы. Используйте дочернюю тему или отдельный мини-плагин, чтобы обновление темы не затёрло изменения. Для сайтов с кешированием после правки обязательно сбрасывайте не только page cache, но и object cache, если он есть.
Ещё один практический момент: не плодите несколько независимых решений для одной задачи. Если SEO-плагин уже управляет robots-мета и sitemap, не дублируйте ту же логику в functions.php без необходимости. Иначе потом сложно понять, почему одна и та же страница то индексируется, то закрывается.
Если нужен более широкий контроль над дублями, мета-тегами и технической чисткой сайта, иногда удобнее собрать это в одном инструменте, а не держать набор разрозненных сниппетов. Но даже в этом случае логику редиректов и индексации лучше проверять вручную на конкретных URL, а не полагаться на общие настройки.