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

Страницы автора в WordPress часто становятся лишними в индексе: на сайте один редактор, записи без уникальных архивов, а в поиске всё равно висит отдельная страница /author/username/. Для новостников, корпоративных блогов и сайтов с одним автором это обычно не даёт пользы, но создаёт дубли и размывает качество индексации.

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

Когда страницы автора мешают индексации

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

Особенно часто это встречается в таких случаях:

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

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

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

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

Перед изменениями проверьте, что именно индексируется. Самый простой способ — поиск по сайту и проверка в Google Search Console или Яндекс.Вебмастере. Ищите URL вида /author/, а также страницы автора с параметрами, если тема или плагин добавляют лишние ссылки.

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

Мини-чек-лист диагностики:

  • есть ли в индексе URL /author/username/;
  • отдаёт ли страница код 200;
  • есть ли уникальный текст или только список записей;
  • не дублирует ли архив автора рубрики, теги или главную ленту;
  • не закрыт ли он уже через robots.txt, если вы рассчитываете на noindex вместо блокировки обхода.

Как закрыть страницы автора: плагин или код

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

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

Вариант 1: закрыть архив автора через SEO-плагин

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

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

Вариант 2: добавить noindex через код

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

<?php
add_action( 'wp_head', function () {
    if ( is_author() ) {
        echo '<meta name="robots" content="noindex,follow" />' . "\n";
    }
}, 1 );

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

Вариант 3: убрать архивы автора из sitemap

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

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

Пошаговое решение без лишних рисков

  1. Определите, нужны ли архивы автора как посадочные страницы. Если нет — закрывайте.
  2. Проверьте, не используются ли они в навигации, хлебных крошках или внутренних ссылках как важный узел.
  3. Выберите один способ: SEO-плагин или код. Не смешивайте сразу три механизма — плагин, robots.txt и meta noindex — без необходимости.
  4. Добавьте noindex,follow или отключите архивы автора в плагине.
  5. Уберите страницы автора из sitemap, если они там есть.
  6. Проверьте заголовки ответа и исходный код страницы.

Если нужен более точный контроль на уровне HTTP-заголовков, можно отправлять X-Robots-Tag для архивов автора. Это полезно, когда шаблон страницы не всегда выводит корректный <head>, но для большинства сайтов достаточно обычного meta robots.

<?php
add_action( 'send_headers', function () {
    if ( is_author() ) {
        header( 'X-Robots-Tag: noindex, follow', true );
    }
} );

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

Как проверить, что решение сработало

После внедрения откройте страницу автора в браузере и проверьте исходный код. В <head> должен быть виден noindex,follow или аналогичный сигнал, если вы используете SEO-плагин. Затем проверьте ответ сервера через DevTools или curl.

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

В ответе ищите либо заголовок X-Robots-Tag, либо хотя бы отсутствие конфликтующих директив. Если вы закрывали архив через плагин, проверьте ещё и sitemap: URL автора не должен там оставаться.

Дальше откройте Google Search Console и посмотрите, как страница отображается в отчёте по проверке URL. Если она уже была в индексе, удаление может занять время. Это нормально: поисковик не выкидывает такие страницы мгновенно только потому, что вы добавили noindex.

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

Закрыли в robots.txt вместо noindex

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

Поставили noindex, но оставили страницу в sitemap

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

Закрыли архив, но оставили на него внутренние ссылки

Это не критично, но бессмысленно, если страница не должна участвовать в поиске. Проверьте меню, блоки «Автор», хлебные крошки и виджеты. Иногда ссылка на автора остаётся в шаблоне записи и продолжает передавать вес на страницу, которую вы не хотите продвигать.

Использовали код в родительской теме

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

Что ещё стоит проверить после закрытия архивов автора

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

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

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

⭐⭐⭐⭐⭐