Как запретить индексацию архивов автора и дат в WordPress без плагинов

Архивы автора и дат в WordPress часто создают лишние страницы в индексе: они дублируют списки записей, не дают новой информации и размывают релевантность сайта. На небольшом блоге это может быть незаметно, но на контентном проекте такие страницы быстро превращаются в технический шум.

Если задача не в том, чтобы полностью удалить архивы из сайта, а именно в том, чтобы не пускать их в поиск, есть несколько рабочих вариантов: отключить архивы, закрыть их от индексации через noindex, либо оставить доступными для пользователей и при этом убрать из sitemap. Ниже — практический сценарий без выдуманных хуков и без лишней магии.

Когда архивы автора и дат действительно мешают

Проблема обычно проявляется не в одной точке, а сразу в нескольких местах:

• в Google Search Console появляются страницы вида /author/username/ и /2026/08/;
• в выдаче всплывают архивы вместо более полезных страниц категорий или самих записей;
• на сайте несколько авторов, но у каждого архив пустой или почти пустой;
• архивы дат не несут смысла для пользователя, потому что контент не привязан к новостной ленте;
• сайт использует SEO-плагин, но там не отключены архивы по умолчанию.

Если архив автора содержит полноценную биографию, уникальное описание и собственную навигацию, его можно оставить открытым. Но в большинстве проектов архив автора — это просто повтор списка постов, а архив дат вообще не нужен в индексе.

Диагностика: что именно нужно закрыть

Перед правкой проверьте, какие архивы реально доступны и как они сейчас отдаются поисковикам.

Проверка в браузере и исходном коде

Откройте несколько URL вручную:

• /author/slug/;
• /2026/08/ или другой архив даты;
• /author/slug/page/2/ — если есть пагинация.

Посмотрите исходный код страницы и найдите:

• <meta name="robots" content="...">;
• canonical;
• нет ли случайного index,follow на страницах, которые вы хотите закрыть.

Проверка через Search Console

Если архивы уже попали в индекс, одного изменения в коде мало. После настройки нужно будет отправить страницы на переобход и дождаться обновления статуса. Это нормальный процесс: поисковик не убирает такие URL мгновенно.

Пошаговое решение без плагинов

Ниже вариант, который не ломает сам архив, но добавляет noindex для архивов автора и дат. Подходит, если вы хотите оставить страницы доступными для пользователей и при этом убрать их из поиска.

Шаг 1. Добавьте фильтр robots meta

Вставьте код в functions.php дочерней темы или в собственный мини-плагин. Для современных версий WordPress можно использовать фильтр wp_robots.

<?php
add_filter( 'wp_robots', function( array $robots ) {
    if ( is_author() || is_date() ) {
        $robots['noindex']  = true;
        $robots['nofollow']  = false;
        $robots['max-snippet'] = -1;
        $robots['max-image-preview'] = 'large';
        $robots['max-video-preview'] = -1;
    }

    return $robots;
} );

Здесь важный момент: мы не ставим nofollow принудительно. Для архивов это обычно не нужно. Достаточно noindex, чтобы страница не попадала в индекс, но оставалась доступной для обхода.

Шаг 2. Уберите архивы из XML sitemap, если они там есть

Если у вас SEO-плагин генерирует карту сайта, проверьте, не включены ли в неё архивы автора и даты. В большинстве случаев их лучше исключить. Если sitemap создаётся кодом, убедитесь, что туда попадают только нужные типы контента.

Если вы используете собственную генерацию sitemap, не добавляйте туда архивы, которые закрыты от индексации. Иначе поисковик будет регулярно видеть противоречие: URL есть в карте сайта, но на странице стоит noindex.

Шаг 3. При необходимости отключите архивы полностью

Если архивы не нужны даже пользователям, можно убрать их из маршрутизации темы. Но это уже более жёсткий сценарий: ссылки на такие страницы начнут вести на 404, если вы не предусмотрите редирект.

Вместо полного отключения чаще достаточно закрыть их от индекса и оставить для навигации внутри сайта.

Если нужен более жёсткий вариант: редирект или 404

Иногда архивы автора и дат вообще не должны существовать. Например, на корпоративном сайте с одним редактором архив автора не несёт смысла. Тогда можно сделать редирект на главную, на страницу блога или на страницу автора, если она у вас есть.

Пример для архива автора:

<?php
add_action( 'template_redirect', function() {
    if ( is_author() ) {
        wp_safe_redirect( home_url( '/' ), 301 );
        exit;
    }
} );

Этот вариант стоит применять осторожно. Если архив уже в индексе, поисковик должен увидеть стабильный 301-редирект. Если вы просто отдаёте 404 без плана, можно получить лишний шум в отчётах и потерять полезные входящие ссылки, если они были.

Сравнение вариантов

Проверка результата после внедрения

После правки не ограничивайтесь просмотром кода страницы. Проверьте результат в нескольких слоях.

• Откройте архив автора и даты в браузере.
• Посмотрите исходный код и убедитесь, что в robots meta есть noindex.
• Проверьте, не остались ли архивы в XML sitemap.
• В Search Console отправьте URL на проверку и переобход.
• Если использовали редирект, проверьте ответ сервера через curl -I https://site.ru/author/slug/.

Для быстрой проверки заголовков можно использовать:

curl -I https://example.com/author/slug/

Если вы видите 301 и нужный Location, редирект работает. Если используете noindex, убедитесь, что страница отдаёт 200 OK и в HTML действительно присутствует robots meta с нужным значением.

Частые ошибки и как их исправить

Ставят noindex, но оставляют URL в sitemap

Это частая причина, почему поисковик продолжает активно обходить архивы. Решение простое: уберите закрытые страницы из карты сайта или отключите генерацию таких URL в SEO-плагине.

Используют robots.txt вместо noindex

Запрет в robots.txt не гарантирует удаление страницы из индекса, если она уже известна поисковику. Для закрытия от индексации нужен именно noindex или редирект/404 в зависимости от задачи.

Ставят noindex и одновременно canonical на главную

Такой микс иногда встречается в самописных темах. Он не всегда ломает сайт, но создаёт лишнюю путаницу. Если архив закрыт от индекса, canonical должен вести на логичную саму страницу или оставаться штатным, а не маскировать проблему.

Редиректят архив автора на главную без логики

Если у автора есть полезная страница профиля или список публикаций, лучше перенаправлять туда, а не на главную. Иначе пользователь теряет контекст, а поисковик получает слишком общий сигнал.

Забывают про пагинацию

Если закрыли только первый архив автора, но не проверили /page/2/, в индексе могут остаться вторые и третьи страницы. Проверяйте весь шаблон URL, а не только корень архива.

Практические советы по безопасности и производительности

Если вы вносите правки через functions.php, делайте это в дочерней теме. Иначе обновление темы затрёт изменения. Для более аккуратного варианта лучше оформить код как небольшой mu-plugin или отдельный плагин под задачу.

Ещё один практический момент: не перегружайте условные проверки в каждом запросе. Для задачи с архивами достаточно стандартных условных тегов WordPress, без дополнительных запросов к базе.

Если на сайте уже есть SEO-плагин, сначала проверьте его настройки. Иногда нужный результат можно получить без кода, а код оставить только для исключений. Это особенно полезно, если на проекте несколько администраторов и вам важно, чтобы логика была предсказуемой.

Если вам нужен более широкий контроль над дублями, индексированием и технической чисткой сайта, в экосистеме WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wptask.ru&utm_medium=article&utm_campaign=kak-zapretit-indeksaciyu-arkhivov-avtora-i-dat-v-wordpress-bez-plaginov. Но для описанного сценария достаточно и штатного кода WordPress, если вы хотите держать решение под контролем.

Короткий чек-лист перед публикацией

• Проверить, нужны ли архивы пользователям вообще.
• Выбрать подход: noindex, редирект или 404.
• Убедиться, что закрытые URL не попали в sitemap.
• Проверить архивы автора и дат, включая пагинацию.
• Посмотреть исходный код страницы и HTTP-ответ.
• Отправить URL на переобход в Search Console.

Если после настройки архивы всё ещё появляются в индексе, обычно проблема не в самом коде, а в сопутствующих сигналах: sitemap, canonical, старые внешние ссылки или слишком ранняя проверка без переобхода. В таких случаях помогает последовательная проверка всех уровней, а не замена одного тега на другой.