Архивы дат в WordPress часто появляются автоматически, даже если сайт не ведёт новостную ленту и не использует страницы по месяцам. В итоге в индексе оказываются слабые страницы вида /2024/05/ или /2024/05/12/, которые дублируют контент, размывают внутренний вес и мешают поисковику сосредоточиться на нормальных разделах сайта.
Удалять такие архивы «в лоб» опасно: можно получить 404 на старых ссылках, сломать хлебные крошки, потерять часть переходов из поиска и случайно закрыть не только архивы, но и полезные страницы. Ниже — рабочий сценарий: как понять, что именно у вас индексируется, как отключить архивы дат без лишних побочных эффектов и как проверить результат.
Когда архивы дат действительно мешают
Проблема обычно проявляется не в админке, а в поиске и логах. На сайте могут существовать:
- архивы по году, месяцу и дню с пустым или почти пустым содержимым;
- страницы архивов, которые повторяют список записей без уникальной ценности;
- URL, которые попали в sitemap или были проиндексированы раньше;
- внутренние ссылки на даты из темы, хлебных крошек или виджетов.
Если сайт не новостной и пользователю не нужно листать записи по датам, такие страницы обычно не нужны. Но прежде чем что-то отключать, стоит проверить, как именно они используются.
Диагностика: что именно нужно убрать
Сначала определите, какие архивы у вас есть и где они участвуют.
Проверьте структуру URL
В WordPress архивы дат зависят от настроек постоянных ссылок и темы. Чаще всего встречаются такие варианты:
/2024/— архив года;/2024/05/— архив месяца;/2024/05/12/— архив дня.
Если вы видите их в выдаче или в sitemap, это уже повод проверить, откуда они берутся.
Посмотрите, есть ли ссылки на архивы в теме
Иногда архивы дат не нужны поиску, но на них всё равно ведут ссылки из шаблонов. Проверьте:
- боковую колонку и футер;
- хлебные крошки;
- шаблоны
archive.php,date.php,functions.php; - виджеты «Архивы» и похожие блоки в редакторе.
Если архивы используются как навигация для посетителей, их лучше не удалять, а ограничить индексирование. Если они нигде не нужны, можно отключить их полностью.
Что выбрать: редирект, noindex или полное отключение
| Вариант | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Оставить и закрыть от индексации | Архивы нужны пользователям, но не поиску | Не ломает старые ссылки, проще внедрить | Страницы остаются в обходе, но без индексации |
| Редирект на рубрику или главную | Архивы не нужны вообще | Убирает мусорные URL из пользовательского пути | Нужно аккуратно выбрать целевую страницу |
| Полностью отключить шаблон и ссылки | Архивы нигде не используются | Чистая структура, меньше лишних страниц | Можно сломать тему, если она рассчитывает на эти архивы |
Для большинства сайтов безопаснее начать с запрета индексации и только потом, если всё стабильно, убирать сами URL.
Пошаговое решение через код
Если у вас есть доступ к теме или небольшому mu-plugin, можно отключить архивы дат на уровне WordPress. Это надёжнее, чем надеяться на настройки темы, которые могут исчезнуть после обновления.
1. Отключите ссылки на архивы дат в шаблонах
Если тема выводит архивы дат через стандартный виджет или собственный блок, сначала уберите саму ссылку из интерфейса. Для виджета «Архивы» в классической теме его просто не добавляйте. Если ссылка генерируется в коде, ищите вызовы вроде get_month_link() или get_day_link().
Пример: если в теме есть собственный вывод архива по месяцам, его можно убрать или заменить на рубрики.
<?php
// Пример: не выводим архивы дат в сайдбаре, если они не нужны.
if ( function_exists( 'wp_get_archives' ) ) {
// wp_get_archives( array( 'type' => 'monthly' ) );
}
?>2. Перенаправьте архивы дат на более полезные страницы
Если архивы уже в индексе или на них есть внешние ссылки, лучше сделать 301-редирект. Ниже пример для functions.php или mu-plugin: он перенаправляет архивы года, месяца и дня на главную. В реальном проекте чаще логичнее вести на рубрику или страницу архива, если она есть.
<?php
add_action( 'template_redirect', function () {
if ( is_date() ) {
wp_safe_redirect( home_url( '/' ), 301 );
exit;
}
} );Если у вас есть подходящая страница-замена, подставьте её URL вместо главной. Главное — не отправлять все архивы на случайную страницу, которая не соответствует интенту пользователя.
3. Закройте архивы от индексации, если они нужны для навигации
Иногда архивы дат нужны как вспомогательная навигация. Тогда лучше не редиректить их, а добавить noindex, follow. Это можно сделать через SEO-плагин, если он умеет управлять архивами, или кодом в wp_head.
<?php
add_action( 'wp_head', function () {
if ( is_date() ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
} );Этот способ рабочий, но у него есть минус: если SEO-плагин тоже выводит robots meta, можно получить конфликт. Тогда оставьте управление индексацией в одном месте.
4. Уберите архивы из sitemap, если они туда попадают
Если sitemap генерируется SEO-плагином, проверьте его настройки архивов. Если архивы дат не нужны, они не должны попадать в карту сайта. Если sitemap создаётся вручную или через кастомный код, исключите date-архивы из списка URL.
Важный момент: не закрывайте sitemap целиком ради одной группы URL. Нужно убрать только ненужные архивы, а не ломать индексацию всего сайта.
Как проверить, что решение сработало
После внедрения не ограничивайтесь просмотром страницы в браузере. Проверьте несколько уровней.
- Откройте старый URL архива даты и убедитесь, что он отдаёт 301 или
noindex, если это было задумано. - Посмотрите исходный код страницы и найдите
meta name="robots". - Проверьте sitemap: архивов дат там быть не должно, если вы решили их убрать.
- Пройдитесь по внутренним ссылкам темы и убедитесь, что они не ведут на отключённые архивы.
- Если используете Search Console, отправьте на переобход только те URL, которые реально изменились.
Для быстрой проверки редиректа удобно использовать curl:
curl -I https://example.com/2024/05/В ответе вы должны увидеть 301 и заголовок Location с целевым URL. Если вместо этого отдаётся 200, значит правило не сработало или его перебивает другой код.
Частые ошибки и как их исправить
Редирект на главную без логики
Это самая частая ошибка. Формально проблема решена, но пользователь и поисковик попадают на нерелевантную страницу. Лучше редиректить на рубрику, страницу архива записей или другой близкий по смыслу раздел.
Сразу ставят noindex и забывают про ссылки
Если архивы продолжают активно использоваться в теме, они остаются в обходе, а пользователь всё равно на них попадает. В результате вы не решаете вопрос структуры сайта, а только прячете его от индексации.
Конфликт с SEO-плагином
Если плагин уже управляет robots meta, а вы добавили свой код в wp_head, на странице может появиться несколько директив. Это не всегда критично, но лучше оставить один источник правды. Проверьте настройки плагина и удалите дублирующий код.
Отключили архивы, но забыли про кэш
После изменения шаблонов или редиректов старые версии страниц могут ещё какое-то время отдаваться из кэша. Очистите серверный кэш, кэш плагина и CDN, если он есть. Иначе проверка покажет старый результат, хотя код уже исправлен.
Практика безопасности и производительности
Если вы вносите изменения через functions.php, делайте это аккуратно. Для небольших правок лучше использовать mu-plugin: он не зависит от темы и не исчезнет после обновления шаблона. Это особенно важно, если сайт обслуживается не одним разработчиком.
Ещё один полезный момент: не плодите отдельные правила для каждого типа архива, если можно обработать их одним условием is_date(). Чем меньше точек отказа, тем проще поддержка.
Если на сайте много технического мусора — дубли, лишние архивы, пустые таксономии, служебные страницы — имеет смысл смотреть на комплексную чистку. В таких сценариях иногда удобнее использовать Clearfy Pro, если нужен набор типовых SEO- и технических настроек без ручного разбрасывания по теме. Но даже с плагином всё равно стоит понимать, какие URL вы закрываете и зачем.
Мини-чек-лист перед публикацией изменений
- Понял, нужны ли архивы дат пользователям.
- Проверил, есть ли на них внутренние ссылки.
- Выбрал один сценарий: редирект, noindex или полное отключение.
- Убрал архивы из sitemap, если они больше не нужны.
- Очистил кэш и проверил ответ сервера.
- Посмотрел исходный код страницы и robots meta.
- Проверил, что не сломались хлебные крошки и навигация.
Если после изменений старые архивы продолжают индексироваться, не спешите добавлять новые костыли. Сначала проверьте, не остались ли на них ссылки в меню, шаблоне или sitemap. В WordPress такие вещи почти всегда находятся в одном из этих трёх мест.