Архивы по датам в WordPress часто остаются включенными по умолчанию, хотя на большинстве сайтов они не несут самостоятельной ценности. Проблема не в самих URL, а в том, что они создают дублирующие страницы, размывают краулинговый бюджет и иногда плодят тонкие архивы с несколькими записями. Если у вас новостной сайт, блог с редкой публикацией или проект, где контент сгруппирован по рубрикам и тегам, архивы дат обычно можно отключить или закрыть от индексации.
Когда архивы дат действительно мешают
Сначала стоит понять, что именно вы хотите исправить: убрать страницы из индекса, скрыть их из меню и поиска по сайту, или полностью отключить генерацию архивов. Это разные задачи. Если просто поставить noindex, URL останутся доступны, но поисковики перестанут считать их посадочными страницами. Если удалить архивы на уровне шаблона или редиректом, нужно аккуратно сохранить поведение старых ссылок и не сломать переходы из внешних источников.
Типичные признаки проблемы
- в индексе есть страницы вида
/2024/05/или/2024/05/15/; - в отчётах Search Console появляются дубли и страницы с низкой ценностью;
- архивы дат доступны, но содержат 1–2 записи и не дают полезной навигации;
- тема или SEO-плагин уже выводят архивы в sitemap, хотя они не нужны;
- внутренние ссылки ведут на архивы дат из хлебных крошек, виджетов или блоков автора.
Диагностика: что именно у вас сейчас включено
Перед изменениями проверьте, как WordPress формирует архивы дат и кто управляет их индексацией. На практике конфликт бывает в одном из трёх мест: тема, SEO-плагин или кастомный код. Если вы начнёте с удаления шаблона, а потом обнаружите, что sitemap всё ещё содержит архивы, придётся откатывать часть правок.
Проверьте URL и ответ сервера
Откройте несколько архивов дат вручную и посмотрите, что возвращает сервер. Если страница отдаёт 200 OK, значит архив живой. Если стоит редирект на главную или рубрику, это уже другой сценарий. Для быстрой проверки удобно использовать:
curl -I https://example.com/2024/05/Ищите статус-код, заголовок Location и наличие X-Robots-Tag, если он задаётся на уровне сервера или плагина.
Посмотрите, есть ли архивы в sitemap
Если у вас установлен SEO-плагин, проверьте XML-карту сайта. Иногда архивы дат попадают туда автоматически, даже если вы уже закрыли их от индексации. Это не критично, но создаёт лишний шум для поисковиков. Сначала определите источник: генерация темы, SEO-плагин или отдельный плагин для sitemap.
Что лучше: noindex, редирект или полное отключение
Универсального ответа нет. Если архивы уже в индексе и на них есть внешние ссылки, резкое удаление может дать лишние 404. Если архивы почти не используются, достаточно закрыть их от индексации и убрать из sitemap. Если же это мусорные URL без ценности, можно отключить их генерацию и сделать 301-редирект на более релевантную страницу.
| Подход | Когда подходит | Компромисс |
|---|---|---|
noindex |
Архивы нужны пользователям, но не поиску | URL остаются доступными |
| 301-редирект | Архивы не нужны вообще | Нужно выбрать целевую страницу |
| Отключение через код | Нужен чистый контроль над шаблонами и ответами | Требует аккуратного тестирования |
Пошаговое решение через код
Если задача — убрать архивы дат из публичной части сайта, самый надёжный путь — обработать запросы на уровне template_redirect и вернуть 301 на релевантную страницу. Для сайтов с уже существующим трафиком это обычно безопаснее, чем просто удалять шаблон архива.
Вариант 1: редирект архивов дат на блог или рубрику
Добавьте код в functions.php дочерней темы или в небольшой mu-plugin. Пример ниже редиректит все архивы дат на страницу блога. Если у вас нет страницы записей, замените URL на рубрику или другую подходящую страницу.
<?php
add_action( 'template_redirect', function () {
if ( is_date() ) {
wp_safe_redirect( home_url( '/blog/' ), 301 );
exit;
}
} );Этот вариант простой, но он не решает вопрос индексации старых URL, если поисковик уже успел их обойти. Поэтому после внедрения проверьте, что старые адреса действительно отдают 301, а не 200.
Вариант 2: закрыть архивы дат от индексации
Если архивы нужны посетителям, но не поисковым системам, лучше оставить страницу доступной и добавить noindex, follow. В WordPress это можно сделать через фильтр wp_robots:
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_date() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Такой подход не ломает навигацию и не требует удаления шаблонов. Но он работает только если тема и SEO-плагин не переопределяют robots meta своими настройками.
Вариант 3: убрать архивы дат из sitemap
Если ваш SEO-плагин умеет исключать типы архивов из карты сайта, используйте его настройки. Это предпочтительнее, чем писать отдельный код, потому что плагин обычно уже знает, как формировать sitemap без конфликтов. Если же архивы попадают в sitemap через кастомную логику, проверьте, не добавляет ли их тема вручную.
Как проверить, что решение сработало
После правок не ограничивайтесь визуальной проверкой в браузере. Нужно посмотреть и HTTP-ответ, и мета-теги, и карту сайта.
- Откройте старый URL архива даты и убедитесь, что он отдаёт
301или содержитnoindex. - Проверьте исходный код страницы: в
<head>должен быть корректный robots meta. - Посмотрите sitemap и убедитесь, что архивы дат там больше не перечисляются.
- В Search Console отправьте проверку URL и посмотрите, как робот видит страницу.
- Если был редирект, проверьте цепочку: не должно быть
301 -> 301 -> 200.
Быстрая проверка через curl
curl -I https://example.com/2024/05/
curl -s https://example.com/2024/05/ | grep -i robotsПервая команда покажет статус и редирект, вторая — есть ли robots meta в HTML, если страница не редиректится.
Частые ошибки и как их исправить
На этой задаче чаще всего ломают не сам архив, а сопутствующие вещи: крошки, sitemap и каноникал. Ниже — ошибки, которые встречаются регулярно.
Редирект на главную без логики
Это плохой вариант, если у вас есть близкая по смыслу страница. Поисковик и пользователь теряют контекст. Лучше вести на страницу блога, рубрику или архив записей, если он реально полезен.
Закрыли архивы, но оставили их в sitemap
Так бывает, когда robots meta меняют в коде, а sitemap генерирует SEO-плагин отдельно. В итоге поисковик получает противоречивые сигналы. Исправление простое: исключите архивы из sitemap тем же инструментом, которым он создаётся.
Сломали хлебные крошки
Некоторые темы строят крошки через архивы дат. После редиректа ссылка в крошках может вести на несуществующий или перенаправленный URL. Проверьте шаблон крошек и при необходимости замените дату на рубрику или уберите этот уровень из навигации.
Поставили noindex, но не убрали внутренние ссылки
Это не ошибка само по себе, но если архивы дат больше не нужны, лучше убрать на них явные ссылки из виджетов и блоков. Иначе вы продолжите тратить обход на страницы, которые не дают пользы.
Практические советы по безопасности и производительности
Если вы правите архивы через код, не вносите изменения напрямую в родительскую тему. Используйте дочернюю тему или mu-plugin, чтобы обновление не затёрло правки. Для небольших сайтов это особенно важно: один аккуратный файл с фильтром проще сопровождать, чем править шаблоны в нескольких местах.
Если на сайте уже стоит плагин для технической чистки, например Clearfy Pro, проверьте, не умеет ли он закрывать архивы, управлять robots meta и чистить лишние страницы без ручного кода. Это не обязательное решение, но для типовых задач оно может сократить количество кастомных правок. Смотрите только на реальные настройки, а не на обещания в описании плагина: вам нужны управление индексированием, мета-тегами и дублями, а не лишняя обвязка.
Когда лучше не отключать архивы дат
Есть сайты, где архивы по датам полезны: новостные проекты, журналы, личные блоги с регулярной публикацией, архивы событий. Если пользователи реально переходят по датам и ищут материалы за конкретный период, не стоит рубить их полностью. В таком случае достаточно настроить noindex, убрать их из sitemap и проверить, что они не конкурируют с рубриками.
Если после внедрения вы видите, что старые URL продолжают получать трафик, не спешите удалять их окончательно. Сначала посмотрите источники переходов, статус в Search Console и поведение внутренних ссылок. В технической оптимизации лучше один раз проверить цепочку целиком, чем потом чинить последствия по частям.