Пагинация в WordPress часто создаёт не одну, а несколько версий одного и того же контента: архивы рубрик, теги, страницы автора, поиск по сайту, архивы по датам. Для пользователя это нормально, а для поисковика — источник дублей и размывания веса. Проблема обычно всплывает после обновления темы, установки SEO-плагина или переноса сайта: в индексе появляются страницы вида /page/2/, /page/3/, а иногда ещё и параметры сортировки или фильтров.
Ниже — рабочий сценарий: как диагностировать, что именно индексируется, какие страницы закрывать, где достаточно canonical, а где нужен noindex, и как проверить результат без гаданий.
Когда пагинация становится проблемой
Не каждая страница /page/2/ вредна. Если у вас большой архив записей, поисковик может нормально обходить пагинацию и находить старые материалы. Проблема начинается, когда:
- в индекс попадают служебные страницы поиска и фильтров;
- в выдаче видны почти одинаковые архивы с разными URL;
- в Search Console растёт число страниц, исключённых как дубли, но без понятной логики;
- на сайте есть тонкие архивы с 1–2 записями, которые не несут самостоятельной ценности.
Что именно искать в диагностике
Сначала проверьте не «всё подряд», а конкретные типы URL. В WordPress чаще всего это:
- архивы рубрик и тегов:
/category/.../page/2/; - архивы автора:
/author/.../page/2/; - страницы поиска:
/?s=...и их пагинация; - страницы с параметрами сортировки или фильтрации, если они есть через плагины или кастомный код.
Если проблема только в поиске по сайту, не надо закрывать все архивы целиком. Если же у вас тонкие рубрики и теги, лучше пересмотреть их индексацию точечно.
Как понять, что именно попало в индекс
Самый быстрый способ — посмотреть отчёт в Google Search Console и проверить несколько URL вручную. Но этого мало: нужно понять, как страница отдаёт мета-теги и canonical.
Проверка через браузер и исходный код
Откройте проблемную страницу и посмотрите исходный HTML. Ищите:
<meta name="robots" content="noindex,follow">;<link rel="canonical" href="...">;- нет ли нескольких canonical — это частая ошибка после установки двух SEO-плагинов.
Если canonical указывает на саму пагинированную страницу, а вы хотите убрать её из индекса, этого недостаточно. Canonical — это подсказка, а не жёсткий запрет. Для служебных страниц обычно нужен именно noindex.
Проверка через консоль
Если у вас есть доступ к серверу и WP-CLI, можно быстро посмотреть, какие архивы вообще существуют и не плодятся ли лишние таксономии. Например:
wp post list --post_type=post --posts_per_page=5 --fields=ID પોસ્ટ_title
Команда выше не решает проблему сама по себе, но помогает убедиться, что контент есть только в нужных разделах. Для аудита дублей полезнее смотреть URL-структуру и мета-теги, чем количество записей.
Пошаговое решение: что закрывать, а что оставить
Универсального рецепта нет, поэтому лучше идти по слоям. Сначала убираем служебные страницы, потом решаем судьбу архивов.
Шаг 1. Закройте поиск и внутренние служебные страницы
Страницы поиска почти всегда лучше исключать из индекса. Они нестабильны, быстро меняются и редко дают ценность в поиске. Для этого можно добавить noindex,follow на результаты поиска и на страницы с пустой выдачей.
add_action('wp_head', function () {
if (is_search()) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
});
Это базовый вариант. Если у вас уже стоит SEO-плагин, не дублируйте мета-теги вручную: сначала проверьте, умеет ли плагин закрывать поиск штатно. Два одинаковых robots-тега — лишний риск.
Шаг 2. Для пагинации архивов используйте canonical и, при необходимости, noindex
Если речь о рубриках с нормальным объёмом контента, часто достаточно canonical на саму страницу пагинации. Но если архив тонкий или служебный, лучше закрыть его от индексации.
Пример для архивов рубрик и тегов, где вы хотите закрыть именно страницы пагинации, а первую страницу оставить открытой:
add_action('wp_head', function () {
if (is_paged() && (is_category() || is_tag() || is_author())) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
});
Логика простая: первая страница архива остаётся индексируемой, а /page/2/ и дальше — нет. Это не универсальная истина, а рабочий компромисс для большинства контентных сайтов, где вторая и последующие страницы не несут самостоятельного поискового спроса.
Шаг 3. Не ломайте canonical вручную без причины
Частая ошибка — переписать canonical на первую страницу архива для всех страниц пагинации. На практике это может запутать обход и ухудшить понимание структуры сайта. Если SEO-плагин уже ставит корректный canonical, не вмешивайтесь без теста.
Если нужен контроль на уровне шаблона, ориентируйтесь на стандартные функции WordPress и не подменяйте логику глобально. Например, для архивов пагинации лучше работать через условные теги, а не через жёсткую замену всех canonical.
Сравнение подходов: плагин, код или только robots.txt
| Подход | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Если нужно быстро закрыть поиск, архивы и мета-теги без правки темы | Легко получить конфликт настроек, если подключено несколько плагинов |
| Код в теме или мини-плагине | Если нужна точечная логика для конкретных архивов и пагинации | Нужно следить за обновлениями темы и не дублировать функциональность |
| robots.txt | Если надо ограничить обход служебных URL | Не гарантирует исключение из индекса, если URL уже известен поисковику |
Если задача именно в индексации, robots.txt сам по себе не решает вопрос. Для уже известных URL поисковику обычно нужен noindex или корректная каноникализация.
Как проверить, что решение сработало
После внедрения не ограничивайтесь визуальной проверкой. Нужны три уровня контроля.
- Исходный код страницы. Убедитесь, что на нужных URL появился
noindex,followи нет лишних robots-тегов. - Search Console. Проверьте, как Google видит страницу: индексируется ли она, какой canonical выбран, нет ли статуса «Просканировано, но не проиндексировано».
- Поиск по сайту. Выполните запрос вида
site:example.com/page/2/и посмотрите, исчезают ли служебные страницы со временем.
Важно: изменения в индексации не происходят мгновенно. Если вы закрыли страницы сегодня, а в выдаче они ещё видны, это не значит, что настройка не работает. Сначала проверьте исходный код и отчёты обхода.
Частые ошибки и как их исправить
Два SEO-плагина одновременно
Если один плагин ставит canonical, а другой — robots, вы получите непредсказуемый результат. Оставьте один источник правды для мета-тегов. Перед внедрением проверьте, не дублируют ли тему и плагин одну и ту же функцию.
Закрыли всё через robots.txt
Это типичная попытка «быстро убрать дубли». Но если URL уже в индексе, запрет на обход не удалит его автоматически. Для удаления из индекса нужен либо noindex, либо последующая переобходка и корректная каноникализация.
Закрыли первую страницу архива вместе с пагинацией
Так делать не стоит, если архив реально нужен для навигации и поиска. Первая страница архива часто собирает внутренние ссылки и может быть полезной посадочной страницей. Закрывайте именно пагинированные страницы, а не весь архив целиком, если нет отдельной причины.
Сломали шаблон пагинации кастомным кодом
Иногда разработчик добавляет условие в wp_head, но забывает, что тема или плагин уже выводит свои мета-теги. В итоге в HTML два canonical или два robots-тега. Проверяйте исходник после каждого изменения и не полагайтесь только на админку.
Что ещё стоит сделать для чистоты индекса
Если вы уже занялись пагинацией, имеет смысл проверить соседние источники дублей. Это не обязательно делать в тот же день, но в рамках технической чистки сайта это логичный следующий шаг.
- убрать индексирование пустых или почти пустых рубрик;
- закрыть теги, если они дублируют рубрики и не используются как отдельные посадочные страницы;
- проверить архивы автора на небольших сайтах, где они не дают ценности;
- нормализовать URL с параметрами сортировки и фильтрации;
- убедиться, что в sitemap попадают только нужные типы страниц.
Если нужен инструмент для точечной чистки дублей и служебных элементов WordPress, можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином всё равно стоит проверить, какие именно URL он закрывает, а какие оставляет открытыми.
Мини-чек-лист перед публикацией изменений
- Проверил, какие URL реально дублируются.
- Убедился, что canonical не конфликтует с SEO-плагином.
- Закрыл только служебные и пагинированные страницы, а не весь архив без разбора.
- Посмотрел исходный HTML на тестовом URL.
- Проверил отчёты Search Console после переобхода.
Если после внедрения в индексе всё ещё остаются старые URL, это обычно вопрос времени и повторного обхода, а не признак того, что настройка не сработала. Но если в исходнике нет нужного noindex или canonical указывает не туда, проблему нужно искать в теме, плагине или кастомном коде, а не в поисковике.