Архивы по датам в WordPress часто живут своей жизнью: у них есть страницы по годам, месяцам и иногда по дням, но реальной пользы для пользователя они не дают. На небольших и средних сайтах это обычно превращается в лишние URL, дубли листингов и размывание краулингового бюджета. Если у вас уже есть статьи про архивы авторов, поисковые страницы и sitemap, следующий логичный шаг — разобраться именно с датами.
Когда архивы дат становятся проблемой
Сценарий типовой: в индексе появляются страницы вида /2024/, /2024/08/ или /2024/08/15/, а в них — тот же список записей, что и на главной рубрики или в блоге. Для поисковика это не новая ценность, а ещё одна точка входа в тот же контент. Если архивы не используются как полноценная навигация, их лучше убрать из индекса или отключить совсем.
Как понять, что проблема уже есть
Проверьте несколько вещей:
- в
site:-поиске видны страницы архивов по датам; - в отчётах краулера есть дубли title и description на архивных страницах;
- внутренние ссылки ведут на архивы, хотя пользователь ими почти не пользуется;
- в теме или плагине SEO для архивов не задана уникальная логика заголовков и canonical.
Если архивы дат открыты и индексируются, а контент на них повторяет другие страницы, это уже технический долг. Не всегда критичный, но почти всегда лишний.
Что лучше: отключить, закрыть или оставить
Тут важно не смешивать три разных действия. Полное отключение удаляет архивы из интерфейса и с фронтенда. Закрытие от индексации оставляет страницы доступными пользователю, но убирает их из поиска. Оставить можно только в том случае, если архивы реально помогают навигации и имеют самостоятельную ценность.
| Подход | Когда подходит | Компромисс |
|---|---|---|
| Отключить архивы дат | Блог без нужды в календарной навигации | Нужно убрать ссылки из темы и меню |
| Закрыть от индексации | Архивы нужны посетителям, но не поиску | Страницы остаются доступными по URL |
| Оставить как есть | Новостной или событийный сайт | Нужно следить за canonical, title и дублями |
Пошаговое решение: отключаем архивы дат кодом
Если тема и структура сайта позволяют, самый чистый вариант — убрать сами архивы. Для этого можно использовать фильтры WordPress, не трогая ядро.
<?php
// functions.php дочерней темы или mu-plugin
add_action( 'init', function () {
global $wp_rewrite;
// Убираем правила для архивов по датам.
$wp_rewrite->date_structure = '';
} );
add_filter( 'date_rewrite_rules', '__return_empty_array' );
Но на практике этого недостаточно, если тема продолжает выводить ссылки на архивы в шаблонах. Поэтому дополнительно проверьте:
- виджеты с архивами;
- ссылки в футере и сайдбаре;
- хлебные крошки, если они строятся с датами;
- шаблоны
date.php,archive.phpи их переопределения в теме.
Если вам не нужно полностью отключать архивы, а достаточно убрать их из индекса, используйте SEO-плагин или добавьте noindex для архивов дат. Это безопаснее, если на сайте есть старые ссылки и вы не хотите ловить 404.
Вариант через robots meta
Для архивов дат можно добавить noindex, follow через фильтр. Пример для случаев, когда вы хотите оставить страницу доступной, но не показывать её в поиске:
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_date() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );
Этот вариант полезен, если вы не уверены, что архивы нигде не используются внешними ссылками или внутренней навигацией.
Если используете плагин SEO или чистки сайта
В ряде проектов проще управлять архивами дат через SEO-плагин или через набор настроек для чистки дублей. Например, в Clearfy Pro есть инструменты для отключения лишних архивов и технических страниц, если вам нужен более быстрый путь без ручного кода. Это уместно, когда на сайте много типовых дублей и вы не хотите поддерживать отдельный кусок логики в теме.
Ссылка на продукт, если нужен ориентир: Clearfy Pro.
Но плагин не отменяет диагностику. Если архивы дат уже попали в индекс, нужно проверить, как именно они закрываются: через noindex, canonical или редирект. Для старых URL редирект на релевантную страницу обычно безопаснее, чем просто молча убрать шаблон.
Как проверить, что решение сработало
После внедрения не ограничивайтесь открытием главной страницы. Нужна короткая техническая проверка:
- Откройте несколько URL архивов дат вручную и убедитесь, что они либо недоступны, либо отдают ожидаемый статус.
- Посмотрите исходный код страницы: есть ли
noindex, если вы его добавляли. - Проверьте, не остались ли ссылки на архивы в меню, виджетах и футере.
- Прогоните сайт краулером и сравните количество URL архивов до и после.
- В Search Console проверьте, не растёт ли число страниц с типом «Дубликат» или «Просканировано, но не проиндексировано».
Если вы отключали архивы полностью, убедитесь, что старые URL не возвращают 200 без смысла. Если они больше не нужны, лучше отдать 404 или 410, а не пустую страницу с тем же шаблоном.
Частые ошибки и как их исправить
Отключили шаблон, но ссылки остались
Это самая частая ситуация. Страница архива может исчезнуть из меню, но ссылки на неё продолжают генерироваться в теме или плагине. Решение простое: ищите вызовы get_archives(), виджеты архивов и ручные ссылки в шаблонах.
Поставили noindex, но не убрали canonical
Если canonical указывает на сам архив, поисковик может продолжать воспринимать его как отдельную страницу. Для архивов дат canonical должен быть либо на саму страницу, либо на более общий раздел — в зависимости от вашей структуры. Универсального ответа тут нет, но конфликтов быть не должно.
Сломали навигацию в теме
Некоторые темы используют архивы дат как часть хлебных крошек или боковой навигации. После отключения проверьте шаблоны, где выводятся даты публикации и ссылки на архивы. Если это важная часть UX, лучше оставить архивы доступными, но закрыть их от индексации.
Удалили архивы без редиректов
Если старые URL уже были в индексе или на них есть внешние ссылки, резкое удаление без редиректа создаёт лишние 404. В таких случаях настройте 301 на наиболее близкий раздел: рубрику, блог или главную страницу архива записей.
Практические советы по безопасности и производительности
Архивы дат сами по себе не уязвимость, но они добавляют лишние маршруты и шаблоны, которые нужно поддерживать. Чем меньше технического мусора в теме, тем проще обновлять сайт и тем меньше шансов, что какой-то плагин начнёт конфликтовать с архивной логикой.
Если вы вносите изменения кодом, лучше вынести их в mu-plugin или дочернюю тему, а не править родительскую тему. Так обновления не затрут правки. И не отключайте архивы наугад на новостном сайте: если дата — часть смысла контента, поисковик и пользователь ожидают её увидеть.
Для сайтов, где техническая чистка идёт пакетно, имеет смысл сначала собрать список страниц-дублей, а уже потом отключать архивы, поисковые страницы, лишние feed-URL и другие служебные разделы. Так вы не будете лечить один симптом и ломать другой.