Пагинация в WordPress часто создает не одну проблему, а сразу три: в индекс попадают слабые страницы архивов, поисковик тратит краулинговый бюджет на повторяющийся контент, а в отчётах по SEO появляются дубли title и description. Типичный пример — страницы категорий вида /category/news/page/2/, /page/3/ у главной ленты или пагинация тегов. Сам по себе факт существования таких URL не ошибка. Ошибка начинается, когда они индексируются без контроля и конкурируют с основной страницей архива.
Ниже — рабочая схема: как диагностировать, что именно у вас дублируется, какие варианты закрытия подходят для WordPress, и как проверить результат после внедрения.
Когда пагинация становится SEO-проблемой
Не каждая страница /page/2/ вредна. Если архив большой и полезный, поисковик может нормально обходить его, а пользователю нужны дополнительные страницы. Проблема возникает, когда:
- на страницах пагинации повторяются одинаковые title и description;
- в выдаче всплывают нецелевые страницы вместо основной категории;
- в индексе много URL с почти одинаковым содержимым;
- на сайте есть тонкие архивы: 2–3 записи в категории, но 5–10 страниц пагинации из-за старых материалов;
- фильтры, сортировки или параметры URL создают дополнительные дубли поверх обычной пагинации.
Что именно проверять в первую очередь
Сначала смотрим не на теорию, а на факты. Откройте несколько проблемных архивов и проверьте:
- есть ли у страниц пагинации уникальный
<title>; - не дублируется ли canonical;
- нет ли в sitemap страниц, которые вы не хотите индексировать;
- как ведут себя категории с малым числом записей;
- не генерирует ли тема или плагин лишние параметры в URL.
Диагностика: где искать дубли в WordPress
Самый быстрый способ — взять 2–3 URL из Search Console и сравнить их с тем, что отдает сайт. Если у вас подключен SEO-плагин, проверьте шаблоны title и robots meta. Если SEO-плагина нет, часть логики может идти из темы или кастомного кода.
Проверка через браузер и исходный код
Откройте страницу архива и её вторую страницу. Сравните:
<title>;<meta name="robots">;<link rel="canonical">;- наличие ссылок на следующую и предыдущую страницу;
- не меняется ли основной заголовок H1 без необходимости.
Если на всех страницах архива title одинаковый, это уже повод исправлять шаблон. Если canonical указывает на первую страницу архива, а сама страница пагинации полезна для обхода, это не всегда ошибка. Но если вы хотите исключить такие URL из индекса, нужен явный noindex.
Проверка через WP-CLI и SQL
Если нужен быстрый аудит, можно посмотреть, сколько записей вообще попадает в архивы, и есть ли у вас «пустые» или почти пустые таксономии. Это не решает проблему само по себе, но помогает понять масштаб.
wp post list --post_type=post --post_status=publish --fields=ID,post_title --format=table
Для таксономий полезно посмотреть количество терминов и записи в них через админку или напрямую в базе. Если категория содержит 1–2 поста, а пагинация всё равно есть, это кандидат на закрытие от индексации или на пересмотр структуры контента.
Как закрыть дубли: сравнение подходов
Универсального решения нет. Выбор зависит от того, хотите ли вы полностью убрать страницы пагинации из индекса или только снизить их вес.
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
noindex,follow |
Когда пагинация нужна пользователю, но не нужна в поиске | Простой контроль индексации, ссылки внутри архива остаются доступными | Нужно следить, чтобы мета-тег не конфликтовал с canonical и sitemap |
| canonical на первую страницу | Когда страницы 2+ не несут самостоятельной ценности | Сигнализирует поисковику о главной версии | Не всегда убирает URL из индекса быстро и предсказуемо |
| закрытие через robots.txt | Редко, только для технических URL и параметров | Снижает обход мусорных URL | Не удаляет уже проиндексированные страницы и может мешать переобходу |
Для обычных архивов WordPress чаще всего разумнее использовать noindex,follow на страницах пагинации, а не блокировать их в robots.txt. Так поисковик видит ссылки внутри архива, но не добавляет сами страницы в индекс.
Пошаговое решение: ставим noindex на страницы пагинации
Если у вас есть SEO-плагин, сначала проверьте его настройки. Многие плагины умеют закрывать архивы, теги, авторов и пагинацию без кода. Но если нужен точечный контроль, можно добавить фильтр в functions.php дочерней темы или в небольшой mu-plugin.
Вариант через код
Ниже пример, который добавляет noindex,follow только на страницы пагинации архивов, категорий, тегов и главной ленты. Это не трогает обычные одиночные записи и страницы.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_paged() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );
Этот вариант удобен тем, что использует встроенный фильтр WordPress wp_robots. Он работает с современным ядром и не зависит от конкретного SEO-плагина. Но перед внедрением проверьте, не добавляет ли ваш SEO-плагин собственный meta robots с конфликтующими значениями.
Если нужно закрыть только архивы, а не весь сайт
Иногда is_paged() слишком широко, особенно если у вас есть отдельные шаблоны или нестандартные страницы с пагинацией. Тогда можно сузить условие:
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_paged() && ( is_home() || is_category() || is_tag() || is_tax() || is_author() ) ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );
Такой подход обычно безопаснее: вы не затрагиваете служебные страницы, если они вдруг используют пагинацию по своей логике.
Что делать с robots.txt и sitemap
Закрывать пагинацию через robots.txt — соблазнительно, но для SEO это не всегда лучший путь. Если URL уже в индексе, запрет на обход не удалит его. Поисковик просто перестанет его переобходить, а старая версия может висеть ещё долго.
Правильнее сначала поставить noindex, а затем убедиться, что такие URL не попадают в sitemap. Если ваш SEO-плагин включает архивы пагинации в карту сайта, это стоит отключить в настройках плагина или через его фильтры, если они предусмотрены.
Когда robots.txt всё-таки уместен
Есть отдельный класс мусорных URL: параметры сортировки, фильтры, внутренний поиск, технические страницы. Их можно ограничивать в robots.txt, если вы понимаете, что именно блокируете. Но для обычной пагинации архивов WordPress это не первый выбор.
User-agent: *
Disallow: /?s=
Disallow: /search/
Disallow: /*?orderby=
С параметрами нужно быть аккуратнее: шаблоны в robots.txt поддерживаются не всеми поисковиками одинаково, а слишком широкое правило может задеть полезные URL.
Проверка результата после внедрения
После правки не ограничивайтесь просмотром исходника. Нужно проверить, что решение работает на уровне ответа сервера и на уровне индексации.
- Откройте страницу пагинации и убедитесь, что в
<meta name="robots">естьnoindex. - Проверьте, что canonical не указывает на случайный URL.
- Убедитесь, что страница не попала в sitemap.
- В Search Console отправьте URL на проверку и посмотрите, как он определяется после переобхода.
- Через несколько дней проверьте, уменьшается ли число проиндексированных дублей.
Если используете WP-CLI или тестируете локально, можно быстро посмотреть HTML-ответ страницы пагинации и убедиться, что нужный meta-тег присутствует. В рабочем проекте полезно прогнать несколько URL разных типов: главная лента, категория, тег, автор.
Частые ошибки и как их исправить
Ставят noindex на все архивы подряд
Это частая ошибка после установки SEO-плагина или копирования чужого сниппета. В результате из индекса исчезают не только пагинация, но и полезные категории. Исправление простое: ограничьте условие только страницами is_paged() или только нужными типами архивов.
Закрывают URL в robots.txt и ждут удаления из индекса
Такой подход не работает как «кнопка удаления». Если URL уже известен поисковику, он может остаться в индексе с устаревшим сниппетом. Для удаления нужен noindex или возврат 410/404 для реально ненужных страниц.
Оставляют пагинацию в sitemap
Если карта сайта продолжает отдавать страницы, которые вы хотите исключить, поисковик получает противоречивые сигналы. Проверьте настройки SEO-плагина и исключите архивы пагинации из sitemap, если это предусмотрено.
Конфликтуют SEO-плагин и кастомный код
Например, плагин уже выводит noindex для архивов, а тема добавляет свой canonical. В итоге в исходнике несколько противоречивых сигналов. Решение — оставить один источник правды: либо настройки плагина, либо код в теме/му-плагине.
Практические советы по безопасности и производительности
Если правите тему, не вносите изменения прямо в родительскую тему. Используйте дочернюю тему или mu-plugin, чтобы обновление не затёрло ваш код. Для небольших SEO-правок mu-plugin часто удобнее: он не зависит от активной темы и проще в сопровождении.
Если на сайте много архивов и фильтров, следите за количеством URL с параметрами. Они не только засоряют индекс, но и увеличивают нагрузку на обход. В таких проектах полезно заранее ограничивать генерацию лишних страниц на уровне темы, а не только лечить последствия в SEO-настройках.
Если нужен более широкий набор инструментов для чистки дублей, служебных ссылок и SEO-правок, у WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином полезно понимать, какие именно URL вы закрываете и почему.
В итоге рабочая логика простая: сначала находите, какие именно страницы пагинации создают дубли, затем выбираете один способ закрытия — чаще всего noindex,follow, после чего проверяете исходный код, sitemap и Search Console. Если на этом этапе всё совпадает, проблема обычно уходит без побочных эффектов.