Проблема с пагинацией в WordPress обычно всплывает не в момент запуска сайта, а позже: в индексе оказываются страницы архивов с /page/2/, /page/3/ и дальше, а в Search Console появляются URL, которые не дают трафик, но создают шум. На небольшом сайте это выглядит безобидно, на контентном проекте — уже мешает: поисковик тратит обход на второстепенные страницы, а дубли заголовков и описаний начинают размазывать сигналы.
Ниже — рабочая схема, как понять, что именно у вас индексируется, чем закрывать пагинацию и как проверить, что решение не сломало архивы и внутренние ссылки.
Когда пагинация становится проблемой
Не каждая страница /page/2/ требует запрета индексации. Если у вас новостной архив, блог с большим количеством записей или каталог материалов, поисковик может использовать пагинацию как путь к контенту. Но есть типовые сценарии, где страницы пагинации почти всегда лишние в индексе:
- на страницах архива повторяются одинаковые title и meta description;
- в выдаче появляются слабые страницы без самостоятельной ценности;
- в индексе много URL с параметрами и пагинацией одновременно;
- архивы создаются для таксономий, которые не должны ранжироваться сами по себе;
- сайт уже упирается в crawl budget, и бот ходит по второстепенным URL вместо новых материалов.
Диагностика проблемы
Сначала проверьте, что именно попало в индекс. Самый простой путь — поиск по сайту и отчёт в Google Search Console. Ищите URL вида /page/2/, /page/3/, а также архивы категорий и тегов, где пагинация дублирует структуру.
Полезно посмотреть и сам HTML страницы: если на страницах архива одинаковые мета-теги, а в <link rel="canonical"> стоит текущий URL без логики, поисковик может воспринимать каждую страницу пагинации как отдельную сущность.
curl -I https://example.com/category/news/page/2/
В ответе обратите внимание на статус, canonical и заголовки, если они отдаются сервером или плагином. Если страница отдаёт 200 OK и не закрыта от индексации, а в индексе она не нужна, это уже кандидат на доработку.
Что лучше: noindex, canonical или вообще не трогать
Здесь важно не смешивать задачи. noindex говорит поисковику не включать страницу в индекс. canonical помогает указать основную версию, но не заменяет запрет индексации. Для пагинации чаще всего используют именно noindex, follow на страницах архивов, если эти страницы не должны ранжироваться отдельно, но ссылки внутри них всё ещё нужны для обхода.
| Подход | Когда уместен | Компромисс |
|---|---|---|
| noindex, follow | Пагинация не должна быть в поиске, но ссылки на записи нужны | Страницы могут ещё некоторое время отображаться в отчётах, пока поисковик не переобойдёт сайт |
| canonical на первую страницу | Нужно подсказать основную версию архива | Не всегда достаточно, если страница сама по себе индексируется |
| Оставить как есть | Пагинация реально помогает находить контент и не создаёт дублей | Риск мусора в индексе и лишнего обхода |
Пошаговое решение через код
Если вы хотите контролировать поведение без зависимости от темы или SEO-плагина, можно добавить логику в functions.php дочерней темы или в собственный мини-плагин. Для архивов и пагинированных страниц обычно достаточно вывести noindex, follow там, где это действительно нужно.
<?php
add_action( 'wp_head', function () {
if ( is_paged() && ( is_home() || is_archive() || is_search() ) ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1 );
Этот вариант простой, но у него есть ограничение: он не убирает уже существующие мета-теги, которые может выводить SEO-плагин. Если у вас установлен Yoast SEO, Rank Math или другой плагин, нужно проверить, не конфликтует ли их настройка с вашим кодом. Иначе в HTML можно получить два разных robots-тега.
Если вы используете SEO-плагин, лучше сначала настроить пагинацию в нём, а код оставить только для точечных исключений. Например, для отдельных таксономий или нестандартных архивов.
Когда нужен отдельный фильтр для таксономий
Иногда закрывать нужно не все архивы, а только теги или пользовательские таксономии. Тогда логика должна быть точнее:
<?php
add_action( 'wp_head', function () {
if ( is_paged() && is_tag() ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1 );
Такой подход полезен, если категории у вас рабочие и дают трафик, а теги созданы автоматически и только плодят дубли.
Как закрыть пагинацию в SEO-плагине
Если на сайте уже есть SEO-плагин, сначала проверьте его настройки. Во многих случаях это проще и безопаснее, чем писать код. Логика одна: для архивов, которые не должны индексироваться, ставится noindex, а ссылки остаются доступными для обхода.
Плюс плагина в том, что он обычно сам управляет canonical и мета-тегами. Минус — настройки могут быть спрятаны глубоко, а после обновления часть параметров легко пропустить. Поэтому после изменения всегда проверяйте исходный HTML страницы.
Проверка результата после внедрения
После правки не ограничивайтесь визуальной проверкой. Откройте несколько страниц пагинации и посмотрите исходный код: должен быть только один корректный robots-тег, без конфликтов с canonical. Затем проверьте ответ сервера и индексацию в Search Console.
- страница
/page/2/отдаёт200 OK; - в HTML есть
noindex,followтам, где он нужен; - canonical указывает на ожидаемую версию страницы;
- в Search Console URL постепенно уходят из индекса или перестают появляться новые;
- внутренние ссылки на записи из архива по-прежнему доступны для обхода.
Для быстрой проверки можно использовать не только браузер, но и командную строку:
curl -s https://example.com/category/news/page/2/ | grep -i "robots\|canonical"
Если в ответе видно два robots-тега, значит у вас конфликт между темой, плагином и кастомным кодом. Это нужно исправить до того, как поисковик переобойдёт страницу.
Частые ошибки и как их исправить
Ставят noindex на весь архив, хотя он нужен для обхода
Ошибка возникает, когда закрывают не только пагинацию, но и первую страницу архива. В результате поисковик хуже понимает структуру сайта, а пользователи теряют полезные страницы. Исправление простое: ограничьте правило только пагинированными URL через is_paged().
Дублируют robots-теги
Один тег выводит SEO-плагин, второй — тема или кастомный код. В HTML это выглядит грязно и может дать непредсказуемый результат. Решение: оставьте один источник правды. Если используете плагин, уберите дублирующий код из темы.
Ставят canonical на первую страницу, но не закрывают индекс
Canonical сам по себе не гарантирует исключение из индекса. Если страница уже попала в поиск, она может там оставаться. Для проблемной пагинации обычно нужен именно noindex,follow или настройка в SEO-плагине.
Закрывают пагинацию через robots.txt
Это частая ошибка. Если запретить обход в robots.txt, поисковик может не увидеть canonical и другие сигналы на странице. Для индексации это хуже, чем точечный noindex. Robots.txt уместен для технических разделов, но не как основной инструмент борьбы с дублями пагинации.
Безопасность и производительность
Если правите код вручную, не вносите изменения прямо в родительскую тему. После обновления они пропадут. Используйте дочернюю тему или небольшой mu-plugin, если логика должна жить независимо от дизайна.
Ещё один практический момент: не плодите сложные условия в wp_head. Проверка is_paged() и типа архива почти не нагружает сайт, но громоздкие запросы к базе на каждом хите — плохая идея. Для этой задачи достаточно простых условных тегов WordPress.
Если на сайте много дублей, иногда полезно сначала провести общую чистку SEO-слоя: убрать лишние архивы, закрыть теги, отключить ненужные страницы автора и медиа-вложения. В таких сценариях удобнее работать через один набор настроек, а не разрозненные правки в теме. Если нужен инструмент для чистки дублей и технических мелочей, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy.
Что делать, если после изменений страницы всё равно в индексе
Это нормальная ситуация на коротком отрезке. Поисковик не выкидывает URL мгновенно. Если правило внедрено правильно, но старые страницы ещё видны в отчётах, проверьте три вещи: нет ли кеша с прежним HTML, не переопределяет ли robots-тег SEO-плагин и не закрыт ли URL в robots.txt раньше времени.
Если всё настроено корректно, дальше остаётся дождаться переобхода и при необходимости отправить проблемные URL на повторную проверку в Search Console. Главное — не менять одновременно несколько механизмов, иначе будет сложно понять, что именно сработало.