Страницы автора, архивы по датам и часть тегов часто создают лишние URL, которые не дают трафика, но попадают в индекс. Проблема не в самих архивах как классе страниц, а в том, что они дублируют список записей и размывают обход поисковыми роботами. Если у сайта есть один автор, слабая структура рубрик или теги используются формально, такие страницы обычно лучше закрывать от индексации точечно, а не рубить весь архивный механизм.
Когда архивы действительно мешают
Сначала стоит понять, что именно вы хотите убрать из индекса. Не все архивы одинаково бесполезны. Архив автора может быть полезен на медиа-сайте с несколькими редакторами и отдельными страницами профилей. Архив по дате иногда нужен новостному проекту. А вот на небольшом корпоративном сайте архивы автора и даты чаще всего просто дублируют ленту записей.
Типичные симптомы
- в индексе есть страницы вида
/author/username/,/2026/08/,/tag/..., но они не получают переходов; - в Search Console появляются URL с низкой ценностью и одинаковыми заголовками;
- поисковик индексирует архивы, хотя основная страница рубрики уже ранжируется;
- в выдаче всплывают страницы автора вместо нужных посадочных страниц.
Диагностика: что закрывать, а что оставить
Перед правками проверьте, не используется ли архив как рабочая посадочная страница. Для этого откройте архив в браузере и ответьте на три вопроса: есть ли у страницы уникальный текст, есть ли у нее поисковый спрос, и отличается ли она от других списков материалов. Если ответ «нет» хотя бы на два пункта, архив можно закрывать от индексации.
Полезно также посмотреть, как WordPress формирует архивы в вашей теме. Иногда разработчики добавляют на архив автора описание, блок биографии и внутренние ссылки. В таком случае лучше не удалять страницу совсем, а оставить ее доступной для пользователей и убрать только из индекса.
| Подход | Когда подходит | Минус |
|---|---|---|
| noindex, follow | архив нужен пользователям, но не нужен в поиске | страница остается в обходе, но не должна ранжироваться |
| canonical на основную страницу | есть явный дубль другой страницы | не всегда уместно для архивов, которые не являются дублем один-в-один |
| robots.txt Disallow | нужно ограничить обход, а не индексацию | не гарантирует удаление уже проиндексированного URL |
Пошаговое решение через настройки SEO-плагина
Самый безопасный путь — закрыть архивы через SEO-плагин, если он уже используется на сайте. В большинстве случаев этого достаточно: плагин добавит noindex и корректный canonical, а вам не придется вручную править шаблоны темы.
- Откройте настройки индексации в вашем SEO-плагине.
- Найдите раздел архивов автора, дат и тегов.
- Для ненужных архивов включите
noindex. - Проверьте, что canonical ведет на саму страницу архива или на более релевантную страницу, если это предусмотрено логикой плагина.
- Сохраните настройки и очистите кеш, если он есть.
Если у вас установлен Clearfy Pro, его удобно использовать для точечной чистки дублей и технических страниц. Для этого сценария важен не бренд, а сам принцип: закрывать только те архивы, которые не несут самостоятельной ценности. Подробно это обычно настраивается в блоке SEO-опций и управления индексированием.
Решение кодом: точечно добавить noindex для архивов автора и дат
Если вы не хотите зависеть от интерфейса плагина или у вас кастомная тема, можно добавить мета-тег robots через хук wp_head. Это рабочий вариант, но применять его стоит аккуратно: он должен срабатывать только на нужных типах архивов.
<?php
add_action( 'wp_head', function () {
if ( is_author() || is_date() || is_tag() ) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
}, 1 );Этот пример закрывает от индексации архивы автора, даты и теги. Но перед использованием проверьте, не нужны ли теги для поиска внутри сайта или для внешнего SEO. Если теги у вас реально работают как навигация и имеют уникальные страницы, закрывать их целиком не стоит.
Если нужно закрыть только архив автора, а теги оставить открытыми, сузьте условие:
<?php
add_action( 'wp_head', function () {
if ( is_author() ) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
}, 1 );Когда нужен canonical, а не только noindex
noindex говорит поисковику не показывать страницу в выдаче. canonical помогает указать предпочтительный URL, если у вас есть несколько очень похожих страниц. Для архивов автора canonical на главную обычно не нужен, если это не явный дубль. А вот для страниц с параметрами сортировки или пагинацией canonical может быть полезнее, чем прямое закрытие.
Что делать с robots.txt
Файл robots.txt не заменяет noindex. Это частая ошибка. Если URL уже в индексе, запрет обхода не удалит его автоматически. Поэтому robots.txt можно использовать только как дополнительный слой, когда вы хотите сократить обход ненужных разделов, но не как основной способ очистки индекса.
Пример аккуратного ограничения обхода для архивов, если это действительно нужно:
User-agent: *
Disallow: /author/
Disallow: /date/
Disallow: /tag/Но перед такой правкой убедитесь, что эти разделы не используются для внутренней навигации и не должны сканироваться поисковыми роботами. В большинстве случаев лучше оставить robots.txt в покое и ограничиться noindex.
Проверка результата после внедрения
После изменений не ограничивайтесь просмотром исходного кода в браузере. Проверьте результат в нескольких точках:
- откройте архив в браузере и убедитесь, что в
<head>есть<meta name="robots" content="noindex,follow">; - посмотрите HTTP-ответ и HTML через инструменты разработчика или
curl; - в Search Console отправьте URL на повторную проверку, если он уже был в индексе;
- убедитесь, что страница не закрыта случайно для пользователей и не сломала навигацию.
Проверка через curl выглядит так:
curl -I https://example.com/author/username/Но для проверки именно meta robots лучше смотреть HTML-ответ, а не только заголовки. Если используете кеширующий плагин или серверный кеш, очистите его до проверки, иначе вы увидите старую версию страницы.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt, но она осталась в индексе
Это ожидаемое поведение. Robots.txt запрещает обход, но не гарантирует удаление URL из индекса. Исправление: добавьте noindex, дождитесь переобхода и только потом при необходимости ограничивайте обход.
Поставили noindex через плагин, но тег не появился
Обычно причина в кешировании или конфликте с темой. Проверьте исходный HTML без кеша, отключите временно оптимизаторы, которые могут вырезать wp_head, и убедитесь, что код выполняется на нужном шаблоне.
Случайно закрыли от индексации полезные рубрики
Такое бывает, если в настройках плагина включают noindex для всех архивов подряд. Исправление простое: оставьте открытыми только те рубрики и архивы, которые реально дают трафик или служат посадочными страницами.
Поставили canonical на главную без причины
Для архивов автора это часто лишнее. Canonical должен отражать реальную каноническую версию, а не просто «куда-нибудь». Если архив не является дублем, достаточно noindex,follow.
Практические советы по безопасности и производительности
Если вы вносите правки кодом, не редактируйте файлы темы напрямую. Используйте дочернюю тему или небольшой mu-plugin, чтобы обновление не затерло изменения. Для точечных SEO-правок это особенно важно: такие правки редко должны жить в шаблоне навсегда.
Еще один полезный момент — не плодить несколько источников управления индексацией одновременно. Когда один плагин ставит noindex, второй переписывает canonical, а третий меняет robots.txt, отладка превращается в поиск случайностей. Лучше выбрать один основной способ и держать его под контролем.
Если на сайте много архивов и дублей, имеет смысл сначала навести порядок в технической базе: убрать лишние архивы, проверить пагинацию, отключить ненужные таксономии и только потом добиваться чистого индекса. В таких задачах помогает дисциплина в настройках, а не набор разрозненных «фиксов».