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

Автор: Полина Ширяева | Опубликовано: 28.09.2026

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

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

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

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

Типичные признаки проблемы

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

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

Диагностика: какие архивы у вас реально открыты

Сначала проверьте, какие URL WordPress вообще отдаёт. На стандартной установке это могут быть:

/YYYY/ — архив по году;
/YYYY/MM/ — архив по месяцу;
/YYYY/MM/DD/ — архив по дню.

Откройте такие адреса вручную и посмотрите:

есть ли на странице список записей;
не стоит ли там noindex уже через SEO-плагин;
какой код ответа отдаёт сервер;
не создаются ли цепочки редиректов.

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

Как отключить архивы дат: рабочие варианты

Есть три нормальных сценария. Выбор зависит от того, хотите ли вы убрать архивы совсем или только закрыть их от поисковиков.

Подход	Что делает	Когда использовать	Минус
SEO-плагин	Ставит `noindex` или отключает архивы	Если уже используете SEO-настройки на сайте	Зависит от конкретного плагина
Код в теме / мини-плагине	Полностью отключает архивы или меняет их поведение	Если нужен точный контроль	Нужно аккуратно тестировать
Редирект на 301	Перенаправляет старые архивы на релевантную страницу	Если архивы уже индексировались	Нужно выбрать правильную целевую страницу

Вариант 1. Закрыть архивы дат через SEO-плагин

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

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

Вариант 2. Отключить архивы дат кодом

Если нужен предсказуемый результат, можно отключить архивы через фильтр date_rewrite_rules не получится, потому что это не стандартный публичный фильтр для такой задачи. Надёжнее использовать проверку запроса и отдавать 404 или редиректить на главную/релевантную страницу. Для большинства сайтов лучше не маскировать проблему, а убрать саму доступность архивов.

Пример: отдаём 404 для архивов по дате. Код можно положить в functions.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 не всегда лучший первый шаг: поисковику нужно время, чтобы переобойти URL и убрать их из выдачи.

Вариант 3. Сделать 301-редирект на более полезную страницу

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

add_action('template_redirect', function () {
    if (is_date()) {
        wp_redirect(home_url('/blog/'), 301);
        exit;
    }
});

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

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

Проверьте, индексируются ли архивы дат сейчас.
Определите, нужен ли вам 404 или 301.
Если используете SEO-плагин, сначала попробуйте его настройки.
Если плагин не решает задачу, добавьте код в дочернюю тему или мини-плагин.
Очистите кеш сайта и CDN.
Переобойдите проблемные URL в Search Console или аналогичном инструменте.

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

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

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

Если выбран 404 — страница должна отдавать код ответа 404, а не показывать контент архива.
Если выбран 301 — должен быть один редирект на целевой URL без цепочки.
Если используется noindex — в HTML должен быть соответствующий meta robots, но сама страница может открываться.
В Search Console проверьте, как робот видит URL после переобхода.

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

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

В ответе смотрите на строку HTTP/1.1 404 или HTTP/1.1 301 и заголовок Location, если настроен редирект.

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

Отключили архивы, но они всё ещё открываются

Чаще всего причина в кеше. Проверьте не только плагин кеша, но и серверный кеш, CDN и браузер. Ещё одна причина — код добавили не в тот файл или в активную тему, которую потом обновили.

Поставили 301 на главную и получили мусорный редирект

Это типичная ошибка. Для архивов дат лучше выбирать страницу, которая логически связана с контентом: блог, раздел новостей, рубрику. Главная подходит не всегда.

Закрыли архивы, но потеряли полезные переходы

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

Сделали noindex, но URL продолжают обходиться

noindex не запрещает обход, он только просит не показывать страницу в поиске. Если цель — убрать сам URL из сайта, нужен 404 или 301.

Что учесть по безопасности и производительности

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

Ещё один практический момент: не добавляйте несколько конфликтующих правил одновременно. Например, если SEO-плагин ставит noindex, а ваш код делает 301, в логике сайта начинается путаница. Сначала выберите один сценарий и протестируйте его до конца.

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

Короткий чек-лист перед публикацией изменений

Проверил, нужны ли архивы дат по смыслу сайта.
Выбрал один сценарий: 404, 301 или noindex.
Добавил правило в дочернюю тему или мини-плагин.
Очистил кеш сайта, сервера и CDN.
Проверил код ответа через curl -I или DevTools.
Убедился, что в индексе не осталось новых дублей.

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