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

Проблема с параметрами в URL обычно всплывает не в теории, а после очередной проверки в Search Console: в индексе появляются адреса с ?sort=, ?filter=, ?replytocom=, UTM-метками и другими хвостами. Для поисковика это часто отдельные URL, а для сайта — дубли, распыление обхода и лишняя нагрузка на сервер.

Сразу важная оговорка: не все параметры нужно закрывать. Если параметр меняет содержимое страницы и реально нужен пользователю, его нельзя просто массово запретить. Работать нужно точечно: сначала понять, какие URL индексируются, потом выбрать способ — canonical, noindex, правила в robots.txt или серверная нормализация.

Диагностика: какие параметры реально создают проблему

Начинать стоит не с правок в robots.txt, а с проверки, какие именно адреса уже попали в индекс и как они отдаются сервером. В WordPress чаще всего встречаются такие сценарии:

• ?replytocom= у комментариев;
• ?utm_, ?gclid=, ?yclid= и другие маркетинговые метки;
• ?sort=, ?orderby=, ?filter= в каталогах, архивах и списках записей;
• ?amp или другие служебные параметры, если они настроены нестандартно;
• параметры поиска, например ?s=, если они массово индексируются.

Проверка простая: откройте проблемный URL с параметром и посмотрите, меняется ли контент, title, canonical и robots meta. Если страница визуально та же, а URL другой — это кандидат на склейку или запрет индексации.

Что смотреть в первую очередь

• отчет «Страницы» в Google Search Console;
• сниппеты с параметрами в результатах поиска;
• логи сервера, если есть подозрение на лишний обход;
• исходный код страницы: rel="canonical", meta name="robots", редиректы.

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

Какой способ выбрать: canonical, noindex или robots.txt

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

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

Пошаговое решение в WordPress

1. Уберите мусорные параметры на уровне генерации ссылок

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

<?php
// Убираем UTM-параметры из внутренних ссылок в контенте, если они случайно попали в разметку.
add_filter('the_content', function ($content) {
    $content = preg_replace('/([?&])(utm_[^=]+|gclid|yclid)=[^&\"\']+/i', '', $content);
    $content = preg_replace('/\?&/', '?', $content);
    return $content;
});

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

2. Отдавайте canonical на чистую страницу

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

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

    $uri = $_SERVER['REQUEST_URI'] ?? '';
    if (strpos($uri, '?') === false) {
        return $canonical;
    }

    $url = home_url(add_query_arg([], $GLOBALS['wp']->request ?? ''));
    return strtok($url, '?');
});

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

3. Закрывайте только служебные параметры через noindex

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

<?php
add_action('wp_head', function () {
    if (empty($_GET['sort']) && empty($_GET['filter']) && empty($_GET['replytocom'])) {
        return;
    }

    echo '<meta name="robots" content="noindex,follow">' . "\n";
}, 1);

Здесь важен смысл: follow оставляет роботам возможность ходить по ссылкам, а noindex не дает странице закрепиться в индексе. Но если параметр нужен для полноценной посадочной страницы, такой подход уже не подойдет.

4. Для совсем лишних параметров делайте 301 на чистый URL

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

<?php
add_action('template_redirect', function () {
    if (empty($_SERVER['REQUEST_URI'])) {
        return;
    }

    $request_uri = $_SERVER['REQUEST_URI'];
    $parsed = wp_parse_url(home_url($request_uri));

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

    parse_str($parsed['query'], $query);
    $blocked = ['gclid', 'yclid', 'utm_source', 'utm_medium', 'utm_campaign'];

    foreach ($blocked as $param) {
        if (isset($query[$param])) {
            wp_safe_redirect(remove_query_arg($blocked), 301);
            exit;
        }
    }
});

Не применяйте такой редирект ко всем параметрам без разбора. Если в URL есть ?s=, ?paged= или параметр фильтра, который нужен для работы сайта, редирект сломает навигацию.

Когда robots.txt уместен, а когда нет

robots.txt полезен для экономии обхода, но это не инструмент для «удаления из индекса». Если вы закроете параметр в robots.txt, поисковик может продолжать помнить URL, но не увидит содержимое страницы и не сможет нормально обработать canonical или noindex.

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

Если нужен точечный запрет, можно добавить правило на конкретный путь, но не на все URL с вопросительным знаком — в robots.txt это работает не так, как многие ожидают.

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

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

1. Откройте URL с параметром в браузере и проверьте, не происходит ли редирект на чистый адрес.
2. Посмотрите исходный код страницы: есть ли canonical на базовый URL и не появился ли noindex там, где он не нужен.
3. Проверьте ответ сервера через curl или DevTools.

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

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

Что должно измениться

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

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

Ошибка 1: закрыли все параметры в robots.txt. В результате робот не видит содержимое страницы и не может понять, что это дубль. Исправление: вернуть доступ для обхода и решить вопрос через canonical, noindex или редирект.

Ошибка 2: поставили noindex на страницу, которая должна ранжироваться. Так часто ломают фильтры и полезные посадочные страницы. Исправление: разделить параметры на служебные и SEO-значимые.

Ошибка 3: редиректят все URL с вопросительным знаком. Это ломает поиск по сайту, пагинацию и сортировку. Исправление: редиректить только заранее известные мусорные параметры.

Ошибка 4: canonical указывает на URL с параметром. Тогда поисковик получает сигнал, что дубль — это и есть основная версия. Исправление: canonical должен вести на чистый адрес без лишнего хвоста.

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

Практические советы по безопасности и производительности

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

• не генерируйте уникальные URL для каждого маркетингового перехода внутри сайта;
• не храните UTM в постоянных внутренних ссылках;
• проверяйте, не ломает ли кэш разные варианты одного и того же URL;
• не ставьте сложную логику в wp_head, если можно решить вопрос на уровне шаблона или SEO-плагина;
• для массовой чистки дублей сначала делайте бэкап и тест на staging.

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

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