Как исключить параметры URL из индексации в WordPress без потери нужных страниц

Параметры в URL — частая причина технических дублей в WordPress. Один и тот же материал может открываться с разными хвостами вроде ?utm_source=, ?replytocom=, ?sort= или фильтрами поиска. Для пользователя это одна страница, а для поисковика — несколько разных адресов. Если не разрулить это на уровне шаблона, каноникализации и индексации, в индексе начинают жить лишние версии страниц.

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

Когда проблема уже есть: как ее распознать

Обычно сигналов несколько. В Search Console появляются URL с одинаковым контентом, но разными параметрами. В логах обхода видны повторные заходы на те же страницы с хвостами. В выдаче всплывают адреса с ?utm_, ?fbclid= или внутренними параметрами сортировки. Иногда проблема заметна и без инструментов: в поиске по сайту находятся одинаковые записи по разным URL.

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

• ?replytocom= в комментариях;
• ?utm_*, ?gclid=, ?fbclid= из рекламных и социальных переходов;
• параметры сортировки и фильтров в каталогах и архивах;
• параметры поиска по сайту, если они индексируются;
• служебные хвосты, которые добавляют темы, плагины или трекеры.

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

Что делать: выбрать правильную реакцию для каждого параметра

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

Шаг 1. Определите, какие параметры реально нужны

Не начинайте с массовой блокировки в robots.txt. Сначала выпишите параметры и разделите их на три группы:

• нужны пользователю — например, сортировка в каталоге;
• нужны для аналитики — UTM-метки, рекламные клики;
• не нужны никому — мусорные хвосты, которые создают одинаковые страницы.

Для WordPress чаще всего безопасно оставлять доступными UTM-параметры, но канонизировать их на чистый URL. А вот внутренний поиск, если он не несет SEO-ценности, обычно лучше закрывать от индексации.

Шаг 2. Добавьте canonical для параметров, которые не должны быть отдельными страницами

Если у вас есть страницы, которые открываются с параметрами, но контент у них тот же, canonical должен указывать на чистый адрес. В WordPress это можно сделать через фильтр wpseo_canonical, если используется Yoast SEO, или через свой вывод <link rel="canonical"> в wp_head, если вы управляете шаблоном вручную.

Пример для темы или мини-плагина: убираем UTM и похожие маркетинговые параметры из canonical, но не ломаем сам URL для пользователя.

<?php
add_filter( 'wpseo_canonical', function( $canonical ) {
    if ( is_admin() ) {
        return $canonical;
    }

    if ( empty( $_SERVER['REQUEST_URI'] ) ) {
        return $canonical;
    }

    $url = home_url( add_query_arg( array(), wp_unslash( $_SERVER['REQUEST_URI'] ) ) );
    $parts = wp_parse_url( $url );

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

    parse_str( $parts['query'], $query );

    foreach ( array_keys( $query ) as $key ) {
        if ( 0 === strpos( $key, 'utm_' ) || in_array( $key, array( 'gclid', 'fbclid' ), true ) ) {
            unset( $query[ $key ] );
        }
    }

    $clean = remove_query_arg( array_keys( $_GET ), home_url( $parts['path'] ) );

    if ( ! empty( $query ) ) {
        $clean = add_query_arg( $query, $clean );
    }

    return $clean;
} );

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

Шаг 3. Закройте от индексации страницы, которые не должны ранжироваться

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

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

<?php
add_filter( 'wpseo_robots', function( $robots ) {
    if ( is_search() ) {
        return 'noindex,follow';
    }

    return $robots;
} );

Важно: не закрывайте такие URL в robots.txt, если поисковику нужно увидеть noindex. Если робот не может зайти на страницу, он не увидит мета-тег и может дольше держать URL в индексе как «известный, но недоступный».

Шаг 4. Для мусорных параметров используйте нормализацию или редирект

Если параметр не нужен вообще, лучше убрать его на уровне ответа сервера или WordPress-роутинга. Например, можно редиректить URL с fbclid и gclid на чистый адрес, если это не ломает аналитику и не мешает рекламным системам.

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

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

    foreach ( $remove as $param ) {
        if ( isset( $_GET[ $param ] ) ) {
            $has_bad_param = true;
            break;
        }
    }

    if ( ! $has_bad_param ) {
        return;
    }

    $clean_url = remove_query_arg( $remove );
    wp_safe_redirect( $clean_url, 301 );
    exit;
} );

Такой редирект стоит применять осторожно. Если рекламная платформа или аналитика завязаны на параметр, сначала проверьте, не потеряете ли вы данные атрибуции. Для UTM чаще достаточно canonical, а не редиректа.

Диагностика перед внедрением: что проверить до правок

Перед изменениями посмотрите, где именно живут параметры. Это можно сделать без тяжелых инструментов:

• откройте несколько URL с параметрами и сравните <title>, canonical и robots;
• проверьте исходный код страницы в браузере;
• посмотрите отчеты Search Console по страницам с дублирующимся контентом;
• сравните ответы сервера для чистого URL и URL с параметром через curl -I;
• проверьте, не генерирует ли параметр отдельную страницу в карте сайта.

Пример быстрой проверки заголовков:

curl -I 'https://example.com/post/?utm_source=test'
curl -I 'https://example.com/post/'

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

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

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

• в исходном коде параметрический URL содержит canonical на чистую страницу;
• страницы поиска и другие служебные URL отдают noindex,follow;
• в Search Console новые версии URL перестают накапливаться как отдельные страницы;
• при повторном обходе робот видит основную версию, а не набор дублей;
• внутренние ссылки на сайте не ведут на URL с мусорными параметрами.

Если используете кэш, очистите его после правок. Иначе можно проверять старую версию шаблона и решить, что код не работает.

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

Закрыли параметры в robots.txt и ждали, что дубли исчезнут

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

Поставили noindex на все страницы с параметрами подряд

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

Сделали редирект на каждый параметр без проверки

Редирект на чистый URL удобен, но может сломать аналитику, A/B-тесты и рекламные переходы. Если параметр нужен только для трекинга, чаще безопаснее canonical. Если параметр мусорный и не нужен никому — тогда редирект оправдан.

Не обновили внутренние ссылки

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

Безопасность и производительность: что имеет смысл учесть

Любая логика на основе $_GET должна быть аккуратной. Не доверяйте параметрам как данным для SQL или для прямой подстановки в HTML. Если строите собственную нормализацию URL, используйте функции WordPress для работы с адресами и экранирование там, где это нужно.

С точки зрения производительности лучше не городить сложную обработку на каждом запросе. Если параметров немного, проверка в template_redirect или фильтре canonical не создаст проблемы. Но если у вас крупный проект с фильтрами, сортировками и поиском, часть логики лучше вынести в плагин или в уже существующий SEO-инструмент. В таких случаях удобно использовать решения уровня Clearfy Pro, если вам нужно централизованно управлять дублями и техническими настройками сайта: https://wpshop.ru/plugins/clearfy.

И еще один практический момент: если у вас есть кэш на уровне сервера или CDN, проверьте, не кэшируются ли параметрические URL как отдельные страницы. Иначе вы можете исправить canonical, но при этом продолжать раздавать старые версии из кэша.

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

• определены все параметры, которые создают дубли;
• для маркетинговых меток настроен canonical на чистый URL;
• для служебных страниц с низкой ценностью добавлен noindex,follow;
• мусорные параметры либо редиректятся, либо игнорируются;
• внутренние ссылки не генерируют лишние query string;
• кэш очищен, а изменения проверены в исходном коде страницы;
• Search Console и серверные логи взяты в контроль после внедрения.

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