Пагинация архивов в WordPress часто создаёт не одну, а сразу несколько проблем: в индексе появляются страницы-двойники, в отчётах Search Console растёт число URL с низкой ценностью, а canonical начинает указывать не туда, куда ожидает SEO-специалист. Ситуация особенно заметна на категориях, тегах, авторских архивах и в блоге с большим количеством записей.
Ниже разберём, как понять, что проблема именно в пагинации, какие варианты решения реально работают в WordPress и как проверить результат без гадания по логам.
Как выглядит проблема на практике
Типичный сценарий: у категории есть основная страница /category/news/ и страницы пагинации /category/news/page/2/, /page/3/ и дальше. С точки зрения пользователя это нормально, но поисковик может воспринимать такие URL как отдельные документы. Если на страницах пагинации почти нет уникального контента, они начинают конкурировать с основной страницей архива.
Проверять нужно не только robots.txt. Если страница закрыта от обхода, но уже попала в индекс, она может там оставаться ещё долго. Если canonical настроен неверно, поисковик может игнорировать ваш сигнал и выбирать другую версию URL.
Диагностика: что смотреть в первую очередь
- отчёт Страницы в Google Search Console: есть ли URL вида
/page/2/в индексе; - исходный код пагинированных страниц: какой canonical указан;
- robots.txt: не закрывает ли он слишком широко все архивы или наоборот не закрывает ничего;
- шаблон темы: нет ли ручной генерации canonical, которая конфликтует с SEO-плагином;
- наличие дублей от тегов, авторов и дат, если они тоже индексируются без необходимости.
Если у вас установлен SEO-плагин, сначала проверьте его настройки. Во многих случаях проблема решается без правки темы, но иногда приходится вмешиваться кодом, если тема или плагин генерируют конфликтующие теги.
Что именно закрывать, а что оставлять открытым
Не стоит рубить всё подряд. Пагинация нужна для обхода контента и распределения ссылочного веса внутри архива. Закрывать от индексации имеет смысл только тогда, когда страницы пагинации не несут самостоятельной ценности и не должны ранжироваться отдельно.
| Подход | Когда уместен | Минус |
|---|---|---|
| Оставить как есть | Если пагинация даёт уникальный контент и трафик | Риск дублей и лишних URL в индексе |
| Закрыть в robots.txt | Если нужно уменьшить обход, но не ломать структуру | URL могут оставаться в индексе без переобхода |
Добавить noindex,follow | Если страницы не должны индексироваться, но ссылки по ним важны | Нужно аккуратно реализовать, чтобы не конфликтовать с canonical |
На практике для архивов чаще используют связку: noindex,follow для страниц пагинации и корректный canonical на саму пагинированную страницу, а не на первую страницу архива. Это снижает риск дублей и не ломает переходы по страницам.
Пошаговое решение в WordPress
Шаг 1. Проверьте SEO-плагин и тему
Если у вас уже есть Yoast SEO, Rank Math или другой SEO-плагин, сначала отключите ручные правки canonical в теме. Два источника canonical одновременно — частая причина хаоса. В исходнике страницы должен быть один основной canonical, без дублирования.
Если плагин умеет управлять индексированием архивов, используйте его настройки. Код нужен только там, где стандартных опций недостаточно.
Шаг 2. Добавьте noindex для страниц пагинации архивов
Ниже пример для темы или небольшого mu-plugin. Он добавляет noindex,follow только на страницы пагинации архивов, не затрагивая обычные записи и страницы.
<?php
add_filter('wp_robots', function (array $robots) {
if (is_paged() && (is_home() || is_category() || is_tag() || is_author() || is_date())) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Этот вариант работает с современным API WordPress для robots meta. Он не вставляет жёсткий <meta name="robots"> вручную и не конфликтует с частью SEO-плагинов, которые тоже используют фильтры WordPress.
Шаг 3. Убедитесь, что canonical не ломается
Для пагинированных страниц canonical должен указывать на текущую страницу пагинации, а не всегда на первую страницу архива. Если canonical всегда ведёт на первую страницу, поисковик может игнорировать остальные страницы или считать их дубликатами без контекста.
Если тема выводит canonical вручную, лучше убрать этот код и оставить его SEO-плагину или ядру WordPress, если вы используете стандартную логику. Пример проверки в шаблоне:
<?php
// Плохой вариант: один и тот же canonical для всех страниц архива.
if (is_category()) {
echo '<link rel="canonical" href="' . esc_url(get_category_link(get_queried_object_id())) . '" />';
}
Такой код делает все страницы категории дублями первой страницы. Если он уже есть в теме, его нужно заменить на штатную генерацию canonical или убрать совсем.
Шаг 4. При необходимости ограничьте обход в robots.txt
Если у вас очень большой сайт и нужно снизить нагрузку на обход, можно добавить аккуратное правило в robots.txt. Но это не замена noindex и не способ удалить URL из индекса мгновенно.
User-agent: *
Disallow: /page/
Disallow: /*/page/
С этим вариантом нужно быть осторожным. Слишком широкое правило может задеть не только пагинацию архивов, но и другие URL-структуры, если в них встречается сегмент /page/. Перед публикацией проверьте, какие адреса реально генерирует ваш сайт.
Как проверить, что решение сработало
После внедрения не ограничивайтесь просмотром исходника одной страницы. Нужна проверка на нескольких уровнях.
- Откройте
/category/.../page/2/и проверьте meta robots в исходном коде. - Убедитесь, что canonical указывает на текущий URL пагинации или на ту версию, которую вы сознательно выбрали.
- Проверьте robots.txt через браузер и убедитесь, что правило не зацепило лишние разделы.
- В Google Search Console отправьте страницу на повторную проверку после обновления.
- Сравните количество URL с параметром
/page/в отчёте по индексированию через несколько обходов.
Если у сайта есть sitemap, проверьте, не попадают ли туда страницы пагинации. Обычно они там не нужны. В sitemap должны быть основные страницы архива и записи, а не технические страницы навигации.
Частые ошибки и как их исправить
Ошибка 1. Закрыли пагинацию в robots.txt, но не поставили noindex
Это частая ловушка. URL перестают обходиться, но уже известные поисковику страницы могут оставаться в индексе. Если задача именно убрать дубли, одного robots.txt недостаточно.
Ошибка 2. Canonical всегда ведёт на первую страницу
Такой canonical часто появляется из-за самописной темы или старого SEO-кода. Исправление простое: убрать ручную генерацию canonical и оставить корректную логику для пагинированных страниц.
Ошибка 3. Закрыли всё подряд через noindex
Если поставить noindex на все архивы, можно потерять полезные страницы категорий, которые реально приводят трафик. Закрывать нужно только пагинацию или только те архивы, которые не должны ранжироваться.
Ошибка 4. Не проверили дубли от тегов и авторов
Иногда проблема не в пагинации как таковой, а в том, что индексируются ещё и теги, и авторские архивы, и даты. Тогда закрытие одной пагинации ничего не меняет. Сначала нужно понять, какой именно тип архивов создаёт шум.
Практические советы по безопасности и производительности
Если вы вносите код в тему, лучше не править functions.php напрямую на боевом сайте. Используйте дочернюю тему или небольшой mu-plugin. Так вы не потеряете изменения после обновления.
Для сайтов с большим количеством архивов полезно проверить, не создаёт ли тема лишние запросы на каждой странице пагинации. Иногда проблема с SEO идёт рядом с проблемой производительности: тяжелые виджеты, лишние блоки и повторяющиеся запросы к базе на архивных страницах.
Если нужен более широкий набор инструментов для чистки дублей и технической оптимизации, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином полезно понимать, какие именно URL вы закрываете и почему.
Мини-чек-лист перед публикацией
- проверен исходный код пагинированных страниц;
- canonical не дублируется вручную и не указывает на первую страницу без причины;
noindex,followприменён только к нужным архивам;- robots.txt не блокирует лишние URL;
- пагинация не попадает в sitemap;
- в Search Console отправлена проверка после изменений.
Если после правок в индексе всё ещё остаются старые URL, это не всегда ошибка внедрения. Поисковику нужно время на повторный обход и переоценку сигналов. В таких случаях полезнее не добавлять новые костыли, а ещё раз проверить, нет ли конфликтов между темой, SEO-плагином и ручными вставками в шаблонах.