Как отключить архивы дат в WordPress без лишних дублей и мусорной индексации

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

Ниже — практический разбор: как понять, что именно у вас проблема с date archives, чем отличается отключение от noindex, и как сделать это без поломки сайта.

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

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

Типичный сценарий проблемы выглядит так:

• в поиске появляются страницы вида /2024/05/ или /2023/;
• на архиве мало уникального текста, а список записей совпадает с рубриками;
• в отчётах по индексации растёт число страниц без трафика;
• внутренняя перелинковка уходит на страницы, которые не должны конкурировать с основными посадочными.

Как быстро проверить, есть ли проблема

Сначала посмотрите, существуют ли архивы дат вообще. В большинстве тем WordPress они доступны по адресам формата /2024/ и /2024/05/. Затем проверьте, индексируются ли они:

• поиск в Google с оператором site:example.com 2024/05;
• отчёт «Страницы» в Google Search Console;
• просмотр исходного кода архивной страницы на наличие noindex или canonical;
• логика темы: есть ли в меню или хлебных крошках ссылки на архивы.

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

Что выбрать: noindex, редирект или отключение шаблона

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

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

Пошаговое решение через код

Самый предсказуемый вариант — отключить архивы дат на уровне WordPress и одновременно убрать их из индексации. Для этого удобно использовать дочернюю тему или небольшой mu-plugin, чтобы изменения не потерялись после обновления темы.

1. Запретить архивы дат на уровне запроса

Этот код переводит date archives в 404. Подходит, если вы точно не используете их как часть структуры сайта.

<?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;
    }
});

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

2. Оставить страницу доступной, но закрыть от индексации

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

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

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

3. Убрать ссылки на архивы из темы

Даже если архивы закрыты, не всегда есть смысл светить их в интерфейсе. Проверьте виджеты, меню, блоки в сайдбаре и шаблоны, где тема может выводить архивы автоматически. В классической теме это часто делается через виджет «Архивы» или через шаблонный тег wp_get_archives().

<?php
// Пример: вывод только рубрик вместо архивов дат
wp_list_categories([
    'title_li' => '',
    'show_count' => true,
]);

Если архивы добавлены в меню вручную, удалите их там же. Иначе вы получите странную ситуацию: страница закрыта от индексации, но продолжает быть заметной в интерфейсе.

Диагностика после внедрения

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

• Откройте архив дат в браузере и убедитесь, что он отдаёт 404, если вы выбрали жёсткое отключение.
• Если используете noindex, проверьте исходный код страницы или заголовки на наличие директивы.
• Посмотрите, не остался ли canonical на сам архив, если вы ожидали редирект или 404.
• Проверьте Search Console: статус URL должен измениться после переобхода.

Для быстрой проверки ответа сервера удобно использовать curl:

curl -I https://example.com/2024/05/

Если вы ожидаете 404, в ответе должен быть соответствующий статус. Если выбрали noindex, статус обычно остаётся 200, но в HTML или заголовках должна быть директива для роботов.

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

Закрыли архивы в robots.txt, но они всё равно в индексе

Это частая ошибка. Robots.txt не удаляет уже известный URL из поиска, а только ограничивает обход. Если архив уже в индексе, добавьте noindex или сделайте редирект/404 в зависимости от сценария.

Поставили 404 на архивы, но сломали хлебные крошки

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

Оставили архивы доступными, но забыли убрать ссылки из меню

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

Сделали редирект на главную для всех архивов

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

Практические советы по безопасности и производительности

Любые изменения лучше вносить не в родительскую тему, а в дочернюю или в отдельный mu-plugin. Тогда обновление темы не сотрёт вашу правку. Если сайт работает под кэшем, после изменений очистите не только страницу, но и объектный кэш, если он есть.

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

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

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

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

1. страница отдаёт ожидаемый статус: 404, 301 или 200 с noindex;
2. в исходном коде нет противоречивых директив, например noindex вместе с canonical на сам архив, если вы хотели его убрать;
3. внутренние ссылки на архивы исчезли или остались только там, где это действительно нужно.

Если после переобхода в Search Console архивы всё ещё висят в индексе, это не всегда ошибка. Поисковику нужно время, чтобы обновить данные. Но если через несколько обходов статус не меняется, значит, где-то осталась ссылка, canonical или конфликтующая настройка SEO-плагина.