Архивы по датам в WordPress часто остаются включёнными по умолчанию, хотя на большинстве сайтов они не дают пользы ни пользователю, ни поиску. Проблема не в самом архиве как функции, а в том, что он может плодить страницы с тонким содержимым, дублировать рубрики и авторские списки, а ещё создавать лишние URL в карте сайта и внутренней перелинковке.
Если у вас новостной сайт, блог с регулярными публикациями или проект, где статьи быстро теряют актуальность, архивы дат нужно проверить отдельно. Ниже — как понять, мешают ли они, чем их отключать и как убедиться, что после правки ничего не сломалось.
Когда архивы дат становятся проблемой
Сценарий обычно одинаковый: в индексе появляются страницы вида /2024/05/, /2024/05/12/ или похожие URL, а в выдаче они конкурируют с рубриками, тегами и самими статьями. На небольшом сайте это может быть просто мусор, на крупном — источник лишней нагрузки на обход и индексацию.
Проверять стоит не только SEO-эффект. Архивы дат иногда используются в теме как навигация, и после отключения нужно убедиться, что ссылки не ведут на 404 и не остаются в меню, виджетах или хлебных крошках.
Диагностика: как понять, что архивы дат реально мешают
Начните с простых проверок:
- введите в поиск Google запрос
site:example.com inurl:2024/05и посмотрите, есть ли в индексе архивы дат; - проверьте, есть ли у них содержимое кроме списка записей — если на странице только заголовки постов, это слабый сигнал для индексации;
- посмотрите, не попадают ли такие URL в XML-карту сайта;
- проверьте, не используются ли архивы дат в шаблоне темы как основной путь к старым материалам.
Если у вас установлен SEO-плагин, откройте отчёт по индексируемым типам архивов. Иногда архивы дат уже закрыты, но URL всё равно доступны и продолжают расходовать краулинговый бюджет.
Как отключить архивы дат: три рабочих подхода
Есть три нормальных варианта: через SEO-плагин, через код темы или через комбинацию настроек и редиректа. Выбор зависит от того, нужен ли вам полный контроль и есть ли на сайте уже настроенная SEO-логика.
| Способ | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Если нужен быстрый способ без правки темы | Зависимость от интерфейса и настроек плагина |
| Код в теме или mu-plugin | Если нужен предсказуемый результат и контроль | Нужно аккуратно тестировать после обновлений |
| Редирект + noindex | Если архивы уже в индексе и их надо убрать мягко | Не решает вопрос генерации URL внутри сайта |
Вариант 1. Отключить архивы дат через код
Если тема или плагин не дают нужной настройки, можно отключить сами архивы дат на уровне WordPress. Для этого удобно использовать небольшой mu-plugin, чтобы код не потерялся при смене темы.
<?php
/**
* Plugin Name: Disable Date Archives
* Description: Отключает архивы по датам в WordPress.
*/
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. Он уместен, если вы уверены, что на сайте они не нужны вообще. Если архивы уже в индексе, лучше сначала сделать мягкий переход через noindex или 301 на более подходящую страницу.
Вариант 2. Поставить noindex на архивы дат
Если нужно оставить страницы доступными для пользователей, но убрать их из индекса, добавьте мета-тег noindex, follow для date archive. Это не удаляет URL сразу, но снижает шанс, что поисковик будет считать их полезной посадочной страницей.
<?php
add_action('wp_head', function () {
if (is_date()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});Важно: этот способ работает только если тема выводит wp_head() в шаблоне. Если его нет, мета-теги не попадут в HTML вообще — это частая ошибка в самописных темах.
Вариант 3. Настроить редирект на рубрику или главную
Если архивы дат уже накопили историю и на них есть внешние ссылки, лучше не отдавать 404 сразу. В таком случае можно перенаправить их на ближайшую релевантную страницу: рубрику, страницу блога или главную архивную страницу.
<?php
add_action('template_redirect', function () {
if (is_date()) {
wp_safe_redirect(home_url('/blog/'), 301);
exit;
}
});Редирект должен быть осмысленным. Не гоните все даты на главную без разбора: это ухудшает поведение пользователя и может выглядеть как мягкая ошибка для поисковика. Лучше направлять на страницу, где действительно есть список актуальных материалов.
Что делать с уже проиндексированными URL
Если архивы дат уже попали в индекс, одного изменения шаблона мало. Поисковик должен увидеть либо noindex, либо 301, либо 404/410. После этого нужно дождаться переобхода и проверить, не осталось ли старых URL в sitemap, внутренних ссылках и хлебных крошках.
Если вы используете плагин для SEO, проверьте, не генерирует ли он отдельные архивные страницы в карте сайта. Иногда архивы дат закрыты в настройках, но сами URL всё ещё доступны через старые ссылки в теме или в блоках навигации.
Чек-лист после внедрения
- архивы дат открываются не как обычные страницы, а как 404, 301 или
noindex; - в исходном коде есть нужный robots-мета-тег, если выбран мягкий вариант;
- внутренние ссылки на даты удалены из меню, футера и виджетов;
- страницы дат не попадают в XML sitemap;
- в Search Console нет роста ошибок обхода из-за массовых 404;
- основные рубрики и записи не потеряли внутренние переходы.
Проверка результата после внедрения
Проверять нужно не только глазами, но и по факту ответа сервера. Откройте несколько URL архивов дат и посмотрите код ответа. Для 404 и 301 это можно сделать через браузерные инструменты разработчика, curl или любой HTTP-клиент.
curl -I https://example.com/2024/05/Если вы выбрали noindex, откройте страницу и проверьте HTML-исходник. Должна быть строка вроде <meta name="robots" content="noindex,follow" />. Если её нет, значит код не сработал или тема не вызывает wp_head().
Для редиректа проверьте, что ответ действительно 301, а не 302. Временный редирект может затянуть переобход и оставить старые URL в индексе дольше, чем нужно.
Частые ошибки и как их исправить
Отключили архивы, но ссылки остались в теме
Это самая частая ситуация. Архивная страница уже не нужна, но в шаблоне остались ссылки на даты в блоке «Архивы», в футере или в сайдбаре. Уберите виджет, замените его на рубрики или последние записи, либо отключите вывод этого блока в теме.
Поставили 404, но забыли про старые URL в sitemap
Если архивы всё ещё попадают в карту сайта, поисковик продолжит их обходить. Проверьте настройки SEO-плагина и исключите date archives из генерации sitemap, если плагин вообще их добавляет.
Сделали редирект на главную без логики
Массовый редирект всех дат на главную — плохой компромисс. Пользователь теряет контекст, а поисковик видит слабую релевантность. Если архивы нужны как переход к старым материалам, лучше вести их на блог или тематическую рубрику.
Использовали код в functions.php и забыли про обновления темы
Рабочий код в functions.php легко потерять при смене темы. Для технических правок такого типа безопаснее использовать mu-plugin или отдельный мини-плагин.
Практика безопасности и производительности
Отключение архивов дат само по себе не ускорит сайт радикально, но может сократить количество бесполезных обходов и упростить структуру. На больших проектах это полезно, если у вас уже есть проблемы с дублями, лишними архивами и перегруженной навигацией.
Если вы регулярно чистите сайт от технического мусора, имеет смысл проверить и другие слабые места: страницы поиска, архивы авторов, пустые теги, служебные URL плагинов. Для этого удобно использовать инструменты, которые помогают убирать дубли и лишние элементы без ручной правки каждого шаблона. Например, в Clearfy Pro есть набор настроек для технической чистки WordPress, если вам нужен более прикладной способ закрывать служебные страницы и сокращать мусор в индексации.
Но даже с плагином не стоит отключать всё подряд. Сначала проверьте, какие URL реально используются, какие уже в индексе и какие страницы дают трафик. Иначе можно убрать не мусор, а рабочую навигацию.
Если нужен быстрый ориентир, оставьте себе короткую последовательность: найти архивы дат, выбрать способ отключения, проверить код ответа, убрать внутренние ссылки, перепроверить sitemap и Search Console. Это обычно надёжнее, чем пытаться лечить проблему только настройкой robots.txt.