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

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

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

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

Отключать такие архивы имеет смысл, если:

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

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

Сначала проверьте, есть ли архивы дат в индексе и как они выглядят для поисковых систем. Не начинайте с удаления шаблонов или массовых правок в robots.txt: сначала нужно понять, откуда берутся URL и кто их генерирует.

Что смотреть в первую очередь

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

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

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

Подход зависит от того, нужен ли вам этот URL вообще. Ниже — практическое сравнение.

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

Пошаговое решение: отключаем архивы дат в WordPress

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

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

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

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

Вариант 2: отключение архивов дат кодом

Если архивы дат не нужны вообще, можно убрать их маршруты и перенаправить посетителей. Добавьте код в functions.php дочерней темы или в небольшой mu-plugin.

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

add_filter('date_rewrite_rules', function ($rules) {
    return [];
});

Первый блок делает 301-редирект для всех архивов дат. Второй убирает rewrite-правила для дат, чтобы WordPress не продолжал обрабатывать такие URL через ЧПУ. Но важно понимать: если у вас уже есть старые ссылки, только редиректа может быть недостаточно — их нужно ещё убрать из меню, хлебных крошек и внутренних ссылок.

Если вам нужно не перенаправление, а только закрытие от индексации, используйте фильтр wp_robots и добавьте noindex именно для архивов дат:

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

    return $robots;
});

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

Что ещё нужно поправить после отключения

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

• меню и футер темы;
• хлебные крошки;
• виджеты с архивами;
• внутренние ссылки в контенте;
• XML-карту сайта, если архивы туда попали;
• каноникал на страницах архива, если они ещё доступны.

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

Проверка результата после внедрения

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

# Проверка редиректа и кода ответа
curl -I https://example.com/2024/05/

# Проверка, что страница больше не отдается как 200 OK
curl -I https://example.com/2024/

Что должно быть в результате:

• для редиректа — 301 Moved Permanently и корректный Location;
• для закрытия от индексации — страница открывается, но в HTML есть noindex;
• в Search Console URL постепенно исчезает из отчётов как индексируемый;
• внутренние ссылки на архивы дат больше не ведут на них напрямую.

Если вы используете noindex, откройте исходный код страницы и убедитесь, что meta robots не конфликтует с настройками SEO-плагина. Иногда один плагин ставит index, а другой — noindex, и в итоге поведение становится непредсказуемым.

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

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

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

Только robots.txt вместо реального отключения

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

Удалили архив, но оставили ссылки в теме

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

Сломали пагинацию

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

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

С точки зрения производительности отключение ненужных архивов полезно: меньше страниц для обхода, меньше мусора в индексе, меньше внутренних переходов к бесполезным URL. Но не стоит превращать это в массовую чистку без бэкапа. Любое изменение rewrite-логики и шаблонов лучше сначала проверить на staging-копии.

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

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

• Проверили, нужны ли архивы дат пользователям.
• Определили: noindex, 301 или полное отключение.
• Убрали ссылки на архивы из меню, футера и виджетов.
• Проверили canonical и meta robots в исходном коде.
• Убедились, что архивы не попали в sitemap.
• Проверили ответ сервера через curl -I или DevTools.
• Сравнили результат в Search Console после переобхода.

Если после изменений архивы дат всё ещё появляются в индексе, не пытайтесь добить проблему дополнительными запретами в robots.txt. Обычно причина в старых внутренних ссылках, sitemap или в том, что страница продолжает отдавать 200 OK без noindex. В таких случаях проще вернуться к диагностике и проверить цепочку целиком: маршрут, шаблон, ссылки и карту сайта.