Как убрать дубли страниц от фильтров и сортировки в WordPress без потери индексации

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

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

Когда дубли появляются именно из-за фильтров и сортировки

Типичный сценарий: у вас есть каталог записей, рубрика или архив, а фильтры добавляют параметры вроде ?sort=price, ?color=blue, ?page=2 или несколько параметров сразу. Если каждая комбинация получает отдельный индексируемый URL, поисковик начинает видеть не одну страницу, а набор почти одинаковых страниц.

Особенно часто это происходит, если:

  • фильтр меняет только порядок вывода, а не смысл страницы;
  • параметры попадают в <title> и meta description без логики;
  • канонический URL не учитывает базовую страницу без параметров;
  • в sitemap случайно попадают URL с параметрами;
  • сервер отдает одинаковый контент на разные адреса без явного сигнала поисковику.

Диагностика: какие URL уже стали дублями

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

Что проверить вручную

  • Откройте несколько страниц с фильтрами и сортировкой.
  • Посмотрите исходный код: есть ли rel="canonical" и куда он указывает.
  • Проверьте, меняется ли <title> при смене параметров.
  • Сравните HTML разных URL: если контент почти одинаковый, это кандидат на склейку или закрытие от индексации.

Что проверить в Search Console и логах

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

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

Как выбрать стратегию: закрыть, склеить или оставить

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

ПодходКогда использоватьМинус
Canonical на базовую страницуЕсли параметры меняют только сортировку или второстепенный видНе всегда быстро убирает уже проиндексированные URL
noindex, followЕсли страница полезна пользователю, но не нужна в поискеНужно аккуратно следить за мета-тегами и robots
Закрытие в robots.txtДля технических параметров и бесполезных комбинацийНе удаляет URL из индекса мгновенно, если они уже там есть
Нормализация URL в кодеЕсли фильтр генерирует слишком много комбинацийТребует разработки и тестирования

Пошаговое решение на уровне темы или плагина

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

<?php
add_filter('get_canonical_url', function ($canonical, $post) {
    if (is_admin() || ! is_singular() && ! is_archive()) {
        return $canonical;
    }

    $params_to_strip = ['sort', 'order', 'view'];

    if (empty($_GET)) {
        return $canonical;
    }

    $current_url = home_url(add_query_arg([], $_SERVER['REQUEST_URI']));
    $parsed = wp_parse_url($current_url);

    if (empty($parsed['query'])) {
        return $canonical;
    }

    parse_str($parsed['query'], $query_args);

    foreach ($params_to_strip as $key) {
        unset($query_args[$key]);
    }

    $base_url = remove_query_arg(array_keys($query_args), $current_url);

    return $base_url ? $base_url : $canonical;
}, 10, 2);

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

    $technical_params = ['sort', 'order'];

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

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

Если фильтр строится через pre_get_posts

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

<?php
add_action('pre_get_posts', function ($query) {
    if (is_admin() || ! $query->is_main_query()) {
        return;
    }

    if ($query->is_post_type_archive('post') && isset($_GET['sort'])) {
        $allowed = ['date', 'title'];
        $sort = sanitize_key($_GET['sort']);

        if (! in_array($sort, $allowed, true)) {
            $sort = 'date';
        }

        if ($sort === 'title') {
            $query->set('orderby', 'title');
            $query->set('order', 'ASC');
        } else {
            $query->set('orderby', 'date');
            $query->set('order', 'DESC');
        }
    }
});

Здесь важен не только сам фильтр, но и ограничение допустимых значений. Если принимать любые параметры, можно случайно создать бесконечное число URL с одинаковым или почти одинаковым контентом.

Как закрыть технические параметры через robots.txt и мета-теги

Если параметры не нужны для поиска вообще, их можно закрыть на уровне robots.txt. Но это не замена canonical: robots.txt помогает снизить обход, а canonical и meta robots помогают объяснить, какая версия основная.

Пример для типичных технических параметров:

User-agent: *
Disallow: /*?sort=
Disallow: /*?order=
Disallow: /*?view=

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

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

После правок нужно убедиться, что поисковик видит нужную версию страницы и не получает противоречивых сигналов.

  • Откройте URL с параметром и проверьте исходный код.
  • Убедитесь, что canonical указывает на базовую страницу или на нужную посадочную.
  • Проверьте, что на технических URL стоит noindex,follow, если это было задумано.
  • Сравните заголовки ответов и HTML для нескольких комбинаций параметров.
  • В Search Console отправьте на переобход ключевые страницы и посмотрите, как меняется статус индексации.

Если у вас есть доступ к командной строке, можно быстро проверить заголовки и canonical через curl:

curl -sL 'https://example.com/category/news/?sort=title' | grep -iE 'canonical|robots|title'

Если canonical не совпадает с ожидаемым URL, значит логика нормализации еще не сработала или ее перебивает SEO-плагин.

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

Canonical указывает на саму параметрическую страницу

Это самая частая проблема. Обычно она возникает, когда SEO-плагин берет текущий URL без нормализации. Исправление: явно формировать canonical для базовой версии и не полагаться на автоматическую логику, если URL строится фильтрами.

Закрыли URL в robots.txt, но они остались в индексе

Это нормально: robots.txt не удаляет уже известные поисковику страницы. Нужно дополнительно дать правильный canonical, при необходимости поставить noindex и дождаться переобхода.

Сломалась пагинация

Так бывает, если фильтр сбрасывает параметры страницы или неправильно собирает query string. Проверяйте, что paged не теряется при смене сортировки и что ссылки на следующую страницу не ведут на пустые результаты.

Все параметры закрыли одинаково

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

Практические советы по безопасности и производительности

Чем больше параметров принимает сайт, тем выше риск мусорных запросов и лишней нагрузки. Ограничивайте список разрешенных значений, используйте sanitize_key() или явные whitelist-массивы и не передавайте параметры напрямую в SQL.

Если фильтрация тяжелая, имеет смысл:

  • кешировать результаты запросов на уровне объекта или страницы;
  • не генерировать отдельные мета-данные для каждой сортировки;
  • не добавлять параметрические URL в XML sitemap;
  • проверять, не создает ли плагин фильтров лишние архивы и AJAX-страницы.

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

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

Как создать и использовать собственные виджеты в WordPress
30.11.2025
Как создать настройки темы WordPress в админке
26.11.2025
Как настроить X-Robots-Tag в WordPress для закрытия страниц от индексации
29.08.2026
Адаптивный фильтр товаров на WooCommerce: создание без плагинов
05.01.2026
Как использовать REST API в WordPress для создания собственных эндпоинтов
11.11.2025

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