Как убрать лишние страницы авторов и архивов из индексации в WordPress

На небольших и средних WordPress-сайтах поисковый мусор часто появляется не из-за контента, а из-за служебных страниц: архивов авторов, дат, пагинации, пустых таксономий, страниц вложений. Проблема обычно заметна не сразу: в индексе растут малоценные URL, а в отчётах Search Console появляются страницы, которые не должны конкурировать с основными материалами.

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

Когда проблема уже видна в индексе

Сначала стоит понять, что именно попало в поиск. На практике чаще всего всплывают такие сценарии:

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

Проверить это можно напрямую в Search Console или через поиск по сайту в Google с оператором site:example.com. Если видите URL вида /author/..., /date/... или /attachment/..., значит проблема не в robots.txt, а в логике генерации страниц и их мета-данных.

Что именно нужно отключать, а что — только закрывать

Не все страницы стоит удалять из генерации. Иногда достаточно поставить noindex, а иногда лучше вообще убрать архив из фронтенда и из карты сайта. Коротко это выглядит так:

Для архивов авторов и дат чаще всего разумно идти по пути noindex, follow или полного отключения, если архивы не используются как часть структуры сайта.

Пошаговое решение без лишних побочных эффектов

1. Отключите архивы, которые точно не нужны

Если сайт ведётся одним автором, архив автора обычно не несёт пользы. То же касается архивов дат на большинстве контентных проектов. Самый безопасный путь — не править ядро, а использовать тему или небольшой mu-plugin.

<?php
/**
 * Plugin Name: Disable unnecessary archives
 */

add_action('template_redirect', function () {
    if (is_author() || is_date()) {
        wp_redirect(home_url('/'), 301);
        exit;
    }
});

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

2. Поставьте noindex там, где архив нужен для пользователей

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

<?php
add_filter('wp_robots', function ($robots) {
    if (is_author() || is_date()) {
        $robots['noindex'] = true;
        $robots['follow'] = true;
    }

    return $robots;
});

Такой подход не мешает переходам по ссылкам внутри архива, но даёт поисковику понятный сигнал не включать страницу в выдачу.

3. Уберите архивы из XML sitemap, если они там есть

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

Если у вас стоит Yoast SEO или Rank Math, проще всего проверить настройки типов архивов в интерфейсе. Если нужен кодовый вариант, логика та же: не добавлять служебные URL в список sitemap.

4. Проверьте страницы вложений

Отдельная частая проблема — страницы attachment. Они создаются автоматически для медиафайлов и часто индексируются как пустые страницы. Если на сайте они не нужны, лучше редиректить их на файл или на родительскую запись.

<?php
add_action('template_redirect', function () {
    if (is_attachment()) {
        $parent = wp_get_post_parent_id(get_queried_object_id());

        if ($parent) {
            wp_redirect(get_permalink($parent), 301);
        } else {
            wp_redirect(home_url('/'), 301);
        }
        exit;
    }
});

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

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

После внедрения не ограничивайтесь визуальной проверкой в браузере. Нужны три проверки:

1. Откройте проблемный URL и убедитесь, что он отдаёт редирект или содержит noindex в HTML.
2. Проверьте исходный код страницы: в блоке robots должен быть нужный директивный набор.
3. Посмотрите статус URL в Search Console: сначала он может оставаться в индексе, но со временем должен уйти в состояние исключённых или просканированных, но не проиндексированных.

Для быстрой проверки заголовков можно использовать консоль:

curl -I https://example.com/author/admin/
curl -I https://example.com/2024/01/

Если вы ставили редирект, в ответе должен быть код 301 и новый адрес в заголовке Location. Если использовали noindex, проверьте HTML, а не только заголовки.

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

• Закрыли URL в robots.txt, но не убрали из индекса. Robots.txt не удаляет уже проиндексированные страницы. Сначала нужен noindex или редирект, потом уже можно ограничивать обход, если это действительно нужно.
• Поставили 301 на главную для всех архивов. Это слишком грубо. Если у архива есть релевантная замена, редиректите на неё, а не на главную.
• Отключили архивы, но забыли про внутренние ссылки. В меню, хлебных крошках и виджетах могут остаться ссылки на несуществующие страницы. После отключения проверьте шаблоны темы.
• Сделали noindex, но оставили URL в sitemap. Это не критично, но создаёт лишний шум для поисковика. Для служебных страниц лучше убрать их и из карты сайта.
• Использовали плагины, которые одновременно ставят редирект и noindex. Такой конфликт иногда даёт странное поведение в Search Console. Лучше выбрать один способ для каждой группы URL.

Безопасность и производительность

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

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

Если вам нужна более широкая чистка SEO-мусора, дубли и служебные страницы удобнее контролировать через один инструмент, чем собирать набор разрозненных сниппетов. В таких сценариях уместно посмотреть на Clearfy Pro, если нужен именно пакет для технической оптимизации и удаления дублей.

Когда лучше не трогать архивы вручную

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

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