Пагинация архивов часто становится источником лишних URL: страницы категорий, тегов, авторов и дат начинают индексироваться отдельно, хотя содержат почти одинаковый набор материалов. В результате поисковик тратит обход на слабые страницы, а в выдаче всплывают не те URL, которые вы хотите продвигать.
Задача здесь не в том, чтобы «спрятать всё подряд», а в том, чтобы оставить полезные страницы архивов доступными для обхода, но убрать из индекса их вторые, третьи и последующие страницы там, где это действительно не нужно.
Когда пагинацию архивов стоит закрывать
Не каждый архив нужно трогать. Если у вас большой раздел с регулярными обновлениями, страницы пагинации могут быть полезны для пользователей и поисковых роботов. Но если архивы тонкие, редко обновляются или дублируют друг друга почти полностью, их лучше ограничить.
Типичные признаки проблемы
- в индексе есть страницы вида
/category/news/page/2/,/tag/seo/page/3/и похожие, но они не дают нового контента; - в Search Console растёт число «Просканировано, но не проиндексировано» для архивов;
- основная страница категории ранжируется хуже, чем её пагинированные страницы;
- в логах видно, что бот часто ходит по архивам, а важные страницы обновляются реже;
- в CMS много тегов и рубрик, но на каждой странице архива по 5–10 записей.
Диагностика: что именно закрывать
Перед правками проверьте, какие архивы реально создают дубли. Откройте несколько страниц категории или тега и сравните:
- есть ли уникальный текст на первой странице архива;
- меняется ли title и description на страницах
/page/2/,/page/3/; - есть ли у пагинации canonical на саму страницу или на первую страницу архива;
- не закрыты ли уже эти URL через SEO-плагин.
Если вы используете Yoast SEO, Rank Math или похожий плагин, сначала проверьте их настройки. Частая ошибка — пытаться править robots meta в коде поверх уже работающего плагина. В итоге получается конфликт: один слой ставит index, другой — noindex.
Рабочая схема: noindex для страниц пагинации архивов
Самый предсказуемый вариант — оставить страницы доступными для обхода, но поставить noindex, follow для страниц пагинации архивов. Так поисковик сможет переходить по ссылкам дальше, но не будет держать эти URL в индексе.
Ниже пример для functions.php дочерней темы или небольшого mu-plugin. Он добавляет noindex только на пагинированные архивы, не трогая первую страницу.
add_filter('wp_robots', function ($robots) {
if (is_paged() && (is_category() || is_tag() || is_author() || is_date() || is_post_type_archive())) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Этот вариант хорош тем, что использует штатный фильтр WordPress wp_robots. Он не ломает шаблоны и не требует ручной правки мета-тегов в теме.
Если SEO-плагин уже управляет robots meta
Когда на сайте стоит SEO-плагин, лучше сначала проверить его настройки. Если он уже умеет закрывать архивы или пагинацию, используйте его интерфейс. Код нужен только тогда, когда штатной опции нет или она работает не так, как нужно.
| Подход | Плюс | Минус |
|---|---|---|
| SEO-плагин | Удобно менять без кода | Зависимость от логики плагина |
Код через wp_robots | Точечный контроль | Нужно следить за темой и обновлениями |
| Закрыть через robots.txt | Просто на первый взгляд | Не решает проблему индексации корректно |
Как настроить canonical для пагинации
Canonical на страницах пагинации — спорный момент. Если поставить canonical на первую страницу архива, поисковик может игнорировать содержимое второй и последующих страниц. Это допустимо только если вы сознательно хотите оставить в индексе одну страницу архива.
Если же пагинация нужна для обхода, но не для индексации, canonical лучше не использовать как замену noindex. Он не решает задачу так надёжно. Для большинства сайтов рабочая комбинация такая: noindex, follow на страницах пагинации и нормальный canonical на саму страницу.
Пошаговое внедрение без поломки сайта
- Сделайте бэкап файлов и базы, если правите код темы.
- Проверьте, не закрывает ли пагинацию уже SEO-плагин.
- Добавьте фильтр
wp_robotsв дочернюю тему или mu-plugin. - Очистите кэш страницы, объектный кэш и CDN, если они есть.
- Проверьте несколько URL вручную и через исходный код страницы.
- Отправьте на переобход только важные страницы, если это нужно.
Проверка результата после внедрения
После правки откройте страницу архива и её пагинацию. В исходном коде страницы должен появиться мета-robots с noindex, follow именно на /page/2/ и дальше. Первая страница архива должна остаться без этого ограничения, если вы её не закрывали отдельно.
Проверять удобно в таком порядке:
- просмотреть HTML исходник и найти robots meta;
- проверить заголовок ответа и canonical через DevTools или curl;
- сравнить результат в Search Console после переобхода;
- убедиться, что ссылки внутри архива по-прежнему доступны для обхода.
Для быстрой проверки можно использовать curl:
curl -I https://example.com/category/news/page/2/Если у вас настроен вывод robots meta в HTML, смотрите именно страницу, а не только заголовки ответа. В WordPress это обычно видно в исходнике через view-source:.
Частые ошибки и как их исправить
Закрыли пагинацию в robots.txt
Это распространённая ошибка. Если запретить обход через Disallow, поисковик может продолжать держать URL в индексе без нормального понимания содержимого. Для удаления из индекса лучше использовать noindex, а не блокировку обхода.
Поставили noindex на все архивы
Так можно случайно убрать из индекса полезные страницы категорий. Закрывать стоит именно пагинацию или конкретные тонкие архивы, а не весь раздел целиком.
Не очистили кэш
Если сайт использует page cache, объектный кэш или CDN, старый robots meta может продолжать отдаваться ещё какое-то время. После внедрения обязательно очищайте все уровни кэширования.
Конфликт с SEO-плагином
Если плагин уже генерирует свои robots directives, ваш код может не сработать или сработать частично. В таком случае оставьте один источник правды: либо настройки плагина, либо код.
Безопасность и производительность
Сам по себе фильтр wp_robots почти не влияет на производительность. Но если вы начинаете добавлять сложную логику с запросами к базе на каждом хите, это уже лишняя нагрузка. Для такой задачи не нужно делать отдельные запросы: достаточно проверок условных тегов WordPress.
Если правите тему Hueman или любую другую тему вручную, лучше вынести код в дочернюю тему или mu-plugin. Тогда обновление темы не затрёт изменения. Для сайтов, где часто приходится чистить дубли, закрывать архивы и управлять индексацией, полезно держать под рукой инструменты вроде Clearfy Pro, но только если вам реально нужен набор для технической чистки, а не ещё один слой настроек поверх уже настроенного SEO-плагина.
Что должно получиться в итоге
После настройки пагинация архивов остаётся доступной для обхода, но не засоряет индекс. Основные страницы категорий и тегов продолжают работать, а вторые и последующие страницы перестают конкурировать с ними в выдаче. Это не универсальная схема для всех сайтов, но для большинства контентных проектов с дублирующими архивами она практичнее, чем ручная блокировка через robots.txt.