Фильтры, сортировка и параметры в 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, и только после этого закрывайте лишнее от индексации. Так вы уберете дубли без потери нужных страниц в поиске.