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

Автор: Дмитрий Захаров | Опубликовано: 15.08.2026

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

Задача обычно не в том, чтобы «сломать архивы», а в том, чтобы оставить их доступными для пользователей и убрать из индекса там, где это оправдано. Ниже — рабочие способы для WordPress: через SEO-плагин и через код, если нужен точечный контроль.

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

Проблема заметна не сразу. Сайт может нормально открываться, а в индексе уже копятся страницы вида /author/username/ и /2026/08/. Для контентных проектов это особенно неприятно, если:

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

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

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

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

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

Откройте в Search Console отчёт по страницам и посмотрите, есть ли там архивы автора или даты. Затем проверьте исходный код страницы архива: если в <head> уже есть noindex, возможно, проблема не в WordPress, а в кеше или в другом SEO-плагине.

Полезно также проверить:

есть ли на архиве канонический URL;
не закрыт ли архив в robots.txt вместо noindex;
не создаёт ли тема отдельные шаблоны архивов с собственными мета-тегами;
не дублируются ли архивы по пагинации.

Быстрая проверка через браузер

Если открыть страницу автора и посмотреть исходный HTML, ищите строку вида:

<meta name="robots" content="noindex,follow" />

Если её нет, значит, архив, скорее всего, открыт для индексации. Но даже при наличии noindex стоит проверить, не перезаписывается ли он кешем страницы или оптимизатором HTML.

Как закрыть архивы через SEO-плагин

Самый безопасный путь — использовать настройки SEO-плагина, если он уже установлен. В большинстве случаев это лучше, чем править шаблоны темы вручную.

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

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

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

Решение через код: точечно для автора и даты

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

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

    return $robots;
} );

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

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

Иногда архивы дат полезны для навигации, а архивы автора — нет. Тогда условие можно сузить:

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

    return $robots;
} );

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

Что делать с robots.txt и canonical

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

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

Практически рабочая схема такая:

архивы автора и даты — noindex,follow;
robots.txt — только если нужно снизить лишний обход;
canonical — по ситуации, если есть явная основная версия страницы.

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

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

Откройте архив автора или даты в режиме инкогнито.
Посмотрите исходный код и найдите meta name="robots".
Проверьте, что там есть noindex и follow.
Если используется кеш-плагин, очистите кеш страницы и объектный кеш.
В Search Console отправьте URL на повторную проверку, если страница уже была в индексе.

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

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

Закрыли архив в robots.txt, но не поставили noindex

Это самая частая ошибка. Страница перестаёт обходиться, но уже известный URL может остаться в индексе. Исправление простое: добавьте noindex,follow на уровне HTML-мета или через фильтр WordPress.

Поставили noindex, но кеш отдает старую версию

Если на сайте агрессивный кеш, старый <head> может сохраняться после правки. Очистите кеш плагина, серверный кеш и CDN, если он есть. После этого проверьте исходный код ещё раз.

Сломали архивы темой

Иногда разработчики темы вручную выводят robots-мета в шаблоне header.php. Тогда фильтр WordPress может не сработать так, как ожидается. В этом случае нужно убрать дублирующий код темы и оставить один источник правды — либо ядро, либо SEO-плагин, либо ваш mu-plugin.

Сделали noindex для всего сайта

Такое бывает после неудачной настройки SEO-плагина или при переносе сайта со staging. Проверьте, не включён ли глобальный запрет индексации в Настройки → Чтение. Если он активен случайно, поисковики перестанут индексировать весь сайт.

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

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

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

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

Итоговый ориентир простой: архивы должны либо приносить поисковую пользу, либо быть закрыты от индексации. Если они нужны только как навигационный слой, noindex,follow обычно безопаснее, чем попытка «спрятать» их через robots.txt.