Архивы по датам в WordPress часто появляются автоматически: /2024/05/, /2024/05/15/ и похожие URL. На небольшом блоге это может быть нормально, но на рабочем сайте такие страницы нередко создают лишние точки входа, дублируют логику рубрик и размывают краулинговый бюджет. Проблема не в самих архивах как классе страниц, а в том, что они редко несут самостоятельную ценность для пользователя и поисковика.
Ниже — практический сценарий: как понять, нужны ли вам архивы дат, как отключить их без побочных эффектов и как проверить, что сайт после правки ведет себя предсказуемо.
Когда архивы дат действительно мешают
Сначала стоит убедиться, что вы боретесь не с симптомом, а с причиной. Архивы дат обычно становятся лишними в трех случаях:
- на сайте есть рубрики и теги, которые уже покрывают навигацию по контенту;
- в архивы по датам попадают почти те же записи, что и в другие архивы, и это дает дублирующиеся сниппеты;
- в поиске индексируются страницы, которые не приносят переходов и не помогают найти материал.
Если же у вас новостной проект, журнал или сайт, где дата — важный навигационный признак, отключать такие архивы без анализа не стоит. Иногда лучше не удалять их, а оставить, но закрыть от индексации и улучшить внутреннюю перелинковку.
Быстрая диагностика
Проверьте, есть ли архивы дат в индексе и как они выглядят в выдаче. Для этого достаточно нескольких запросов:
site:example.com/2024/— показывает, попадают ли архивы в индекс;site:example.com inurl:/2024/05/— помогает увидеть конкретные URL;- в Google Search Console откройте отчет по страницам и посмотрите, есть ли там архивы дат с показами, но без кликов.
Если архивы получают показы, но не дают переходов, это уже повод проверить, нужна ли им вообще отдельная жизнь. Если они не индексируются, но доступны по прямой ссылке, вопрос скорее в чистоте структуры, а не в SEO-аварии.
Как отключить архивы дат в WordPress
Самый надежный вариант — убрать сами архивы на уровне темы или небольшого кастомного плагина, а не просто прятать их через robots.txt. Robots.txt не решает проблему дублирования URL внутри сайта и не гарантирует, что поисковик не увидит адреса через внешние ссылки.
Если вам нужно именно отключение, а не только закрытие от индексации, используйте фильтр date_rewrite_rules и редирект на 404 или на релевантную страницу. Ниже — рабочий пример для functions.php дочерней темы или собственного мини-плагина.
<?php
add_filter('date_rewrite_rules', '__return_empty_array');
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;
}
});
Что делает этот код:
- убирает правила ЧПУ для дат из набора rewrite rules;
- если кто-то все же откроет старый URL, WordPress отдаст 404;
- не создает ложный 200-ответ для несуществующей страницы.
Если вам нужно не удалять архивы полностью, а перенаправить их, можно сделать 301 на главную рубрику или на страницу архива записей. Но редирект должен быть логичным. Перенаправлять все даты на главную — плохая идея: это выглядит как мягкая ошибка, а не как полезная замена.
<?php
add_action('template_redirect', function () {
if (is_date()) {
wp_safe_redirect(home_url('/blog/'), 301);
exit;
}
});
Такой вариант уместен только если у вас реально есть страница /blog/ или другой раздел, который заменяет навигацию по датам. Если подходящей страницы нет, лучше отдавать 404, чем вести пользователя в случайное место.
Сравнение подходов: отключить, закрыть или перенаправить
| Подход | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| Отключить архивы кодом | Архивы не нужны вообще | Чистая структура, меньше мусорных URL | Нужно аккуратно проверить старые ссылки |
| Отдать 404 | Архивы были, но больше не нужны | Честный ответ сервера, без ложных страниц | Нужен контроль внутренних ссылок |
| 301 на релевантный раздел | Есть понятная замена | Сохраняет часть пользовательского сценария | Легко ошибиться с нерелевантным редиректом |
Если нужен более мягкий вариант: закрыть архивы от индексации
Иногда удалять архивы рано. Например, если старые публикации еще получают трафик, но сами страницы дат не нужны в поиске. Тогда можно оставить URL доступными, но добавить noindex, follow для архивов дат. Это не убирает их из сайта, но снижает шанс, что они будут конкурировать с основными страницами.
Пример через wp_robots:
<?php
add_filter('wp_robots', function (array $robots) {
if (is_date()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});
Этот вариант полезен, если вы не хотите ломать старые ссылки и при этом убрать архивы из поиска. Но важно понимать: noindex — это не замена удалению URL. Если архивы создают внутренний шум, лучше все же убрать их из структуры.
Пошаговое внедрение без сюрпризов
- Сделайте резервную копию файлов темы и базы данных.
- Проверьте, нет ли внутренних ссылок на архивы дат в меню, хлебных крошках, виджетах и шаблонах.
- Выберите модель: 404, 301 или noindex.
- Добавьте код в дочернюю тему или в отдельный мини-плагин, а не в основной файл родительской темы.
- Очистите кеш сайта и, если есть, кеш CDN.
- Переобойдите сайт краулером или вручную проверьте старые URL.
Чек-лист после правки
- старые URL дат возвращают 404 или 301, как задумано;
- главная, рубрики и записи открываются без ошибок;
- в HTML нет случайных ссылок на архивы дат;
- в Search Console не растет число странных страниц с датами;
- кеш-плагины не отдают старую версию шаблона.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Откройте несколько старых URL вручную и посмотрите код ответа. Если вы делали 404, сервер должен отдавать именно 404, а не страницу с текстом «не найдено» и статусом 200.
Для быстрой проверки удобно использовать curl:
curl -I https://example.com/2024/05/
curl -I https://example.com/2024/05/15/
В ответе смотрите на строку HTTP/2 404 или HTTP/2 301. Если там 200, значит шаблон или редирект настроены неправильно.
Дополнительно проверьте исходный код страницы архива, если вы оставили ее доступной. В <head> должен быть нужный robots-мета-тег, а не случайный набор директив от темы или SEO-плагина.
Частые ошибки и как их исправить
Самая распространенная ошибка — закрыть архивы только через robots.txt. Это не убирает URL из внутренней структуры и не решает проблему, если на них уже есть ссылки. Если архивы больше не нужны, лучше отдать 404 или сделать 301 на релевантный раздел.
Еще одна ошибка — редиректить все даты на главную. Так вы теряете смысл старых ссылок и создаете слабый пользовательский сценарий. Если уж делать 301, то на страницу, которая действительно заменяет архив.
Третья проблема — забыть про кеш. После изменения шаблона старые архивы могут еще какое-то время открываться из кеша, особенно если используется серверный кеш или CDN. Если проверка показывает старый результат, сначала очищайте кеш, а уже потом ищите баг в коде.
Когда лучше не отключать архивы
Если у вас новостной сайт, хронологический блог или проект, где дата — часть навигации, архивы могут быть полезны. В таком случае чаще подходит не отключение, а аккуратная оптимизация: убрать лишние архивы, оставить только нужные, настроить индексацию и не плодить дубли через шаблоны.
Практический совет по производительности и чистоте кода
Если вы вносите такие правки регулярно, не держите их в functions.php основной темы. Лучше собрать небольшую служебную плагин-обвязку или использовать дочернюю тему. Так обновление дизайна не сотрет техническую настройку.
Если нужен более широкий набор инструментов для чистки дублей и технической оптимизации, иногда удобнее собрать это в одном месте, чем размазывать по шаблонам. В таких задачах уместно посмотреть на Clearfy Pro, если вам нужен не только контроль архивов, но и другие базовые SEO-настройки сайта. Но сам принцип остается тем же: сначала понять, что именно мешает, потом убрать причину, а не маскировать ее.
Если архивы дат уже не несут пользы, их отключение обычно дает более чистую структуру и меньше лишней работы для поискового робота. Главное — не ограничиваться одним переключателем в админке и обязательно проверить код ответа, ссылки и кеш после внедрения.