Как закрыть от индексации старые архивы авторов и дат в WordPress без ломки SEO

Автор: Антон Захаров | Опубликовано: 06.09.2026

На небольших и средних WordPress-сайтах архивы авторов и дат часто живут своей жизнью: в индексе остаются страницы, которые не несут самостоятельной ценности, но плодят дубли и размывают сигналы. Типичный пример — у сайта один автор, а в поиске одновременно торчат /author/..., /2024/... и страницы пагинации архивов. Если контент уже размечен по рубрикам и тегам, такие архивы чаще мешают, чем помогают.

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

Когда архивы авторов и дат действительно стоит закрывать

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

Признаки, что архивы создают мусор

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

Диагностика: что именно индексируется сейчас

Перед правками нужно понять, что уже попало в индекс и как WordPress отдаёт архивы. Самая частая ошибка — поставить noindex наугад, не проверив, не закрыт ли при этом нужный раздел или не сломан ли canonical.

Проверка через поисковик и исходный код

Сначала посмотрите, какие URL реально индексируются. Для этого удобно использовать запросы вида site:yelly.ru author и site:yelly.ru 2024. Затем откройте несколько архивов в браузере и проверьте:

есть ли в <head> мета-тег robots;
какой canonical указан на странице;
не выводит ли тема отдельный SEO-блок, который конфликтует с плагином;
не генерируются ли архивы в sitemap.

Если используется SEO-плагин, проверьте его настройки отдельно: иногда архивы закрыты в интерфейсе, но тема добавляет собственный noindex или наоборот переопределяет его.

Что смотреть в WordPress

В админке проверьте:

Настройки → Постоянные ссылки — нет ли нестандартной структуры архивов;
Пользователи → Профиль — если автор один, архив автора почти наверняка лишний;
SEO-плагин — настройки архивов авторов, дат, рубрик и пагинации;
Карта сайта — не попадают ли туда архивные URL.

Что лучше: noindex, canonical или полное отключение архивов

Для архивов авторов и дат есть три рабочих подхода. Выбор зависит от того, нужен ли URL пользователю и должен ли он вообще существовать.

Подход	Когда использовать	Плюсы	Минусы
`noindex,follow`	архив нужен для навигации, но не для поиска	страница остаётся доступной, ссылки на ней можно обходить	URL всё ещё существует и может попадать в краулинг
canonical на основную страницу	архив почти полностью дублирует ленту	сигналы консолидируются	не всегда уместно для архивов, особенно если контент меняется
полное отключение шаблона/роута	архив не нужен вообще	убирает URL из сайта и краулинга	можно сломать старые ссылки и навигацию

На практике для большинства сайтов безопаснее начать с noindex,follow для архивов авторов и дат, а не с жёсткого удаления. Если через пару обходов поисковик перестанет держать эти URL в индексе, этого обычно достаточно.

Пошаговое решение через код темы или мини-плагин

Если не хочется завязываться на SEO-плагин, можно добавить правило в мини-плагин или в functions.php дочерней темы. Ниже пример, который ставит noindex,follow для архивов авторов и дат, но не трогает рубрики, теги и обычные записи.

<?php
add_filter( 'wp_robots', function( array $robots ) {
    if ( is_author() || is_date() ) {
        $robots['noindex'] = true;
        $robots['follow']   = true;
    }

    return $robots;
} );

Этот вариант работает на современных версиях WordPress, где используется фильтр wp_robots. Он не ломает вывод robots meta, а аккуратно дополняет директивы.

Если нужен жёсткий запрет на архив автора

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

<?php
add_action( 'template_redirect', function() {
    if ( is_author() ) {
        global $wp_query;
        $wp_query->set_404();
        status_header( 404 );
        nocache_headers();
        include get_query_template( '404' );
        exit;
    }
} );

Такой подход уместен только если архив автора действительно не нужен. Для архивов дат я бы так не делал без явной причины: иногда они используются в навигации и в старых ссылках из поисковой выдачи.

Как сделать это через SEO-плагин и не получить конфликт

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

Проверьте, где именно управляются архивы:

включается ли noindex для архивов авторов;
отдельно ли настраиваются архивы дат;
не отключён ли вывод архивов в sitemap;
не дублируется ли мета-robots в теме.

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

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

После правки не ограничивайтесь открытием страницы в браузере. Нужно проверить и HTML, и поведение поисковика, и карту сайта.

Чек-лист проверки

в исходном коде архивов есть <meta name="robots" content="noindex,follow"> или эквивалентная директива;
canonical указывает на сам архив, если вы не меняли логику специально;
архивы исключены из sitemap, если это предусмотрено SEO-логикой сайта;
страницы доступны по URL и не отдают 404, если вы выбрали noindex;
в Search Console не растёт число проиндексированных архивов после очередного обхода;
внутренние ссылки на архивы не ведут в тупик, если вы не отключали роут полностью.

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

curl -I https://example.com/author/admin/
curl -I https://example.com/2024/08/

Если вы закрывали архив через noindex, в HTML должен быть виден соответствующий meta-тег. Если вы делали 404, ответ сервера должен быть именно 404, а не 200 с текстом ошибки внутри страницы.

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

Ошибка 1. Закрыли архив в robots.txt вместо noindex

Это частая путаница. Disallow в robots.txt не гарантирует удаление URL из индекса, если поисковик уже знает адрес и видит на него ссылки. Для уже существующих архивов безопаснее использовать noindex или 404/410, если страница точно не нужна.

Ошибка 2. Поставили noindex, но оставили архив в sitemap

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

Ошибка 3. Сломали архивы рубрик вместе с архивами дат

Иногда в коде пишут слишком широкое условие, например проверяют is_archive() без уточнения типа архива. В результате закрываются не только даты и авторы, но и рубрики. Используйте точные проверки: is_author() и is_date().

Ошибка 4. Дублируют robots meta из темы и плагина

Если тема вручную печатает <meta name="robots">, а SEO-плагин делает то же самое через свой фильтр, в коде может появиться два тега. Это уже не косметика: поисковик может интерпретировать конфликт по-разному. Оставьте один источник генерации robots meta.

Безопасность и производительность: что учесть перед правкой

Любая правка SEO-логики в WordPress должна идти через дочернюю тему или мини-плагин, а не через правку ядра темы. Иначе обновление сотрёт изменения. Если добавляете код в functions.php, сначала проверьте его на staging-копии.

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

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