Как отключить индексацию архивов авторов и дат в WordPress

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

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

Когда архивы авторов и дат нужно закрывать

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

Закрытие особенно уместно, если:

на сайте один или два автора, и их архивы повторяют список записей;
архивы дат содержат те же материалы, что и рубрики и главная лента;
в sitemap попадают служебные страницы, которые не нужны в поиске;
в Search Console появляются страницы с низкой ценностью и высоким числом дублей.

Что именно считать проблемой

Проблема обычно проявляется не одной ошибкой, а набором симптомов. В отчётах можно увидеть страницы архивов с показами, но без кликов, а в индексе — URL вида /author/... или /2026/08/. Если у сайта уже есть нормальная структура рубрик и тегов, архивы дат и авторов часто только мешают.

Диагностика: как понять, что архивы уже индексируются

Перед изменениями проверьте текущую ситуацию. Это важно, чтобы не закрыть то, что уже не индексируется, и не искать потом причину в другом месте.

Откройте архив автора и архив даты в браузере.
Посмотрите исходный код страницы и найдите meta robots.
Проверьте, есть ли эти URL в XML sitemap.
В Search Console выполните проверку URL и посмотрите, разрешена ли индексация.

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

Пошаговое решение через SEO-плагин

Самый безопасный путь — использовать SEO-плагин, если он уже установлен и управляет meta robots и sitemap. В большинстве случаев это проще, чем писать свой код, потому что плагин сам синхронизирует noindex и карту сайта.

Логика простая: отключаете индексацию архивов авторов и дат в настройках, затем проверяете, что плагин перестал отдавать их в sitemap и начал ставить noindex на самих страницах.

Что проверить в настройках

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

Если вы используете Clearfy Pro, это можно закрыть через его инструменты для SEO-очистки и удаления дублей. Но принцип не меняется: после настройки обязательно проверяйте исходный код и sitemap, а не только галочку в админке. Ссылка на плагин: https://wpshop.ru/plugins/clearfy.

Решение через код: если нужен контроль без плагина

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

Ниже пример, который добавляет noindex, follow на архивы авторов и дат. Код лучше размещать в дочерней теме или в небольшом mu-plugin, а не в основном шаблоне, чтобы не потерять настройку при обновлении темы.

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

    return $robots;
} );

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

Если нужно закрыть только архивы авторов

Иногда архивы дат полезны, а архивы авторов — нет. Тогда не надо закрывать всё подряд. Логика должна быть точечной.

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

    return $robots;
} );

Такой подход удобен для редакционных сайтов, где архивы дат помогают навигации, а страницы авторов дублируют ленту материалов одного редактора.

Сравнение подходов

Подход	Когда подходит	Плюсы	Минусы
SEO-плагин	Если уже используется плагин для мета-тегов и sitemap	Проще настроить, меньше кода, обычно синхронизирует sitemap	Зависимость от плагина и его логики
Код через `wp_robots`	Если нужен точечный контроль	Гибкость, не зависит от интерфейса плагина	Нужно отдельно следить за sitemap
robots.txt	Только как вспомогательная мера	Быстро закрывает обход	Не заменяет `noindex` и не решает проблему индексации полностью

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

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

Откройте архив автора и архив даты в режиме инкогнито.
Посмотрите исходный код и убедитесь, что есть noindex.
Проверьте XML sitemap и убедитесь, что служебные архивы исчезли.
Очистите кэш сайта, сервера и CDN, если они используются.
В Search Console отправьте страницу на повторную проверку, если она уже была в индексе.

Если у вас есть доступ к серверу, можно быстро проверить заголовки ответа. Иногда тема или плагин добавляют meta robots в HTML, но кэш отдает старую версию страницы. В таком случае браузер показывает одно, а поисковый робот получает другое.

curl -I https://example.com/author/admin/
curl -s https://example.com/author/admin/ | grep -i robots

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

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

Закрыли страницу в robots.txt и забыли про noindex

Это самая частая ошибка. Если URL уже в индексе, запрет в robots.txt не гарантирует его удаление. Поисковик может перестать обходить страницу, но сам URL ещё долго останется в выдаче без нормального сигнала на удаление. Для уже проиндексированных архивов нужен именно noindex, а robots.txt — только вспомогательный слой.

Оставили архивы в sitemap

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

Не очистили кэш

После правки в коде или настройках часто забывают про page cache, object cache и CDN. В итоге админка уже показывает правильную настройку, а публичная страница ещё отдаёт старую версию. Если у вас есть кэширование на уровне сервера, очистка только в WordPress не поможет.

Закрыли всё без проверки структуры сайта

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

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

Если вы добавляете код вручную, не вставляйте его в файл темы без контроля версий. Лучше использовать дочернюю тему или mu-plugin. Так вы не потеряете настройку после обновления и не сломаете сайт при смене шаблона.

не правьте functions.php основной темы на живом сайте без бэкапа;
проверяйте код на staging-окружении перед выкладкой;
не дублируйте одно и то же правило в нескольких плагинах;
после изменений смотрите не только HTML, но и sitemap, и кэш;
если сайт большой, фиксируйте изменения в репозитории, а не вручную через админку.

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

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