Пагинация в WordPress часто становится источником лишних URL в индексе: архивы записей, рубрики, теги, страницы поиска и иногда кастомные архивы начинают плодить /page/2/, /page/3/ и похожие адреса. Проблема не в самой пагинации, а в том, что поисковик видит много страниц с почти одинаковым набором блоков, заголовков и мета-данных. В итоге расходуется краулинговый бюджет, а в отчётах появляются дубли и слабые страницы.
Ниже — рабочая схема: как понять, что именно у вас индексируется лишнее, какие варианты решения реально применимы в WordPress и как проверить, что после правки сайт не потерял нужные страницы.
Когда пагинация становится проблемой
Не каждая страница /page/2/ вредна. Для больших архивов она нужна, потому что без неё пользователь не увидит старые записи. Но есть типовые сценарии, где пагинация начинает мешать:
- в индекс попадают страницы пагинации рубрик и тегов, хотя они не несут самостоятельной ценности;
- в поиске видны дубли заголовков и сниппетов для
/page/2/,/page/3/и дальше; - на сайте есть тонкие архивы с 1–2 записями, но WordPress всё равно создаёт несколько страниц пагинации;
- внутренний поиск, авторские архивы, страницы таксономий или фильтров начинают размножать URL с одинаковым контентом;
- пагинация ломает каноникал, если тема или SEO-плагин настроены неаккуратно.
Что считать дублем, а что нет
Если на странице /category/news/page/2/ есть другой набор записей, это не полный дубль в буквальном смысле. Но для SEO это всё равно часто слабая страница, которая не должна конкурировать с основной страницей архива. Обычно в индексе оставляют первую страницу архива, а пагинацию либо закрывают от индексации, либо оставляют доступной для обхода, но без права ранжироваться.
Диагностика: где именно у вас лишние страницы
Сначала не трогайте код. Посмотрите, какие URL уже попали в индекс и откуда они берутся. Это быстрее, чем потом разбирать последствия после правок.
- Откройте
site:вашдомен/page/2в поиске и посмотрите, какие типы страниц всплывают. - Проверьте отчёт по индексированию в Google Search Console: есть ли там URL с
/page/, которые вы не планировали продвигать. - Посмотрите исходный код страницы пагинации и найдите
rel="canonical". Он должен указывать на корректный URL, а не на случайную страницу. - Проверьте robots.txt и настройки SEO-плагина: иногда пагинация закрыта частично, а каноникал остаётся сам на себя.
Если у вас есть доступ к серверу или staging-копии, полезно быстро проверить HTTP-ответы. Страница пагинации должна отдавать 200 OK, если она нужна пользователю, а не 404 или цепочку редиректов.
curl -I https://example.com/category/news/page/2/Смотрите на три вещи: код ответа, canonical и мета-robots. Если страница открывается, но должна быть исключена из индекса, не путайте noindex с запретом обхода в robots.txt. Это разные механики, и для пагинации обычно важнее именно noindex, follow, а не жёсткий запрет сканирования.
Что делать: три рабочих подхода
Выбор зависит от типа страниц. Для рубрик и тегов чаще всего подходит один сценарий, для поиска — другой, для кастомных архивов — третий.
| Подход | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| SEO-плагин | Если нужно быстро закрыть архивы и пагинацию без правки темы | Меньше риска сломать шаблоны | Не всегда даёт точечный контроль |
| Код в теме или плагине | Если нужна точная логика для конкретных архивов | Гибкость, можно закрыть только нужные типы URL | Нужна аккуратность и тестирование |
| Комбинированный вариант | Когда часть страниц должна индексироваться, а часть — нет | Лучше контроль над индексацией | Требует дисциплины в настройках |
Вариант 1: закрыть пагинацию через SEO-плагин
Если у вас уже стоит SEO-плагин, сначала проверьте его настройки для архивов и таксономий. Во многих случаях можно отключить индексацию архивов с пагинацией или задать noindex для конкретных типов страниц. Это безопаснее, чем сразу лезть в шаблоны.
Но не делайте это вслепую. Если вы закроете от индексации все архивы подряд, можно потерять полезные посадочные страницы. Сначала определите, какие рубрики реально должны ранжироваться, а какие существуют только как техническая навигация.
Вариант 2: добавить точечный noindex через код
Если нужен контроль без тяжёлых плагинов, можно повесить логику на wp_robots. Этот фильтр есть в WordPress и позволяет добавить директивы для конкретных типов страниц.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_paged() && ( is_category() || is_tag() || is_tax() ) ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Что делает этот код: если пользователь открыл не первую страницу рубрики, тега или произвольной таксономии, WordPress добавит noindex, follow. Это не запрещает обход ссылок на странице, но снижает шанс попадания самой пагинации в индекс.
Код лучше размещать в небольшом mu-plugin или в дочерней теме, а не в functions.php основной темы, если тема может обновляться и меняться.
Вариант 3: убрать пагинацию из индекса только для поиска и служебных архивов
Страницы поиска, авторские архивы и некоторые служебные страницы обычно не должны конкурировать в поиске. Если у вас уже есть отдельная статья про авторов, не дублируйте логику для них здесь. Для поиска и похожих страниц можно использовать отдельную проверку:
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() || is_paged() && is_home() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Здесь важно не перепутать приоритеты условий. Если у вас сложная тема с кастомным блогом на главной, протестируйте, что именно считается is_home() и не зацепит ли код лишние шаблоны.
Пошаговая настройка без лишнего риска
- Сделайте копию сайта или хотя бы проверьте изменения на staging.
- Определите, какие типы страниц с пагинацией должны остаться доступными пользователю.
- Выберите один способ управления индексацией: SEO-плагин или код. Не смешивайте сразу несколько решений.
- Проверьте, что на страницах пагинации остался корректный
canonical. - После внедрения очистите кеш сайта и CDN, если он есть.
- Переобойдите несколько URL вручную и проверьте HTML-ответ.
Если вы используете Clearfy Pro, его удобно рассматривать как инструмент для точечной чистки дублей и технических мелочей, но всё равно проверяйте результат в исходном коде и Search Console. Ссылка на продукт, если нужен ориентир: Clearfy Pro.
Как проверить, что решение сработало
Проверка нужна не только в браузере. Смотрите на фактический HTML и на то, как страница ведёт себя после переобхода.
- Откройте страницу пагинации и убедитесь, что в
<head>появилсяnoindex, если он нужен. - Проверьте, что
canonicalуказывает на ожидаемый URL, а не на случайную страницу. - Убедитесь, что первая страница архива не получила лишний
noindex. - Посмотрите в Search Console, что новые директивы начали учитываться после повторного обхода.
- Проверьте внутренние ссылки: пагинация должна оставаться кликабельной для пользователя.
Быстрая локальная проверка через командную строку:
curl -s https://example.com/category/news/page/2/ | grep -iE 'robots|canonical'Если у вас есть доступ к логам, полезно посмотреть, не начали ли боты массово ходить по техническим страницам после изменений. Иногда проблема не в индексации, а в бесконечном обходе архивов с параметрами.
Частые ошибки и как их исправить
Закрыли пагинацию в robots.txt
Это частая ошибка. Если запретить обход, поисковик может не увидеть noindex и продолжит держать URL в индексе по старым данным. Для страниц, которые уже известны поиску, обычно лучше использовать noindex, а не только Disallow.
Поставили noindex на первую страницу архива
Такое случается, когда условие написано слишком широко, например только через is_category() без проверки is_paged(). В результате вы закрываете не дубли, а основную посадочную страницу рубрики.
Сломали каноникал в теме
Некоторые темы и плагины генерируют канонический URL вручную. После правки может получиться, что /page/2/ ссылается каноникалом на себя же или на главную страницу сайта. Это нужно проверять в исходнике, а не по визуальному виду страницы.
Включили сразу несколько SEO-решений
Если один плагин ставит noindex, второй переписывает canonical, а третий ещё и меняет robots.txt, потом сложно понять, что именно сломало индексацию. Для таких задач лучше оставить один источник правды.
Практические советы по безопасности и производительности
Технические правки для индексации лучше оформлять так, чтобы они не зависели от обновления темы. Самый надёжный вариант — маленький mu-plugin или собственный мини-плагин. Тогда логика не исчезнет после смены шаблона.
Если сайт большой, не гоняйте лишние проверки на каждой странице без необходимости. Условие is_paged() само по себе лёгкое, но сложные цепочки с кастомными запросами и мета-проверками лучше не строить в wp_robots без причины.
Ещё один практический момент: после изменения директив не забывайте про кеш. Если у вас стоит серверный кеш, CDN или плагин кеширования, старая версия <head> может висеть ещё какое-то время и мешать диагностике.
Если задача шире и вы параллельно чистите сайт от дублей, служебных страниц и лишних элементов, имеет смысл смотреть на комплексные инструменты, а не собирать всё вручную. Но даже в этом случае проверка через исходный код и Search Console остаётся обязательной.