Архивы по датам часто появляются на новостных, блоговых и контентных сайтах автоматически, но в поиске они редко дают пользу. Если у вас уже есть статьи по рубрикам, тегам и авторам, а архивы за месяц или год только создают дубли и размывают релевантность, их лучше убрать из индекса аккуратно: без удаления страниц, без поломки навигации и без лишних 404.
Ниже — рабочий сценарий: как понять, что проблема именно в датах, чем отличается noindex от редиректа, как внедрить решение через код или плагин и как проверить, что поисковики действительно перестали считать такие страницы полезными.
Когда архивы дат становятся проблемой
Сами по себе архивы дат не всегда вредны. Проблема начинается, когда они:
- открываются в индексе и конкурируют с основными страницами сайта;
- содержат слишком мало материалов или дублируют ленту записей;
- создают большое количество тонких страниц, которые не приносят трафик;
- попадают в sitemap или активно перелинкованы из шаблона.
На практике это видно по отчетам Search Console и по логам обхода: поисковик регулярно заходит на архивы, но кликов и показов почти нет. Если сайт зарабатывает на контенте, такие страницы лучше не удалять физически, а просто убрать из индекса и из карты сайта.
Диагностика: как понять, что именно нужно закрывать
Сначала проверьте, какие URL реально существуют. В WordPress архивы дат обычно выглядят так: /2024/, /2024/08/ или /2024/08/15/. Не все темы выводят их одинаково, поэтому ориентироваться лучше на фактические адреса.
Что проверить вручную
- Откройте несколько архивов дат в браузере и посмотрите, есть ли на них полезный контент.
- Проверьте исходный код страницы: есть ли уже
noindexили canonical на другую страницу. - Посмотрите, попадают ли архивы дат в XML-карту сайта.
- Сравните количество таких URL в индексе с количеством переходов из поиска.
Если архивы нужны только для навигации пользователей, но не для SEO, то лучший вариант — оставить их доступными, но закрыть от индексации и убрать из sitemap.
Что выбрать: noindex, редирект или 404
Для архивов дат чаще всего подходит noindex, follow. Это означает, что страница может открываться для пользователя и для обхода ссылок, но не должна попадать в индекс.
| Подход | Когда использовать | Компромисс |
|---|---|---|
noindex, follow | Архив нужен для навигации, но не для поиска | Страница остается доступной, но не ранжируется |
| 301 на главную или рубрику | Архив не нужен вообще | Можно потерять полезные переходы и логику навигации |
| 404/410 | Страница должна исчезнуть полностью | Риск сломать внутренние ссылки и историю обхода |
Если архивы используются в хлебных крошках, календарях или блоках навигации, редирект обычно избыточен. В этом случае безопаснее оставить URL живым и закрыть его от индексации.
Пошаговое решение через код
Надежный способ — добавить noindex для архивов дат на уровне wp_head. Это не требует правки темы, работает предсказуемо и легко откатывается.
<?php
add_action( 'wp_head', function () {
if ( is_date() ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1 );Этот код можно добавить в дочернюю тему или в небольшой mu-plugin. Если у вас уже есть SEO-плагин, проверьте, не задает ли он robots-теги сам. Два разных noindex на одной странице обычно не ломают сайт, но создают путаницу при диагностике.
Как убрать архивы дат из XML sitemap
Если карта сайта генерируется темой или плагином и туда попадают date archives, их лучше исключить отдельно. Универсального фильтра для всех решений нет, поэтому сначала проверьте, чем именно создается sitemap. В популярных SEO-плагинах это настраивается в интерфейсе, а не через код.
Если sitemap формируется вашей темой или кастомным кодом, уберите из списка URL все date archive. Логика простая: если страница закрыта от индексации, она не должна подсказываться как приоритетная для обхода.
Вариант через SEO-плагин
Если вы уже используете плагин для мета-тегов и карт сайта, проще всего настроить правило там. Это особенно удобно, когда на сайте несколько типов архивов и не хочется держать отдельный код для каждого.
Плюс плагина в том, что изменения видны в админке и их проще передать контент-менеджеру. Минус — вы зависите от логики конкретного расширения и его настроек.
Проверка результата после внедрения
После изменений не ограничивайтесь просмотром страницы в браузере. Нужно проверить именно то, что видит поисковый робот.
- Откройте архив даты и посмотрите исходный код: должен быть
noindex,follow. - Проверьте HTTP-ответ через DevTools или
curl: страница должна отдавать200 OK, если вы не делали редирект. - Убедитесь, что URL исчез из XML sitemap.
- В Search Console отправьте страницу на повторную проверку, если она уже была в индексе.
Пример быстрой проверки через консоль:
curl -I https://example.com/2024/08/В ответе вы не увидите meta robots, потому что это HTML-метка, а не заголовок. Поэтому для проверки нужен еще и просмотр исходного HTML:
curl -s https://example.com/2024/08/ | grep -i robotsЕсли архив закрыт правильно, в HTML должен появиться noindex,follow. Если его нет, значит код не подключился, тема переопределяет wp_head или SEO-плагин выводит свои правила позже.
Частые ошибки и как их исправить
Ставят редирект вместо noindex без необходимости
Это частая ошибка на контентных сайтах. Если архивы используются в навигации, редирект ломает логику переходов и может ухудшить поведенческие сигналы. В большинстве случаев достаточно noindex.
Закрывают страницу в robots.txt
Если URL уже заблокирован в robots.txt, поисковик может не увидеть мета-тег noindex и продолжит помнить страницу как отдельный URL. Для уже существующих страниц это плохой вариант. Сначала дайте роботу увидеть страницу и ее мета-правило, а потом при необходимости ограничивайте обход точечно.
Оставляют архив в sitemap
Это создает противоречие: вы говорите поисковику не индексировать страницу, но одновременно подсказываете ее как важную. Уберите такие URL из карты сайта, иначе сигнал получается шумным.
Путают архивы дат с архивами рубрик
Не закрывайте все архивы подряд. Рубрики часто полезны для SEO и структуры сайта, а вот даты — нет. Сначала проверьте шаблон URL и тип архива через условные теги WordPress, чтобы не задеть нужные страницы.
Практические советы по безопасности и производительности
Если вы вносите код вручную, не правьте родительскую тему напрямую. Используйте дочернюю тему или mu-plugin, чтобы обновление не затерло изменения. Для небольших правил это самый безопасный путь.
Если на сайте много технических правок по SEO, чистке дублей и управлению архивами, удобнее держать их в одном месте. В таких задачах часто используют решения уровня Clearfy Pro: он помогает централизованно управлять частью технических настроек WordPress, чтобы не размазывать логику по шаблонам. Ссылку лучше проверять по актуальной документации: Clearfy Pro.
Еще один момент: не добавляйте тяжелые проверки в wp_head, если они не нужны. Для простого условия is_date() это не проблема, но сложные запросы к базе здесь лишние.
Как понять, что решение сработало
Признаки корректной настройки довольно конкретные:
- страницы архивов дат открываются с кодом ответа
200; - в HTML есть
noindex,follow; - URL исчезает из sitemap;
- в Search Console снижается количество страниц этого типа в отчете по индексации;
- поисковик продолжает обходить внутренние ссылки, но не добавляет архив в выдачу.
Если все это выполнено, задача решена правильно: вы не ломаете сайт, но убираете из индекса технически слабые страницы, которые не должны конкурировать с основным контентом.