Как убрать дубли страниц в WordPress от пагинации, фильтров и архивов

Автор: Дарья Егорова | Опубликовано: 06.09.2026

Если в Search Console растут страницы с одинаковым контентом, а в индексе появляются десятки URL с ?replytocom=, ?utm_, пагинацией и архивами, проблема обычно не в «плохом SEO», а в том, что WordPress слишком щедро отдаёт один и тот же контент по разным адресам. Это лечится не одной галочкой, а набором точечных правил: где-то нужен noindex, где-то canonical, а где-то проще вообще убрать источник дубля.

Что именно считать дублем в WordPress

Сначала полезно разделить ситуацию на три типа. Первый — полные дубли, когда одна и та же запись доступна по разным URL. Второй — почти дубли, когда контент тот же, но URL отличается параметрами, сортировкой или фильтром. Третий — тонкие страницы, где контента мало, но они массово создаются архивами, тегами, авторами и датами. Для поисковика это разные сигналы, и закрывать их нужно по-разному.

Типичные источники дублей

страницы пагинации архивов и рубрик;
архивы тегов, авторов и дат;
URL с параметрами ?replytocom=, ?sort=, ?filter=;
страницы вложений медиафайлов;
версии с и без слеша, если сервер и CMS настроены неаккуратно;
страницы поиска по сайту;
дубли из-за неправильного canonical в теме или плагине.

Диагностика: где искать проблему

Не стоит сразу ставить плагин и надеяться, что он всё исправит. Сначала проверьте, какие URL реально индексируются и какие из них отдают одинаковый HTML. Для этого достаточно трёх шагов: Search Console, краулер и ручная проверка нескольких адресов.

Что смотреть в Search Console

Откройте отчёт по страницам и обратите внимание на группы вроде «Просканировано — не проиндексировано», «Дубликат, Google выбрал другой канонический URL» и «Альтернативная страница с правильным каноническим тегом». Если там много архивов и параметров, значит поисковик уже видит разрастание URL-структуры.

Быстрая проверка через curl

Если нужно понять, что отдают разные URL, сравните заголовки и канонический адрес. Это удобно делать даже без краулера:

curl -I https://example.com/category/news/page/2/
curl -I https://example.com/category/news/?sort=popular
curl -I https://example.com/sample-post/?replytocom=123

Дальше откройте HTML и проверьте, есть ли в <head> корректный rel="canonical". Если canonical указывает на саму страницу с параметром, а не на чистую версию URL, поисковик может продолжать индексировать мусор.

Пошаговое решение: что закрывать, а что оставлять

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

1. Уберите технические дубли на уровне сервера и CMS

Если сайт доступен и с www, и без него, или по HTTP и HTTPS, сначала настройте жёсткий редирект на одну версию. Это не SEO-украшение, а базовая гигиена. То же самое касается слеша в конце URL: WordPress обычно умеет сам, но тема или кастомный роутинг могут ломать поведение.

Для вложений медиа лучше сразу отключить индексируемые attachment pages и вести их на сам файл или на родительскую запись. В большинстве проектов это просто лишние страницы без смысла.

2. Закройте архивы, которые не дают ценности

Теги, авторы и даты часто создают десятки страниц с почти одинаковым набором записей. Если на сайте нет редакционной логики для этих архивов, их лучше закрыть от индексации или удалить из карты сайта. Здесь часто помогает плагин уровня Clearfy Pro, если нужен быстрый контроль дублей и технической чистки без ручного кода: Clearfy Pro.

Но если у вас кастомная тема или сложная структура, лучше понимать, что именно происходит на уровне шаблонов и хуков.

3. Настройте canonical для пагинации и фильтров

Для страниц пагинации canonical обычно должен указывать на саму страницу пагинации, а не на первую страницу архива. Иначе вы рискуете обнулить смысл второй и последующих страниц. Для URL с параметрами фильтра чаще нужен canonical на чистую категорию или на основную страницу каталога, если фильтр не создаёт уникальный контент.

Пример: если у вас есть фильтр по цвету, который не меняет смысл страницы, а только сортирует или сужает выдачу, canonical на базовый URL обычно безопаснее, чем индексировать все комбинации параметров.

4. Закройте мусорные параметры через `noindex` и редиректы

Параметры комментариев, сортировки и служебные query string лучше не оставлять на волю случая. Для некоторых URL достаточно noindex,follow, для других — 301-редиректа на чистую страницу. Редирект предпочтительнее, если параметр не нужен пользователю вообще.

Ниже пример, как можно убрать из индекса страницы с replytocom и некоторые служебные параметры через wp_head. Это не панацея, но в реальных проектах помогает быстро навести порядок:

add_action('wp_head', function () {
    if (is_admin()) {
        return;
    }

    $blocked_params = array('replytocom', 'sort', 'filter');

    foreach ($blocked_params as $param) {
        if (isset($_GET[$param])) {
            echo '<meta name="robots" content="noindex,follow" />' . "\n";
            break;
        }
    }
}, 1);

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

add_action('template_redirect', function () {
    if (is_admin()) {
        return;
    }

    if (isset($_GET['replytocom']) || isset($_GET['sort'])) {
        wp_safe_redirect(remove_query_arg(array('replytocom', 'sort')), 301);
        exit;
    }
});

Когда лучше плагин, а когда код

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

Подход	Когда подходит	Минус
Плагин SEO/чистки	Быстро закрыть теги, авторов, вложения, параметры	Не всегда видно, что именно изменилось
Код в теме или mu-plugin	Нужны точечные правила для конкретных URL	Требует тестирования после обновлений
Редиректы на сервере	Нужно убрать технические дубли до загрузки WordPress	Можно случайно сломать нужные параметры

Проверка результата после внедрения

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

проверьте HTML нескольких страниц через view-source: или curl;
убедитесь, что у дублей стоит нужный canonical;
посмотрите, что страницы с параметрами отдают 301 или noindex;
перепроверьте XML-карту сайта: там не должно быть закрытых URL;
в Search Console отправьте на переобход важные страницы и посмотрите, как меняется статус.

Если используете краулер, сравните список URL до и после. Важный признак успеха — сокращение количества страниц с одинаковым контентом и исчезновение мусорных параметров из отчётов об индексировании.

Частые ошибки и как их исправить

Ставят `noindex` на всё подряд

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

Ломают canonical на пагинации

Если все страницы архива указывают canonical на первую страницу, вторая и последующие могут выпадать из индекса даже тогда, когда они нужны. Для пагинации canonical должен быть логичным и последовательным, а не «на всякий случай на главную».

Редиректят параметры без проверки

Иногда параметр нужен для функционала: сортировка, язык, состояние формы. Если без разбора отправить всё на 301, можно сломать фильтры, поиск и пользовательские сценарии. Перед редиректом проверьте, влияет ли параметр на уникальность контента или только на интерфейс.

Оставляют в sitemap всё подряд

Если закрытая страница остаётся в карте сайта, вы посылаете поисковику противоречивые сигналы. Sitemap должен содержать только те URL, которые вы действительно хотите индексировать.

Безопасность и производительность

Любые правки в functions.php лучше сначала вынести в mu-plugin или отдельный мини-плагин. Так вы не потеряете настройки при смене темы и не привяжете SEO-логику к шаблону. Для редиректов и фильтрации параметров не используйте тяжёлые запросы к базе на каждом хите: проверяйте только $_GET и контекст запроса.

Если дублей много, а сайт старый, сначала снимите карту проблем: какие типы архивов индексируются, какие параметры реально встречаются, какие URL уже попали в индекс. После этого правки будут точечными, а не «на удачу».

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