Как закрыть от индексации старые PHP-архивы и страницы пагинации в WordPress без потери SEO

На старых WordPress-сайтах часто всплывает одна и та же проблема: в индексе остаются служебные архивы, страницы пагинации и технические URL, которые не дают трафика, но создают дубли и размывают сигналы. Обычно это не одна ошибка, а набор мелких настроек: тема выводит архивы не так, как нужно, плагин SEO не закрывает часть шаблонов, а в robots.txt уже давно лежит ручная правка, про которую все забыли.

Разберём рабочую схему: что именно закрывать от индексации, где лучше использовать noindex, а где достаточно robots.txt, и как не сломать внутреннюю навигацию и переходы по сайту.

Какие URL обычно создают лишний индекс

Сначала стоит понять, что именно вы хотите убрать. Не все архивы одинаково вредны. На реальном сайте чаще всего мешают:

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

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

Диагностика: где искать проблему

Начните с простого аудита. Откройте Google Search Console и проверьте разделы с индексированием и страницами, которые исключены или попали в индекс неожиданно. Затем пройдитесь по сайту вручную:

• посмотрите исходный код архивных страниц и пагинации;
• проверьте, есть ли на них noindex в <meta name="robots">;
• сравните содержимое первой и второй страницы архива;
• проверьте, не закрыты ли важные страницы в robots.txt слишком грубо.

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

Что должно насторожить

Если в индексе есть страницы вида /page/2/, /page/3/ и они почти полностью повторяют первую страницу архива, это типичный кандидат на noindex,follow. Если же у вас в индексе десятки URL с параметрами ?sort=, ?filter= или старые адреса от прежней структуры, сначала надо понять, откуда они генерируются: тема, плагин, редиректы или внешние ссылки.

Что лучше: robots.txt, noindex или редирект

У каждого способа своя задача. Не стоит использовать один инструмент для всех случаев.

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

Пошаговое решение через код

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

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

    return $robots;
});

Этот вариант опирается на встроенный фильтр WordPress wp_robots. Он работает на уровне генерации мета-тега robots и не требует отдельного плагина. Но применять его нужно осторожно: если у вас теги приносят трафик, закрывать их целиком не стоит. В таком случае лучше ограничиться только пагинацией:

<?php
add_filter('wp_robots', function ($robots) {
    if (is_paged() && (is_category() || is_tag() || is_tax())) {
        $robots['noindex'] = true;
        $robots['follow']  = true;
    }

    return $robots;
});

Если старые PHP-архивы отдаются отдельным шаблоном или через кастомный роут, лучше не маскировать их мета-тегом, а сделать 301-редирект на актуальный раздел. Пример для template_redirect:

<?php
add_action('template_redirect', function () {
    if (isset($_SERVER['REQUEST_URI']) && str_contains($_SERVER['REQUEST_URI'], '/old-archive.php')) {
        wp_redirect(home_url('/blog/'), 301);
        exit;
    }
});

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

Как настроить это через SEO-плагин без кода

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

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

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

Если нужен более широкий набор инструментов для чистки дублей и технической оптимизации, можно посмотреть на Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином полезно понимать, какие именно URL вы закрываете и почему.

Проверка результата после внедрения

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

1. Откройте проблемный URL в браузере и проверьте исходный код: должен быть noindex, если вы его добавляли.
2. Проверьте заголовки ответа и редиректы через DevTools, curl -I или любой HTTP-валидатор.
3. В Search Console отправьте URL на повторную проверку и посмотрите, как он классифицируется через несколько обходов.

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

curl -I https://example.com/category/news/page/2/

В ответе вы не увидите мета-тег robots, потому что он находится в HTML, но сможете проверить, не отдаёт ли страница 301/302 и нет ли неожиданных заголовков кеша. Сам HTML лучше посмотреть отдельно:

curl -s https://example.com/category/news/page/2/ | grep -i robots

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

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

• Закрыли архив в robots.txt, но не поставили noindex. Если URL уже в индексе, одного запрета на обход может быть мало. Добавьте noindex или сделайте редирект, если есть замена.
• Закрыли все теги и рубрики подряд. Это часто убивает полезные посадочные страницы. Сначала оцените трафик и роль каждой таксономии.
• Поставили noindex на первую страницу архива. Тогда вы теряете основную страницу раздела. Обычно закрывают только пагинацию, а не сам архив.
• Сделали редирект со всех старых URL на главную. Это плохая замена. Лучше вести на ближайший релевантный раздел.
• Оставили старую логику в теме и новую в плагине. В итоге на странице может быть два разных сигнала: один шаблонный, другой из SEO-плагина. Уберите дублирующую реализацию в одном месте.

Практические советы по безопасности и производительности

Если вы вносите изменения в тему, не редактируйте её напрямую на рабочем сайте. Используйте дочернюю тему или mu-plugin, чтобы правка не слетела после обновления. Для точечных SEO-правил это особенно важно: такие изменения редко должны жить в шаблоне, который обновляется вместе с дизайном.

Ещё один момент — кеш. После изменения robots-логики или редиректов очистите:

• кеш плагина;
• серверный кеш, если он есть;
• CDN-кеш;
• браузерный кеш для локальной проверки.

Иначе вы можете смотреть на старую версию страницы и думать, что код не сработал. Если на сайте включён объектный кеш, иногда полезно проверить не только фронтенд, но и HTML-кеш конкретного URL.

Когда лучше не закрывать страницу от индексации

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

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