Как исправить canonical и переадресацию на страницах фильтров WordPress

Автор: Наталья Новикова | Опубликовано: 28.09.2026

Если в индексе у вас внезапно появляются десятки почти одинаковых URL с параметрами вроде ?sort=, ?filter=, ?page= или ?orderby=, проблема обычно не в поисковике, а в том, как тема, плагин или сервер обрабатывают канонические адреса и редиректы. На небольшом сайте это выглядит как «мусор в индексе», на большом — как распыление сигналов и лишняя нагрузка на обход.

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

Как выглядит проблема на практике

Чаще всего симптомы такие:

в поиске находятся URL с параметрами, хотя они должны быть служебными;
основная страница архива имеет canonical на саму себя, а параметрические варианты — на разные адреса или вообще без canonical;
страницы сортировки и фильтров отдают 200 OK и попадают в индекс;
после перехода по старому URL с параметром срабатывает 301 на неожиданный адрес;
в Search Console появляются дубли по выбранному каноническому URL.

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

Диагностика: что именно ломается

Сначала проверьте поведение без догадок. Откройте проблемный URL и посмотрите три вещи: код ответа, заголовок Location при редиректе и тег <link rel="canonical"> в HTML.

Проверка через curl

curl -I https://example.com/category/news/?sort=popular

Если ответ 301 или 302, смотрите, куда уходит редирект. Если ответ 200, но canonical указывает не на базовую страницу, проблема в теме, SEO-плагине или кастомном коде.

Полезно сравнить несколько вариантов одного и того же архива:

curl -s https://example.com/category/news/ | grep -i canonical
curl -s 'https://example.com/category/news/?sort=popular' | grep -i canonical
curl -s 'https://example.com/category/news/?page=2' | grep -i canonical

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

Что проверить в админке и коде

SEO-плагин: не переопределяет ли он canonical для архивов и таксономий.
Тема: нет ли собственного вывода rel=canonical в header.php или через хук wp_head.
Плагины фильтрации: не создают ли они отдельные URL для сортировки и пагинации без нужной настройки.
Редиректы: не настроены ли правила в .htaccess, nginx или через плагин редиректов.

Как исправить canonical для параметрических страниц

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

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

add_filter('get_canonical_url', function ($canonical, $post) {
    if (is_admin() || empty($canonical)) {
        return $canonical;
    }

    if (is_archive() || is_tax() || is_category() || is_tag()) {
        $base = home_url(add_query_arg([], $GLOBALS['wp']->request));
        return remove_query_arg(array('sort', 'orderby', 'filter', 'page'), $base);
    }

    return $canonical;
}, 10, 2);

Этот код не универсален для всех сайтов, но показывает принцип: canonical должен строиться от базового URL, а не от текущей строки запроса. Если у вас уже есть SEO-плагин, сначала проверьте, не делает ли он это сам. Дублировать логику не стоит.

Когда canonical лучше не трогать кодом

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

плагин не умеет исключать конкретные параметры;
тема подменяет canonical после SEO-плагина;
нужно точечно исправить только один тип архивов.

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

Как убрать лишние редиректы без потери нужных URL

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

Подход	Когда подходит	Минус
Плагин SEO/фильтрации	Есть готовая настройка canonical и noindex	Не всегда учитывает кастомные параметры
Код через фильтры WordPress	Нужно точечно исправить конкретный архив	Требует тестирования после обновлений
Редирект на сервере	Параметр всегда лишний и не нужен пользователю	Можно случайно сломать сортировку и пагинацию

Если вы решаете именно редирект, не делайте его «в лоб» для всех URL с вопросительным знаком. Это частая ошибка. Например, ?page=2 на архиве — это не дубль, а часть навигации. А вот ?sort=popular часто можно свести к базовому URL.

Пример безопасной логики на PHP: редиректить только конкретный параметр, а остальные оставить как есть.

add_action('template_redirect', function () {
    if (is_admin() || !isset($_GET['sort'])) {
        return;
    }

    $allowed = array('popular', 'new');
    $sort = sanitize_text_field(wp_unslash($_GET['sort']));

    if (!in_array($sort, $allowed, true)) {
        wp_safe_redirect(remove_query_arg('sort'), 301);
        exit;
    }
});

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

Пошаговое решение без лишнего риска

Соберите список проблемных URL из Search Console, логов сервера или краулера.
Проверьте код ответа и canonical для каждого типа URL.
Определите источник: SEO-плагин, тема, плагин фильтрации или серверный редирект.
Для параметров, которые не нужны поиску, задайте canonical на чистую страницу.
Для параметров, которые вообще не должны открываться, настройте точечный 301 или 410.
Перепроверьте, не ломается ли пагинация и не исчезают ли нужные страницы из обхода.

Как проверить, что исправление сработало

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

HTTP-ответ: проблемный URL должен отдавать ожидаемый код — 200, 301 или 410.
Canonical: на странице должен быть один тег rel="canonical", и он должен вести на правильный URL.
Индексация: через несколько обходов поисковик должен перестать считать параметрические URL отдельными страницами.

Проверить canonical можно и через исходный код, и через командную строку:

curl -s 'https://example.com/category/news/?sort=popular' | grep -i 'rel="canonical"'

Если редирект настроен правильно, команда ниже должна показывать ожидаемый адрес в Location:

curl -I 'https://example.com/category/news/?sort=popular'

В Search Console изменения обычно видны не сразу, поэтому ориентируйтесь сначала на техническую проверку, а уже потом на отчёты по индексации.

Частые ошибки и почему они возникают

Редирект всех параметров на главную

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

Два canonical на одной странице

Один тег выводит SEO-плагин, второй — тема или кастомный код. Поисковик обычно игнорирует лишнее, но сам факт конфликта говорит о плохой архитектуре. Нужно оставить один источник правды.

Путаница между noindex и canonical

noindex не заменяет canonical. Если страница должна быть исключена из поиска, но при этом передавать сигнал на основную версию, сначала определите цель. Для служебных URL иногда достаточно canonical, для мусорных параметров — лучше закрытие от индексации или редирект.

Слепая правка .htaccess

На Apache это удобно, но легко задеть пагинацию, фильтры и даже служебные запросы плагинов. Если правило нужно только для одного параметра, лучше начать с PHP-логики или настроек плагина, а не с глобального rewrite.

Что учесть для безопасности и производительности

Любая логика, которая читает $_GET, должна валидировать входные данные. Иначе вы получите не только SEO-проблему, но и лишний риск для шаблона. Используйте sanitize_text_field(), wp_unslash() и, где уместно, белый список допустимых значений.

С точки зрения производительности не плодите тяжёлые проверки на каждом запросе. Если правило касается только архивов, ограничьте его условием is_archive() или конкретной таксономией. Чем меньше лишней логики в template_redirect и wp_head, тем проще сопровождать сайт после обновлений.

Если у вас много служебных дублей по разным причинам — canonical, архивы, пагинация, лишние мета-теги, — имеет смысл сначала навести порядок в технической базе сайта. В таких сценариях часто помогает связка настроек SEO и чистки дублей, а не точечные костыли в шаблоне.

Когда лучше остановиться и не усложнять

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

Премиум шаблоны для WordPress Купить плагины для WordPress