Как закрыть от индексации страницы с параметрами в WordPress без поломки SEO

Автор: Вера Крылова | Опубликовано: 20.08.2026

Проблема с URL вида ?sort=, ?filter=, ?utm_ или другими параметрами обычно всплывает не сразу. На сайте уже есть трафик, в Search Console появляются странные адреса, а в индексе копятся страницы, которые не должны ранжироваться отдельно. Если закрывать это грубо, можно случайно убрать из поиска нужные страницы. Поэтому здесь важен не «запретить всё подряд», а аккуратно разделить: что индексировать, что склеивать, а что оставлять только для пользователя.

Когда это действительно проблема

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

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

Что не стоит делать сразу

Частая ошибка — закрыть всё через robots.txt. Это не решает проблему дублей, если URL уже известны поисковику. Ещё хуже — массово ставить noindex на все страницы с параметрами без разбора: можно задеть полезные посадочные страницы, которые реально должны индексироваться. Нужна точечная схема.

Диагностика: какие параметры можно закрывать, а какие нет

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

трекинговые — utm_source, utm_medium, gclid, fbclid;
сортировка и фильтры — sort, filter, price, color;
служебные — replytocom, некоторые параметры поиска, технические флаги;
контентные — параметры, которые реально меняют страницу и могут быть полезны для индексации.

Если параметр не меняет смысл страницы для поиска, его обычно не нужно индексировать. Если меняет — сначала проверьте, не лучше ли сделать отдельную ЧПУ-страницу или канонический URL.

Рабочие варианты решения

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

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

Пошаговое решение через `noindex` и canonical

Если у вас есть страницы с параметрами, которые должны работать для пользователя, но не должны индексироваться отдельно, логичнее всего добавить noindex, follow и канонический URL на чистую версию страницы. Это не универсальный рецепт, но для большинства фильтров и сортировок он безопаснее, чем жёсткая блокировка.

Шаг 1. Определите список параметров

Не пытайтесь обрабатывать вообще все параметры. Начните с конкретного списка: например, utm_*, gclid, fbclid, sort, filter. Для каждого параметра решите, что с ним делать: игнорировать, закрывать от индексации или редиректить.

Шаг 2. Добавьте условный `noindex` в `wp_head`

Ниже пример для темы или небольшого плагина. Он ставит noindex, follow на страницы с выбранными параметрами. Код не трогает обычные URL без параметров.

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

    $params = array('sort', 'filter', 'gclid', 'fbclid');
    $has_param = false;

    foreach ($params as $param) {
        if (isset($_GET[$param]) && $_GET[$param] !== '') {
            $has_param = true;
            break;
        }
    }

    if ($has_param) {
        echo "<meta name=\"robots\" content=\"noindex, follow\" />\n";
    }
}, 1);

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

Шаг 3. Укажите canonical на чистый URL

Для страниц с параметрами полезно указывать канонический адрес без query string. Это помогает поисковику понять, какая версия основная.

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

    $params = array('sort', 'filter', 'gclid', 'fbclid');
    foreach ($params as $param) {
        if (isset($_GET[$param]) && $_GET[$param] !== '') {
            return remove_query_arg($params, $canonical);
        }
    }

    return $canonical;
}, 10, 2);

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

Если параметр мусорный — лучше убрать его из URL

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

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

    $remove = array('gclid', 'fbclid');
    $has_remove = false;

    foreach ($remove as $param) {
        if (isset($_GET[$param]) && $_GET[$param] !== '') {
            $has_remove = true;
            break;
        }
    }

    if ($has_remove) {
        wp_safe_redirect(remove_query_arg($remove), 301);
        exit;
    }
});

Для utm_* параметров редирект не всегда обязателен. Если аналитика настроена корректно, их можно оставить на входе и просто не пускать в индекс. Но если сайт генерирует слишком много мусорных URL, редирект помогает навести порядок.

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

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

Откройте URL с параметром и проверьте исходный код страницы: должен быть noindex, follow, если вы его добавляли.
Убедитесь, что canonical указывает на чистый URL без лишних параметров.
Проверьте редирект через curl -I или любой HTTP-клиент: если параметр должен удаляться, ответ должен быть 301.
В Search Console посмотрите, уменьшается ли число параметрических URL в отчётах по страницам и сканированию.
Проверьте, не исчезли ли из индекса полезные посадочные страницы, если у вас были исключения.

Пример проверки заголовков:

curl -I "https://example.com/page/?gclid=test"

Если вы настроили редирект, в ответе должен быть 301 и новый Location без параметра. Если редиректа нет, но есть noindex, убедитесь, что он действительно попадает в HTML-ответ, а не только в кэш старой версии страницы.

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

Закрыли параметры в robots.txt

Это не убирает уже известные URL из индекса. Поисковик может продолжать видеть адрес, но не сможет нормально переобойти страницу и увидеть noindex или canonical. Если цель — убрать дубли, robots.txt сам по себе не решает задачу.

Поставили `noindex` на все страницы с query string

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

Сделали редирект и потеряли аналитику

Если вы удаляете utm_* до того, как аналитика успела их прочитать, отчёты станут неполными. Обычно такие параметры лучше не редиректить на уровне сервера без понимания, как у вас устроен сбор данных. Для рекламных меток сначала проверьте, не ломает ли редирект атрибуцию.

Каноникал указывает на несуществующий или неподходящий URL

Это бывает после фильтрации параметров через remove_query_arg(), если базовый URL собран неправильно. Проверяйте canonical на реальной странице, а не только в коде. Особенно это важно для архивов, пагинации и страниц с нестандартными шаблонами.

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

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

Не используйте необработанные значения из $_GET в выводе без проверки.
Не добавляйте редиректы на каждый неизвестный параметр — это может создать петли и лишние запросы.
Проверяйте, как параметрические URL попадают в кэш: иногда нужно исключить их из кэширования на уровне сервера или плагина.
Если SEO-задача сложная, удобнее вынести правила в отдельный мини-плагин, а не держать их в теме.

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

Короткий чек-лист перед публикацией

Список параметров составлен и разделён по типам.
Для мусорных параметров настроен 301-редирект или очистка URL.
Для полезных параметрических страниц добавлен noindex, follow.
Canonical указывает на основную версию страницы.
Проверен исходный код страницы и HTTP-ответ.
В Search Console нет признаков массового выпадения нужных страниц.
Кэш не отдаёт старую версию без изменений.

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