Архивы дат в WordPress часто создают лишние URL: страницы за месяц, год, день. На небольшом блоге это просто шум, а на активном сайте — источник дублей, размывания внутреннего веса и лишней нагрузки на обход. При этом отключать их вслепую нельзя: если архивы уже дают переходы из поиска или используются в навигации, можно потерять полезный трафик.
Ниже — рабочий сценарий: сначала понять, есть ли от архивов реальная польза, затем закрыть их от индексации или полностью убрать, и после этого проверить, что сайт не потерял нужные страницы и не начал отдавать ошибки.
Когда архивы дат действительно мешают
Проблема обычно проявляется не в коде, а в поисковой выдаче и логах обхода. У сайта появляются URL вида /2026/09/, /2026/09/10/ или похожие, которые дублируют ленту записей и не несут отдельной ценности. Поисковик может индексировать такие страницы, если они доступны и не закрыты явно.
Что проверить в первую очередь
- Есть ли архивы дат в индексе: запросы вида
site:example.com 2026/09. - Показывают ли они осмысленный контент или только список записей.
- Есть ли переходы на эти URL из Search Console или аналитики.
- Не используются ли архивы дат в теме как часть навигации или хлебных крошек.
Если архивы не дают трафика и не нужны пользователю, их лучше закрыть от индексации. Если же на старом сайте они уже ранжируются, безопаснее сначала перевести их в noindex, а не удалять сразу.
Диагностика: закрывать, редиректить или оставить
Перед изменениями стоит выбрать один из трёх вариантов. Они не равнозначны, и ошибка здесь обычно дороже самого кода.
| Вариант | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Оставить как есть | Если архивы реально нужны для навигации и дают трафик | Ничего не ломаете | Дубли и лишняя индексация остаются |
noindex | Если страницы полезны пользователю, но не нужны в поиске | Мягкое решение без удаления URL | Нужно следить, чтобы не было блокировки в robots.txt |
| Редирект на главную или архив рубрики | Если архивы дат вообще не нужны | Убираете URL из обхода и индекса | Нужно аккуратно выбрать целевую страницу |
Для большинства контентных сайтов достаточно noindex, follow на архивы дат. Это не мешает поисковику проходить по ссылкам внутри сайта, но не просит индексировать сам архив.
Пошаговое решение без плагина
Если нужен контроль на уровне темы или мини-плагина, можно добавить noindex только для архивов дат. Такой подход безопаснее, чем править шаблоны вручную в нескольких местах.
1. Добавить мета-тег robots для архивов дат
add_action('wp_head', function () {
if (is_date()) {
echo "<meta name=\"robots\" content=\"noindex,follow\" />\n";
}
});Этот код выводит мета-тег только на страницах архивов по дате. Для поисковиков это сигнал не индексировать страницу, но не обрывать переходы по ссылкам.
2. Убрать архивы дат из sitemap, если они туда попали
Если sitemap генерируется плагином SEO, проверьте его настройки. Часто архивы дат туда вообще не попадают, но если попадают — их нужно исключить в самом генераторе, а не поверх кода. Иначе вы получите URL в карте сайта, которые одновременно закрыты от индексации и продолжают светиться в sitemap.
3. При необходимости сделать редирект
Если архивы дат не нужны совсем, можно отправлять их на более релевантную страницу. Но редирект должен быть осмысленным: на главную, на архив рубрики или на страницу блога, если она есть.
add_action('template_redirect', function () {
if (is_date()) {
wp_redirect(home_url('/blog/'), 301);
exit;
}
});Не делайте массовый редирект всех архивов дат на главную без проверки. Для поисковика это часто выглядит как слабая релевантность, а для пользователя — как потеря контекста.
Если используете плагин SEO или чистки сайта
В ряде случаев проще закрыть архивы дат через настройки SEO-плагина, чем писать код. Это особенно удобно, если на сайте уже есть единая политика для noindex, canonical и sitemap. Если вы используете Clearfy Pro, подобные задачи обычно решаются через интерфейс без правки шаблонов; это полезно, когда нужно централизованно убрать дубли и не трогать тему. Но даже в этом случае важно проверить, что плагин не конфликтует с другими настройками индексации.
Плагинный путь удобен, если сайт ведёт не разработчик, а редактор. Кодовый путь лучше, если нужна предсказуемость и минимум лишней логики.
Как проверить, что решение сработало
После внедрения не ограничивайтесь визуальной проверкой страницы в браузере. Нужно убедиться, что поисковик видит именно то, что вы задумали.
- Откройте архив даты и проверьте исходный код: есть ли
<meta name="robots" content="noindex,follow" />. - Проверьте HTTP-ответ страницы: он должен быть
200, если вы не делали редирект. - Если настроен редирект, убедитесь, что он ведёт на нужный URL и отдаёт
301. - Посмотрите, не остались ли архивы дат в sitemap.
- В Search Console отправьте страницу на повторную проверку после обновления.
Для быстрой проверки можно открыть исходный HTML и поискать robots. Если код добавлен, но в браузере его нет, значит тема или кэш отдают старую версию страницы.
Частые ошибки и как их исправить
Закрыли архивы в robots.txt вместо noindex
Это частая ошибка. Если вы запретили обход в robots.txt, поисковик может не увидеть мета-тег noindex на самой странице. В итоге URL может остаться в индексе как «запрещён к сканированию», но не удалиться корректно. Для мягкого удаления сначала нужен доступ к странице, потом сигнал noindex.
Поставили редирект на все архивы без проверки
Если на сайте есть полезные архивы по годам для старых материалов, массовый редирект может ухудшить навигацию и сломать внутренние ссылки. Сначала проверьте, какие архивы реально используются, и только потом принимайте решение.
Не очистили кэш
После изменения шаблона или хука кэш может продолжать отдавать старую версию страницы. Это касается и серверного кэша, и плагинов кэширования, и CDN. Если мета-тег не появился, очистите все уровни кэша и проверьте страницу в режиме инкогнито.
Оставили архивы в sitemap
Если URL закрыт от индексации, но продолжает лежать в sitemap, это создаёт лишний шум. Поисковик будет регулярно натыкаться на страницу, которую вы сами просите не индексировать. Лучше убрать её из карты сайта полностью.
Практические советы по безопасности и производительности
Если архивов много и сайт давно работает, не меняйте всё сразу на боевом трафике без проверки. Сначала протестируйте на staging-копии или хотя бы на одной категории архивов. Это особенно важно, если у вас кастомная тема, где архивы дат используются в шаблонах и хлебных крошках.
С точки зрения производительности сам по себе is_date() не создаёт заметной нагрузки. Но если вы начинаете обвешивать архивы дополнительной логикой, лучше держать код в отдельном мини-плагине или в functions.php дочерней темы, а не в родительской теме. Так проще откатить изменения и не потерять их при обновлении.
Если задача шире и нужно одновременно убрать дубли, закрыть лишние архивы и подчистить технический мусор, удобнее смотреть в сторону централизованных SEO-инструментов. Но даже тогда базовая проверка остаётся прежней: код ответа, мета-тег, sitemap и Search Console.
Короткий рабочий сценарий
Если нужен минимальный план без лишней теории, действуйте так:
- Проверьте, есть ли трафик и индексация у архивов дат.
- Если трафика нет — добавьте
noindex,follow. - Если архивы не нужны вообще — настройте 301-редирект на релевантную страницу.
- Уберите такие URL из sitemap.
- Очистите кэш и проверьте исходный код страницы.
- Переобойдите проблемные URL в Search Console.
Такой подход обычно решает задачу без лишнего риска: вы не ломаете сайт, не теряете нужные страницы и не оставляете поисковику повод индексировать технический мусор.