Страницы автора в WordPress часто остаются в индексе даже тогда, когда они не несут самостоятельной ценности: на них дублируются записи, выводится один и тот же список постов, а в небольших проектах архив автора вообще не нужен. Проблема не в самом архиве как таковом, а в том, что поисковик видит отдельный URL с почти тем же содержимым, что и у рубрик, тегов или главной ленты.
Если задача именно техническая — убрать такие страницы из индекса и при этом не сломать сайт, лучше сначала понять, какой у вас сценарий: архивы авторов нужны для пользователей, нужны только для одного редактора или не нужны вовсе. От этого зависит, что делать: ставить noindex, закрывать архивы от обхода, отключать их генерацию или оставлять страницу доступной, но без индексации.
Когда страницы автора становятся проблемой
Обычно это видно на сайтах с несколькими типами архивов: рубрики, теги, авторы, даты. Если у автора мало материалов, его архив выглядит как тонкая страница с 3–5 записями. Если материалов много, но структура сайта уже хорошо собрана по рубрикам, архив автора начинает конкурировать с другими страницами за те же запросы и тянет на себя дубли.
Типичный сигнал из Search Console — в индексе есть URL вида /author/ivan/, но он почти не получает показов, а в сниппете иногда отображается не то описание, которое вы ожидали. Ещё один признак — в отчёте по страницам много архивов, которые не должны участвовать в поиске вообще.
Что проверить перед правкой
- Открывается ли архив автора в теме и есть ли на нём уникальный контент, кроме списка записей.
- Используются ли архивы автора в навигации сайта или они доступны только по прямой ссылке.
- Есть ли у сайта несколько авторов или всё публикуется от одного имени.
- Не закрыты ли уже архивы через SEO-плагин, чтобы не получить двойную настройку.
Если архивы автора нужны для пользователей, но не должны индексироваться, достаточно корректного noindex. Если они не нужны вообще, можно отключить архивы автора на уровне темы или плагина, но это уже отдельное решение и оно влияет на маршрутизацию сайта.
Как закрыть архивы автора от индексации
Самый безопасный вариант — отдать поисковику страницу, но добавить директиву noindex, follow. Тогда страница остаётся доступной для пользователей и роботов, но не должна попадать в индекс. Для WordPress это обычно делается через SEO-плагин или через код, если вы хотите контролировать поведение точечно.
Вариант 1: через SEO-плагин
Если на сайте уже стоит SEO-плагин, сначала проверьте его настройки архивов. Во многих случаях архивы автора можно закрыть без кода. Это проще сопровождать и меньше шансов, что обновление темы всё сломает. Но важно убедиться, что закрытие не дублируется с кодом в functions.php или в mu-plugin.
| Подход | Плюс | Минус |
|---|---|---|
| SEO-плагин | Удобно менять без кода | Нужно следить за конфликтом настроек |
| Код в теме | Точный контроль | Слетает при смене темы |
| mu-plugin | Не зависит от темы | Нужно аккуратно поддерживать |
Если вы используете Clearfy Pro, там есть инструменты для технической чистки и управления индексированием служебных страниц. Это уместно, когда нужно централизованно закрыть архивы, но всё равно стоит проверить итоговый HTML в браузере и ответ сервера, а не полагаться только на галочку в настройках.
Вариант 2: добавить noindex через код
Если нужен точечный контроль без привязки к плагину, можно добавить мета-тег на архивы автора. Для этого используйте хук wp_head и проверку is_author().
<?php
add_action( 'wp_head', function () {
if ( is_author() ) {
echo '<meta name="robots" content="noindex, follow">' . "\n";
}
}, 1 );
Этот вариант работает, если тема корректно выводит wp_head(). Но для SEO лучше не ограничиваться только мета-тегом, а проверить ещё и HTTP-заголовки, если их добавляет сервер или плагин кеширования. Иначе можно получить конфликт: HTML говорит одно, а заголовок — другое.
Вариант 3: отключить архивы автора полностью
Если на сайте один автор и архивы не нужны, можно убрать их из темы или перенаправить на главную страницу автора. Это уже не про индексацию, а про архитектуру сайта. Такой подход оправдан, когда архивы не используются в интерфейсе и не дают пользы посетителям.
Простой пример редиректа архива автора на главную:
<?php
add_action( 'template_redirect', function () {
if ( is_author() ) {
wp_safe_redirect( home_url( '/' ), 301 );
exit;
}
} );
Такой код нужно применять осторожно: если у вас есть внешние ссылки на архивы автора или вы используете их в навигации, редирект может ухудшить UX. В большинстве случаев для SEO безопаснее оставить страницу доступной, но закрыть её от индексации.
Пошаговая схема внедрения
- Определите, нужны ли архивы автора пользователям.
- Проверьте, нет ли уже настроек
noindexв SEO-плагине. - Выберите один способ управления: плагин, код или редирект.
- Внесите изменение только в одном месте, чтобы не получить конфликт.
- Очистите кеш сайта и CDN, если они есть.
- Проверьте HTML страницы автора и её статус в Search Console.
Если вы работаете через код, лучше вынести его в небольшой mu-plugin, а не в тему. Тогда настройка не исчезнет после обновления шаблона. Для служебных правок это практичнее, чем править functions.php активной темы.
<?php
/**
* Plugin Name: Author Archives Noindex
*/
add_action( 'wp_head', function () {
if ( is_author() ) {
echo '<meta name="robots" content="noindex, follow">' . "\n";
}
}, 1 );
Как проверить, что решение сработало
После внедрения откройте страницу автора в браузере и посмотрите исходный код. В <head> должен быть мета-тег noindex, follow, если вы выбрали этот способ. Если используете SEO-плагин, проверьте, не выводит ли он одновременно другой robots-тег.
Дальше проверьте три вещи:
- страница открывается без ошибок 404 или 500;
- в исходнике есть нужная директива robots;
- в Search Console страница попадает в статус, который соответствует вашей настройке, а не продолжает индексироваться как обычная.
Если архив закрыт через редирект, убедитесь, что ответ действительно 301, а не цепочка из нескольких переходов. Для этого удобно использовать инструменты разработчика в браузере или curl:
curl -I https://example.com/author/ivan/
В ответе вы увидите либо 200 OK с мета-тегом noindex, либо 301 Moved Permanently, если вы выбрали редирект. Для SEO это разные сценарии, и их нельзя смешивать без понимания последствий.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt вместо noindex
Это частая ошибка. Если вы запретили обход в robots.txt, поисковик может не увидеть мета-тег noindex на самой странице. В итоге URL может остаться в индексе как «запрещённый к обходу», но не удалиться так, как вы ожидали. Для удаления из индекса обычно нужен доступ робота к странице.
Поставили noindex в двух местах
Например, в SEO-плагине и в коде темы. Тогда на странице могут появиться разные robots-метки или конфликт настроек. Оставьте один источник правды: либо плагин, либо код.
Сделали редирект на все архивы без проверки
Если на сайте есть архивы нескольких авторов, редирект на главную может сломать внутренние ссылки и аналитику. Особенно это заметно на новостных и контентных проектах, где архив автора используется как часть структуры.
Не очистили кеш
После изменения robots-меток старый HTML может продолжать отдавать кеш-плагин или CDN. Тогда вы проверяете уже не актуальную версию страницы и думаете, что настройка не работает. После правки обязательно сбросьте кеш страницы, объектный кеш и CDN, если он используется.
Безопасность и производительность: что учесть
Технически это простая правка, но лучше не вносить её напрямую в активную тему, если проект живой и тема обновляется. Для таких задач безопаснее использовать mu-plugin или отдельный мини-плагин. Так вы не потеряете настройку при обновлении и не будете искать её по файлам темы через полгода.
Если на сайте много служебных архивов и дублей, имеет смысл не точечно закрывать каждый URL вручную, а привести техническую SEO-структуру к одному стандарту. В таких случаях полезно использовать инструменты, которые помогают управлять дублями и чистить лишние служебные страницы централизованно, например Clearfy Pro: https://wpshop.ru/plugins/clearfy.
Но даже при наличии плагина проверка остаётся обязательной. На практике именно ручная проверка HTML и ответа сервера показывает, что реально увидит поисковый робот, а не только интерфейс настроек.