Архивы авторов и дат часто создают лишние страницы в индексе: у них мало уникального контента, они дублируют логику рубрик и тегов, а в небольших проектах вообще не несут ценности для поиска. При этом просто удалить такие архивы нельзя — на сайте могут остаться ссылки, хлебные крошки, sitemap и старые URL из внешних источников.
Ниже разберём рабочий сценарий: как закрыть архивы авторов и дат от индексации, не ломая сайт и не полагаясь на плагин. Подход подойдёт, если вы хотите управлять мета-тегами и HTTP-заголовками на уровне темы или небольшого mu-plugin.
Когда архивы лучше закрыть от индексации
Не каждый архив нужно запрещать. Но если у вас один автор, а архив автора показывает почти тот же список записей, что и главная блога, поисковику там нечего делать. То же самое с архивами по датам: страницы вида /2026/08/ редко дают пользователю полезный ответ, если на сайте нет редакционного архива новостей.
Обычно закрывают от индексации:
- архивы авторов на сайтах с одним редактором;
- архивы дат на корпоративных блогах и контентных сайтах;
- служебные архивы, которые создают дубли в выдаче;
- страницы, которые не должны конкурировать с рубриками и поиском по сайту.
Если у вас новостной проект или сайт, где архивы по датам реально полезны, закрывать их не стоит. В этом случае лучше сначала посмотреть, как они выглядят в индексе и есть ли у них уникальный контент.
Диагностика: как понять, что проблема есть
Проверка начинается не с кода, а с поиска. Откройте Google и проверьте запросы вроде site:example.com inurl:author и site:example.com inurl:2026/08. Если в выдаче много архивных страниц, которые не должны там быть, это уже сигнал.
Ещё один практичный способ — посмотреть, что именно отдаёт WordPress на этих URL. Если архив открывается с обычным HTML, но без явной директивы noindex, поисковик может его индексировать. Важно не путать индексацию с наличием страницы: страница может существовать, но не должна попадать в поиск.
Что проверить перед изменениями
- есть ли у сайта один или несколько авторов;
- используются ли архивы дат в навигации;
- есть ли в теме или SEO-плагине уже заданный
noindex; - не закрыты ли нужные страницы случайно через robots.txt;
- не попадают ли архивы в sitemap.
Пошаговое решение через код
Самый надёжный вариант — добавить логику в functions.php дочерней темы или в небольшой mu-plugin. Так вы не зависите от интерфейса плагина и можете точно контролировать, какие архивы закрываются.
Для WordPress есть фильтр wp_robots, который позволяет добавить директиву noindex на нужных страницах. Это предпочтительнее, чем пытаться править HTML вручную через шаблоны.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_author() || is_date() ) {
$robots['noindex'] = true;
$robots['nofollow'] = false;
}
return $robots;
} );
Этот код добавит noindex на архивы авторов и дат. Если вам нужно закрыть только архивы авторов, оставьте только is_author(). Если нужно закрыть ещё и поисковую выдачу WordPress, можно добавить is_search(), но это уже отдельное решение и его стоит принимать осознанно.
Если у вас старая тема или нестандартный шаблон, полезно дополнительно проверить, не выводит ли она собственный meta robots. Иногда SEO-плагины и тема одновременно задают разные значения, и в итоге поисковик получает противоречивые сигналы.
Если нужен HTTP-заголовок X-Robots-Tag
Для некоторых сценариев удобнее отправлять директиву на уровне заголовка. Это особенно полезно, если архивы отдаются не только как HTML, но и через промежуточные кэши или reverse proxy. В WordPress это можно сделать через send_headers:
<?php
add_action( 'send_headers', function() {
if ( is_author() || is_date() ) {
header( 'X-Robots-Tag: noindex, follow', true );
}
} );
Здесь важно не дублировать логику без необходимости. Если вы уже используете wp_robots, обычно этого достаточно. Заголовок имеет смысл, когда вы хотите закрыть страницу на уровне ответа сервера, а не только в HTML.
Сравнение подходов: плагин, код или robots.txt
Для этой задачи есть несколько вариантов, но они не равнозначны. Ниже — короткое сравнение по практике.
| Подход | Когда подходит | Минусы |
|---|---|---|
| SEO-плагин | Если уже стоит плагин и вы не хотите трогать код | Легко получить дубли настроек и лишнюю сложность |
Код через wp_robots | Если нужен точный контроль без лишних зависимостей | Нужно аккуратно вносить изменения и хранить их в теме или mu-plugin |
| robots.txt | Если нужно ограничить обход, а не индексацию | Не гарантирует исключение из индекса, если URL уже известен поисковику |
Для архивов авторов и дат чаще всего лучше использовать именно noindex, а не запрет в robots.txt. Это более предсказуемо: страница может быть просканирована, но не должна попадать в индекс.
Проверка результата после внедрения
После добавления кода откройте архив автора или архив даты в браузере и посмотрите исходный код страницы. В HTML должен появиться meta robots с noindex, либо в ответе должен быть заголовок X-Robots-Tag.
Проверять стоит в таком порядке:
- откройте страницу архива в режиме просмотра исходника;
- найдите
noindexв meta robots или заголовках ответа; - проверьте, не конфликтует ли это с SEO-плагином;
- посмотрите, не осталась ли страница в sitemap;
- через несколько дней проверьте индексацию в поиске.
Если архив всё ещё попадает в индекс, причина обычно одна из трёх: страница уже была проиндексирована раньше, на сайте есть конфликтующая настройка в SEO-плагине или поисковик ещё не переобходил URL после изменений.
Частые ошибки и как их исправить
Думают, что robots.txt заменяет noindex
Это частая ошибка. Запрет в robots.txt ограничивает обход, но не всегда убирает URL из индекса. Если страница уже известна поисковику, она может оставаться в выдаче как URL без содержимого. Для архивов авторов и дат лучше использовать noindex.
Добавляют код в родительскую тему
После обновления темы изменения пропадают. Если вы правите шаблон напрямую, код нужно переносить в дочернюю тему или mu-plugin. Для технических правок это базовая гигиена.
Не проверяют конфликт с SEO-плагином
Если плагин уже управляет meta robots, ваш код может не дать ожидаемого эффекта или, наоборот, создать противоречие. Сначала посмотрите настройки плагина, потом добавляйте собственную логику.
Закрывают архивы, но оставляют их в sitemap
Так поисковик получает смешанный сигнал: URL есть в карте сайта, но на странице стоит noindex. Это не критическая ошибка, но лучше привести настройки к одному сценарию: либо архив нужен в индексе, либо нет.
Практические советы по безопасности и производительности
Если вы вносите код в functions.php, делайте это через staging-копию или хотя бы через резервную копию файла. Ошибка в PHP может положить сайт, и это особенно неприятно на живом проекте.
Для небольших правок удобнее использовать mu-plugin: он не зависит от темы и не исчезает после обновления. Это хороший вариант для правил, которые должны жить долго и не зависеть от дизайна.
Ещё один момент — кэш. После изменения robots-логики очистите серверный кэш, кэш плагина и CDN, если он есть. Иначе вы можете проверять старую версию страницы и думать, что код не сработал.
Когда лучше не закрывать архивы
Если у вас несколько авторов с разными темами публикаций, архив автора может быть полезной посадочной страницей. То же касается архивов по датам в новостных проектах, где пользователь реально ищет материалы за конкретный период. В таких случаях лучше сначала улучшить контент архива: добавить описание, навигацию, фильтры и уникальный текст.
Если же архив не несёт самостоятельной ценности, закрытие от индексации — нормальная техническая мера. Она не решает все SEO-задачи, но убирает лишний шум и помогает поисковику сосредоточиться на полезных страницах.