Архивы по датам и месяцам часто остаются включёнными по умолчанию, хотя на реальном сайте они редко дают полезный трафик. Проблема не в самих архивных страницах, а в том, что они создают дополнительные URL с повторяющимся списком записей, размывают внутреннюю перелинковку и иногда попадают в индекс как слабые страницы.
Если у вас новостной сайт, блог с редкими публикациями или проект, где публикации не должны группироваться по календарю, архивы дат обычно проще отключить. Ниже — как понять, что они действительно мешают, как убрать их без поломки темы и что проверить после внедрения.
Когда архивы дат становятся проблемой
Сначала стоит убедиться, что речь не о полезной функции. Архивы по датам могут быть оправданы, если пользователи реально ищут материалы по периоду публикации: например, у новостного проекта или журнала с регулярными выпусками. Во всех остальных случаях они часто превращаются в набор страниц вида /2024/, /2024/05/, /2024/05/12/, которые дублируют логику обычных рубрик и тегов.
Признаки, что архивы лучше отключить
- в индексации есть страницы архива с почти пустым содержимым;
- в отчётах краулера видно много URL с одинаковым списком записей;
- архивы дат получают внутренние ссылки, но не дают переходов;
- в теме есть хлебные крошки или блоки навигации, которые уже решают задачу группировки контента;
- на сайте мало публикаций, и архивы выглядят как «тонкие» страницы.
Что проверить до изменений
Перед правкой кода откройте несколько типовых URL архива и посмотрите, как они формируются в вашей теме. Важно понять, используются ли:
- стандартные архивы WordPress;
- кастомные ссылки в меню;
- виджеты с архивами;
- SEO-плагин, который уже ставит
noindexна архивы.
Если архивы уже закрыты от индексации, но продолжают существовать как URL, это не всегда плохо. Но если задача — именно убрать их из фронтенда и не светить лишние адреса, нужен код.
Как отключить архивы дат через functions.php или мини-плагин
Самый надёжный вариант — не править ядро и не удалять шаблоны вручную, а перехватить запрос на уровне WordPress. Для этого подходит фильтр date_rewrite_rules и проверка основного запроса через template_redirect. Если нужен аккуратный вариант без зависимости от темы, лучше оформить это как маленький must-use плагин или обычный плагин.
Ниже пример, который делает две вещи: убирает генерацию rewrite-правил для дат и отправляет посетителя с архивов дат на главную страницу сайта. Если вам нужен другой сценарий, например 404 вместо редиректа, это легко поменять.
<?php
/**
* Plugin Name: Disable Date Archives
*/
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
add_filter( 'date_rewrite_rules', '__return_empty_array' );
add_action( 'template_redirect', function () {
if ( is_date() ) {
wp_safe_redirect( home_url( '/' ), 301 );
exit;
}
} );Если вы не хотите редиректить, а хотите отдавать 404, используйте такой вариант:
<?php
add_action( 'template_redirect', function () {
if ( is_date() ) {
global $wp_query;
$wp_query->set_404();
status_header( 404 );
nocache_headers();
include get_query_template( '404' );
exit;
}
} );Для большинства сайтов редирект на главную или на релевантную рубрику практичнее, чем 404. Но если архивы уже были в индексе и на них есть внешние ссылки, сначала проверьте логику редиректа, чтобы не отправить пользователя в нерелевантный раздел.
Если архивы нужны только для людей, но не для поиска
Иногда полное отключение не требуется. Например, редакции удобно оставить архивы для навигации, но закрыть их от индексации. Это не решает проблему лишних URL полностью, зато снижает риск дублей в поиске. Такой подход уместен, если архивы уже встроены в тему и используются в интерфейсе.
| Подход | Что делает | Минус |
|---|---|---|
| Редирект | Убирает URL из пользовательского сценария | Нужно аккуратно выбрать целевую страницу |
| 404 | Полностью отключает доступ к архиву | Пользователь не увидит старый адрес |
| noindex | Оставляет архив для навигации, но убирает из поиска | URL всё ещё существует и может обходиться ботом |
Если у вас уже стоит SEO-плагин, проверьте его настройки архивов. Иногда достаточно закрыть архивы дат там, а не писать отдельный код. Но если в теме есть собственные шаблоны или нестандартные ссылки, код всё равно пригодится.
Пошаговая проверка после внедрения
После изменения не ограничивайтесь открытием главной страницы. Нужно проверить, что архивы действительно перестали работать как отдельные точки входа.
- Откройте URL вида
/2024/,/2024/05/и/2024/05/12/. - Убедитесь, что они либо редиректят, либо отдают 404, либо закрыты от индексации по вашей задаче.
- Проверьте исходный код страницы на наличие
noindex, если вы выбрали мягкий вариант. - Посмотрите отчёт в Search Console или другом инструменте сканирования: новые ошибки по этим URL появляться не должны.
- Проверьте меню, хлебные крошки и виджеты: там не должно остаться кликабельных ссылок на старые архивы, если вы их отключали полностью.
Если используете кэш, очистите его после правок. Иначе можно увидеть старую версию страницы и решить, что код не сработал.
Частые ошибки и как их исправить
Редирект сделан на все архивы подряд
Иногда разработчик ставит слишком общий условный оператор и случайно задевает не только архивы дат, но и рубрики, теги или авторов. Проверяйте именно is_date(), а не общий is_archive(), если задача касается только календарных архивов.
После отключения остались старые ссылки в теме
Это частая ситуация, если архивы выводились в меню или в сайдбаре через виджет. Код отключает обработку URL, но не убирает саму ссылку из шаблона. Нужно отдельно пройтись по настройкам меню и виджетов.
SEO-плагин и код конфликтуют
Если SEO-плагин уже ставит noindex, а вы сверху добавили редирект, поведение может отличаться на разных страницах и в кэше. Сначала решите, какой вариант нужен: редирект, 404 или noindex. Не смешивайте их без необходимости.
После правки сайт начал отдавать 404 на другие URL
Обычно причина в том, что код вставили не туда или перепутали условие. Для проверки временно отключите фрагмент и убедитесь, что проблема исчезает. Затем возвращайте код в отдельный плагин, а не в functions.php активной темы, чтобы проще было откатить изменения.
Безопасность и производительность
Для такой задачи не нужен тяжёлый плагин, если достаточно нескольких строк кода. Мини-плагин проще контролировать: он не зависит от темы и не ломается после обновления шаблона. Если сайт большой и архивы уже проиндексированы, не спешите удалять их без проверки логов и Search Console: старые URL могут ещё некоторое время приходить из выдачи и внешних ссылок.
Если вы работаете на продакшене, сначала проверьте решение на staging-копии. Это особенно важно, если архивы используются в хлебных крошках, в блоках похожих записей или в кастомных шаблонах категории.
Как понять, что задача решена
Решение можно считать рабочим, если выполняются все три условия: архивы дат больше не открываются как отдельные страницы, в шаблонах не осталось лишних ссылок на них, а в отчётах сканирования не растёт число новых URL этого типа. Если архивы были закрыты через редирект, проверьте ещё и код ответа: он должен быть 301, а не цепочка из нескольких переходов.
На практике это тот случай, когда лучше выбрать один сценарий и довести его до конца: либо полностью убрать архивы дат, либо оставить их только как служебную навигацию. Полумеры обычно приводят к тому, что URL остаются в обходе, но уже никто не помнит, зачем они нужны.