Если у сайта на WordPress есть архивы, рубрики, теги или страницы блога с пагинацией, поисковик часто видит несколько почти одинаковых URL. На практике это не всегда критично, но в сочетании с тегами, сортировками, параметрами и неправильными canonical дубли начинают расползаться по индексу. В итоге в выдаче оказываются не те страницы, которые вы хотели продвигать, а краулер тратит обход на мусорные варианты.
Ниже разберём рабочую схему: как диагностировать проблему, какие URL действительно стоит закрывать, чем отличается noindex от canonical и где люди чаще всего ломают индексацию сами себе.
Когда пагинация становится проблемой
Пагинация сама по себе не ошибка. Проблема начинается, когда у одного и того же контента есть несколько адресов, которые отличаются только номером страницы или параметром в URL. Типичный пример: /category/news/page/2/, /category/news/page/3/, а ещё дубли через фильтры, UTM или сортировку. Для пользователя это нормальная навигация, а для поисковика — набор очень похожих страниц.
Особенно часто это всплывает на:
- архивах рубрик и тегов;
- страницах блога с большим количеством записей;
- страницах авторов и дат;
- страницах поиска по сайту;
- URL с параметрами
?orderby=,?s=,?ampи подобными.
Что считать дублем, а что нет
Не каждая вторая страница пагинации — дубль в плохом смысле. Если на странице 2 реально другой набор записей, то это отдельная страница архива. Но если у вас есть страницы, которые отличаются только техническими параметрами и не несут самостоятельной ценности, их лучше не пускать в индекс. Иначе в отчётах Search Console появятся лишние URL, а в индексе — страницы, которые не должны конкурировать с основными.
Диагностика: как понять, что проблема уже есть
Начните не с плагинов, а с проверки фактов. Откройте Search Console и посмотрите отчёты по страницам, которые не индексируются, а также список проиндексированных URL. Если там есть много адресов с /page/, параметрами или внутренними поисковыми запросами, это уже сигнал.
Дальше проверьте три вещи вручную:
- Есть ли у пагинированных страниц собственный
titleиcanonical. - Не закрыты ли они случайно через
robots.txtили мета-тегnoindexвместе с важными архивами. - Не создаёт ли тема или плагин дубли через несколько шаблонов одного архива.
Полезно сравнить исходный код первой и второй страницы архива. Если на второй странице canonical указывает на первую, это уже осознанное решение. Если canonical ведёт сам на себя, но страница не нужна в индексе, нужно менять подход.
Что делать: рабочая схема без лишнего риска
Для большинства сайтов правильный порядок такой: сначала убрать технические дубли, затем решить, какие типы страниц должны индексироваться, и только потом трогать мета-теги. Не стоит массово ставить noindex на всё подряд — можно случайно выкинуть из поиска полезные архивы.
Шаг 1. Закройте мусорные параметры и внутренний поиск
Если сайт генерирует URL с параметрами, которые не нужны в поиске, их лучше не индексировать. Для внутреннего поиска это почти всегда верно: страницы вида /?s=запрос редко должны попадать в индекс. Для параметров сортировки и фильтрации — зависит от структуры сайта, но в большинстве редакционных проектов их тоже лучше не индексировать.
Если вы используете плагин для SEO и чистки дублей, проверьте, умеет ли он управлять мета-тегами и canonical без правки темы. Например, в Clearfy Pro есть инструменты для удаления дублей и технической чистки сайта, что удобно, когда нужно быстро убрать лишние архивы и служебные страницы без кастомного кода: https://wpshop.ru/plugins/clearfy.
Шаг 2. Для пагинации решите: индексировать или нет
Если архив полезен сам по себе и у него есть трафик, не спешите ставить noindex на все страницы пагинации. Иногда достаточно оставить canonical на саму страницу и следить, чтобы в индекс не попадали только технические варианты. Если же это второстепенный архив, который не должен конкурировать с основными посадочными, можно закрыть его от индексации через noindex,follow.
В WordPress это можно сделать через фильтр wp_robots. Ниже пример, который добавляет noindex для страниц внутреннего поиска и некоторых архивов пагинации, если они вам не нужны в индексе:
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
if ( is_paged() && ( is_category() || is_tag() || is_author() ) ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Этот код лучше использовать только после проверки структуры сайта. Если у вас сильные рубрики с полезной пагинацией, закрывать их целиком не стоит.
Шаг 3. Проверьте canonical на страницах архива
Canonical должен быть логичным. Для первой страницы архива обычно указывают саму себя, а для пагинации — либо саму страницу, либо первую страницу архива, в зависимости от вашей SEO-логики и текущей реализации темы. Главное — не допустить хаоса, когда разные плагины ставят разные canonical одновременно.
Если тема или SEO-плагин уже выводит canonical, не дублируйте его вручную в header.php. Это частая причина конфликтов.
Сравнение подходов: плагин, код или настройка темы
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
| SEO/clean-up плагин | Нужно быстро закрыть служебные URL и не лезть в тему | Меньше риска сломать шаблон | Может конфликтовать с другим SEO-плагином |
Код через wp_robots | Нужна точечная логика по типам страниц | Гибко и прозрачно | Требует проверки на staging |
| Правка темы | Тема самописная и вы контролируете шаблоны | Полный контроль над canonical и meta | Легко сломать при обновлении |
Проверка результата после внедрения
После изменений не ограничивайтесь просмотром HTML в браузере. Проверьте именно то, что увидит поисковик.
- Откройте страницу и убедитесь, что в
<head>появился нужныйmeta robots. - Проверьте canonical на первой и второй странице архива.
- Посмотрите ответ сервера для пагинированных URL: он должен отдавать
200 OK, если страница нужна пользователю, или корректный редирект, если URL лишний. - В Search Console отправьте страницу на повторную проверку и дождитесь переобхода.
Для быстрой проверки можно использовать curl:
curl -I https://example.com/category/news/page/2/В ответе смотрите статус, а затем откройте HTML и найдите canonical и robots. Если у вас стоит кэш, проверяйте не только в браузере, но и после очистки кэша плагина и CDN.
Частые ошибки и как их исправить
Ставят noindex на всё подряд
Это самая грубая ошибка. В результате из поиска исчезают не только мусорные страницы, но и полезные архивы. Исправление простое: сначала составьте список типов страниц, которые реально не нужны в индексе, и применяйте правило только к ним.
Дублируют canonical в нескольких местах
Один canonical может выводить SEO-плагин, второй — тема, третий — кастомный код. Поисковик в такой ситуации может проигнорировать часть сигналов. Проверьте исходник страницы и оставьте один источник правды.
Закрывают пагинацию в robots.txt
Это не лучший способ для большинства задач. Если URL уже попал в индекс, robots.txt не всегда поможет убрать его быстро. Для технических дублей обычно полезнее управлять noindex и canonical, а не просто запрещать обход.
Не учитывают кэш и CDN
После правок страница может продолжать отдавать старый meta robots из кэша. Если не очистить кэш, вы будете проверять уже неактуальную версию. Перед тестом сбросьте кэш плагина, серверный кэш и CDN, если он есть.
Безопасность и производительность
Любые правки в functions.php лучше делать в дочерней теме или через небольшой mu-plugin. Так вы не потеряете изменения после обновления темы. Если сайт большой, не плодите несколько плагинов, которые одновременно управляют SEO-мета-тегами: это лишняя нагрузка и источник конфликтов.
Если используете готовый плагин для чистки дублей, проверьте, не отключает ли он нужные функции темы, например хлебные крошки, Open Graph или canonical для записей. После установки всегда сравнивайте исходный HTML до и после.
Короткий чек-лист перед публикацией
- Определены типы страниц, которые должны быть в индексе.
- Проверены canonical и meta robots на первой и второй странице архива.
- Внутренний поиск и служебные параметры не индексируются.
- Кэш и CDN очищены.
- В Search Console нет всплеска новых дублей после переобхода.
Если задача не ограничивается одной страницей, а на сайте уже накопились дубли, удобнее сначала навести порядок в технических сигналах, а потом уже править контент и перелинковку. В таких сценариях полезно иметь один инструмент, который закрывает часть технических дублей без ручной правки каждого шаблона.