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

Страницы с параметрами в WordPress часто появляются незаметно: UTM-метки из рекламы, сортировки, фильтры, внутренний поиск, служебные query string. Для пользователя это одна и та же страница, а для поисковика — десятки вариантов URL. В итоге в индексе копятся мусорные адреса, а в отчётах Search Console растёт число «просканировано, но не проиндексировано».

Задача здесь не в том, чтобы закрыть всё подряд. Нужен точный контроль: какие параметры можно оставить для аналитики, какие лучше убрать из индекса, а какие вообще не должны попадать в выдачу и в кэш.

Как понять, что проблема именно в параметрах URL

Сначала проверьте, действительно ли поисковик индексирует вариации одной и той же страницы. Откройте несколько URL с параметрами и сравните:

• одинаковый ли у них основной контент;
• меняется ли только сортировка, фильтр или метка кампании;
• есть ли у страницы канонический URL;
• не создаёт ли сайт отдельные архивы для параметров.

Типичные примеры:

• ?utm_source=... и другие рекламные метки;
• ?sort=price, ?orderby=date;
• ?filter_color=red, ?size=m;
• ?s=... — внутренний поиск;
• ?replytocom=... — старые ссылки на комментарии.

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

Что закрывать, а что оставлять

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

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

Пошаговое решение через код

Ниже пример, который добавляет noindex, follow для страниц с типичными служебными параметрами. Код можно положить в functions.php дочерней темы или в небольшой mu-plugin.

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

    $params = array('utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'sort', 'orderby', 'filter_color', 'filter_size', 'replytocom');

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

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

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

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

    $remove = array('utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'sort', 'orderby', 'filter_color', 'filter_size', 'replytocom');
    $query = $_GET;

    foreach ($remove as $key) {
        unset($query[$key]);
    }

    $path = strtok(home_url(add_query_arg(array(), $_SERVER['REQUEST_URI'])), '?');

    return empty($query) ? $path : $canonical;
});

Этот пример рассчитан на Yoast SEO, потому что фильтр wpseo_canonical у него реальный. Если у вас другой SEO-плагин, логика та же, но хук будет отличаться. В таком случае проще оставить canonical на уровне шаблона и не пытаться «перехватить» всё через фильтр.

Если нужен контроль без кода

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

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

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

После правок не ограничивайтесь просмотром исходника. Проверьте решение по шагам:

1. Откройте URL с параметром в браузере и убедитесь, что в <head> появился noindex, follow.
2. Проверьте canonical: он должен вести на чистую страницу без служебных параметров.
3. Посмотрите, не создаёт ли кэш отдельную версию для каждого query string.
4. Отправьте URL на проверку в Search Console и сравните, как он видится роботу.
5. Через несколько дней проверьте отчёт по индексированию и список просканированных URL.

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

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

Ставят noindex на все страницы с параметрами без разбора

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

Оставляют параметр в canonical

Тогда поисковик всё равно видит разные URL как отдельные варианты. Canonical должен указывать на основную страницу, а не на текущий адрес с хвостом из query string.

Закрывают URL только в robots.txt

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

Не учитывают кэш

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

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

Не храните список параметров в случайных местах и не дублируйте логику в нескольких плагинах. Чем больше слоёв вмешательства, тем выше шанс получить конфликт. Если решение делаете кодом, вынесите его в отдельный мини-плагин или mu-plugin, чтобы оно не зависело от темы.

Для производительности полезно ещё и сократить генерацию мусорных URL на уровне шаблона: не добавлять UTM во внутренние ссылки, не строить лишние сортировки в меню, не плодить отдельные страницы для каждого микрофильтра, если они не нужны в поиске.

Если нужен быстрый аудит дублей, технической чистки и индексации, можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но сам принцип остаётся тем же: сначала определить, какие URL должны жить, а какие — только мешают индексации.

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

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

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