Как закрыть от индексации страницы пагинации в WordPress

Страницы пагинации вида /page/2/, /page/3/ и дальше часто вызывают один и тот же вопрос: оставлять их в индексе или закрывать. Для сайта с большим архивом записей это не абстрактная SEO-теория, а практическая задача: поисковик может тратить обход на второстепенные страницы, а в индексе появляются дублирующие листинги с теми же карточками записей.

Короткий ответ такой: если у вас обычный блог, новостной сайт или архив записей, страницы пагинации чаще всего не нужно индексировать. Но закрывать их стоит аккуратно, чтобы не сломать обход сайта и не убрать из поиска полезные разделы. В WordPress это обычно делают через мета-тег robots, а не через запрет в robots.txt.

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

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

Закрывать от индексации имеет смысл, если:

  • на сайте много записей и длинные архивы;
  • страницы пагинации не получают трафик из поиска;
  • в индексе появляются страницы /page/2/ и дальше, хотя вы хотите продвигать только первую страницу рубрики, архива или блога;
  • в Search Console видно, что поисковик активно сканирует второстепенные листинги.

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

Почему не стоит закрывать пагинацию через robots.txt

Самая частая ошибка — запретить /page/ в robots.txt. На первый взгляд это кажется логичным: если страница не нужна в индексе, значит, нужно запретить её обход. На практике это не лучший вариант.

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

Для пагинации в WordPress обычно нужен именно noindex, а не запрет обхода. Тогда страница остаётся доступной для робота, но не должна попадать в индекс.

Как закрыть страницы пагинации от индексации в WordPress

Самый надёжный способ — добавить на страницы пагинации мета-тег noindex,follow. Это означает: не индексировать саму страницу, но разрешить поисковику переходить по ссылкам на ней. Для архивов это обычно безопаснее, чем жёсткий запрет.

В WordPress есть несколько рабочих вариантов.

Через SEO-плагин

Если на сайте уже стоит SEO-плагин, проверьте его настройки для архивов и пагинации. У многих решений можно отдельно задать robots-метатеги для рубрик, меток, архивов автора и страниц пагинации. Это удобнее, чем править код, если сайт ведётся без разработки.

Плюс этого подхода в том, что плагин сам корректно вставляет мета-теги в <head> и не требует ручных правок темы. Минус — настройки отличаются от плагина к плагину, поэтому нужно смотреть именно документацию вашего решения и проверять результат в исходном коде страницы.

Через код в теме или дочерней теме

Если плагина нет или вы хотите контролировать поведение точечно, можно добавить условный вывод noindex в functions.php дочерней темы или в собственный мини-плагин. Такой вариант подходит, когда нужно закрыть именно страницы пагинации архивов.

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

Пример кода:

add_action( 'wp_head', function () {
    if ( is_paged() ) {
        echo '<meta name="robots" content="noindex,follow" />' . "\n";
    }
} );

Функция is_paged() возвращает true на страницах пагинации архивов, главной ленты и некоторых других списков записей. Для задачи закрытия пагинации это как раз то, что нужно. Если у вас есть отдельные типы страниц, которые тоже используют пагинацию и не должны закрываться, код нужно доработать точнее, чтобы не задеть лишнее.

Если хотите ограничить правило только архивами записей, рубрик, меток и авторов, а не всеми paged-страницами подряд, используйте более узкое условие. Например, можно проверять is_archive() вместе с is_paged(). Но такой вариант уже зависит от структуры сайта и требует аккуратной проверки.

Что выбрать: noindex или canonical

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

Для пагинации обычно используют связку:

  • noindex,follow — чтобы не индексировать вторую и последующие страницы;
  • корректные внутренние ссылки на страницы архива;
  • без лишнего запрета в robots.txt.

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

Как проверить, что страницы /page/2/ действительно закрыты

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

Откройте, например, /page/2/ любой рубрики или блога и посмотрите исходный код страницы. В нём должен быть тег вида:

<meta name="robots" content="noindex,follow" />

Проверять нужно именно исходный код, а не отображение в браузере. Если используется кэш-плагин или серверный кэш, после изменений очистите кэш сайта и, при необходимости, кэш CDN.

Дальше откройте несколько страниц пагинации и убедитесь, что правило срабатывает не только на первой странице архива, но и на /page/2/, /page/3/ и дальше. Если у вас есть отдельные архивы записей, рубрик и меток, проверьте каждый тип отдельно.

В Google Search Console изменения не всегда отражаются мгновенно. Даже после корректной настройки старые URL могут ещё какое-то время висеть в отчётах, пока поисковик не переобойдёт их и не обновит статус.

Типичные ошибки при закрытии пагинации

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

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

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

Если архив большой, а дублей много

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

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

Но это уже отдельная задача. Для пагинации базовое правило остаётся прежним: если страницы /page/2/ и дальше не должны попадать в поиск, закрывайте их через noindex,follow и проверяйте результат по исходному коду.

Если вам нужен именно плагин для чистки SEO-дублей и управления техническими настройками WordPress, можно посмотреть Clearfy Pro. Он не отменяет необходимость понимать логику индексации, но помогает централизованно управлять частью технических SEO-настроек без ручного кода.

Как отключить автоматическое выполнение PHP кода в WordPress
03.10.2026
Как правильно проверять права доступа в WordPress
27.09.2026
Как создать динамические виджеты в WordPress с помощью REST API
27.09.2026
Как избежать конфликтов плагинов в WordPress: практические решения и примеры кода
27.09.2026
Как удалить неактивных пользователей WordPress
24.09.2026