Архивы авторов и дат в WordPress часто остаются открытыми по умолчанию, даже если на сайте один автор или архивы по датам не несут пользы для поиска. В итоге поисковик тратит краулинговый бюджет на страницы, которые дублируют ленту записей или почти не дают уникального контента. На небольших проектах это обычно не критично, но на контентных сайтах и новостниках такие архивы быстро превращаются в технический шум.
Ниже разберём, когда архивы стоит закрывать от индексации, как сделать это без плагина и как проверить, что настройка действительно сработала. Отдельно покажу, где чаще всего ломают логику и почему одного robots.txt здесь недостаточно.
Когда архивы авторов и дат лучше закрыть от индексации
Не все архивы нужно трогать. Если на сайте несколько авторов, у каждого есть нормальная био-страница, подборка материалов и своя роль в структуре сайта, архив автора может быть полезен. То же касается архивов по датам на новостных проектах, где пользователь реально ищет публикации за конкретный период.
Но в типичных случаях noindex оправдан, если:
- на сайте один автор, и архив автора повторяет главную или блог;
- архивы по датам не используются пользователями и не имеют уникального текста;
- в выдаче уже есть дубли: категории, теги, архивы авторов и даты показывают одни и те же записи;
- сайт нацелен на SEO по статьям, а не на навигацию по авторам и календарю публикаций.
Важно понимать разницу между noindex и блокировкой в robots.txt. Если вы запретите обход страницы в robots.txt, поисковик может не увидеть мета-тег noindex вообще. Для удаления из индекса это плохой путь. Сначала нужно разрешить обход, а уже потом отдать директиву noindex.
Диагностика проблемы: что именно индексируется
Перед изменениями проверьте, какие архивы реально открыты. На практике часто оказывается, что закрывать нужно не всё подряд, а только архивы авторов и дат, а категории оставить в индексе.
Что смотреть в первую очередь
- есть ли на сайте один автор;
- показываются ли архивы автора в sitemap;
- есть ли в коде страницы мета-тег
robotsсnoindex; - не закрыты ли архивы одновременно в SEO-плагине и через тему;
- не конфликтует ли настройка с кэшированием HTML.
Быстрая проверка через браузер и исходный код страницы часто уже даёт ответ. Откройте архив автора, затем посмотрите HTML и найдите строку с <meta name="robots". Если там нет noindex, поисковик увидит страницу как обычную.
Пошаговое решение через functions.php или мини-плагин
Самый надёжный вариант — добавить условную установку noindex для архивов авторов и дат. Так вы не зависите от интерфейса темы и не теряете настройку при обновлении.
Ниже пример для functions.php дочерней темы или собственного мини-плагина:
<?php
add_filter('wp_robots', function( array $robots ) {
if ( is_author() || is_date() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Что делает этот код:
- для архивов автора и дат добавляет
noindex; - не запрещает переход по ссылкам внутри страницы, потому что оставляет
follow; - не затрагивает записи, страницы, категории и теги.
Если на сайте уже есть SEO-плагин, сначала проверьте, не управляет ли он robots-мета сам. В таком случае лучше не дублировать логику в двух местах. Иначе можно получить конфликт: один слой ставит index, другой — noindex, а итог зависит от того, что выведется последним.
Если нужно закрыть только архивы одного автора
Иногда архивы нужны для нескольких редакторов, но у одного технического пользователя они не должны индексироваться. Тогда логика может быть точечной:
<?php
add_filter('wp_robots', function( array $robots ) {
if ( is_author('admin') ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Такой подход полезен, если у вас есть служебные аккаунты, которые не должны светиться в поиске. Но лучше не строить сайт вокруг скрытых авторов — это уже вопрос структуры контента, а не только SEO-настройки.
Сравнение подходов: плагин, код, robots.txt
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| SEO-плагин | Если уже используете плагин для мета-тегов и sitemap | Удобно, без кода | Риск дубля настроек и лишней логики |
Код через wp_robots | Если нужна точечная и прозрачная настройка | Контроль, минимум зависимостей | Нужно аккуратно тестировать после обновлений |
robots.txt | Для ограничения обхода, но не для удаления из индекса | Просто добавить правило | Не решает задачу noindex и может мешать переобходу |
Если нужен более широкий контроль над дублями, мета-тегами и техническими страницами, иногда проще использовать специализированный инструмент вроде Clearfy Pro. Но даже в этом случае важно понимать, какие именно архивы вы закрываете и почему. Автоматическая настройка без проверки часто даёт ложное ощущение порядка.
Проверка результата после внедрения
После добавления кода не ограничивайтесь визуальной проверкой в админке. Нужно убедиться, что мета-тег реально появился в HTML и что кэш не отдаёт старую версию страницы.
- Откройте архив автора или даты в режиме инкогнито.
- Посмотрите исходный код страницы и найдите
meta name="robots". - Убедитесь, что там есть
noindexи нет конфликтующей директивыindex. - Очистите серверный и плагинный кэш, если он используется.
- Проверьте страницу через инструменты для вебмастеров после переобхода.
Если архив уже был в индексе, удаление может занять время. Это нормально. Поисковик должен сначала переобойти страницу и увидеть новую директиву. Не стоит ждать мгновенного результата в выдаче в тот же день.
Частые ошибки и как их исправить
Добавили noindex в robots.txt
Это самая частая путаница. В robots.txt нельзя задать noindex как рабочую директиву для современных поисковиков. Для удаления страниц из индекса нужен именно мета-тег или HTTP-заголовок, а не запрет обхода.
Закрыли архив, но забыли про кэш
Если сайт отдаёт HTML из кэша, вы можете видеть старую версию без noindex. После изменений очищайте кэш страницы, объектный кэш и, если нужно, CDN.
Поставили noindex и одновременно запретили обход
Если страница закрыта в robots.txt, поисковик может не увидеть новую директиву. В результате URL остаётся в индексе дольше, чем ожидалось. Сначала дайте роботу доступ к странице, потом управляйте индексацией.
Сломали архивы в теме
Иногда разработчики правят шаблон архива напрямую и случайно меняют вывод заголовков, canonical или пагинацию. Если задача только в индексации, лучше не трогать шаблон, а использовать фильтр wp_robots.
Практические советы по безопасности и производительности
Если вы вносите код вручную, не редактируйте родительскую тему напрямую. Используйте дочернюю тему или небольшой mu-plugin. Так настройка переживёт обновление темы и не потеряется при деплое.
Ещё один полезный момент: не плодите несколько мест, где управляется robots-логика. Когда часть правил живёт в SEO-плагине, часть — в теме, а часть — в кастомном плагине, отладка становится лишней. Для технических директив лучше оставить один источник правды.
Для больших сайтов имеет смысл дополнительно проверить sitemap. Если архивы авторов и дат туда не попадают, это нормально. Если попадают, а вы их закрываете, стоит понять, зачем они вообще там нужны. Иногда проще убрать их из карты сайта, чем рассчитывать только на noindex.
В итоге рабочая схема простая: определить, какие архивы не несут ценности, добавить точечный noindex через wp_robots, очистить кэш и проверить исходный код страницы. Это надёжнее, чем пытаться лечить дубли через robots.txt или скрывать проблему настройками темы.