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

Если на сайте начали всплывать в индексе URL вида ?utm_source=, ?sort=, ?replytocom= или другие параметры, проблема обычно не в одном «плохом» адресе, а в том, что поисковик видит много технических дублей одной и той же страницы. Для WordPress это типичный сценарий: часть параметров нужна для аналитики или интерфейса, а часть вообще не должна попадать в выдачу.

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

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

Сам по себе параметр не всегда вреден. Например, ?replytocom= часто появляется из-за комментариев, ?utm_* — из-за рекламных меток, а ?sort= или ?filter= — из-за сортировки и фильтров. Проблема начинается, когда:

• одна и та же страница доступна по десяткам вариантов URL;
• внутренние ссылки ведут на адреса с параметрами;
• поисковик тратит краулинговый бюджет на мусорные версии;
• в индексе появляются страницы без самостоятельной ценности.

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

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

Сначала не трогайте код. Посмотрите, какие URL уже попали в поиск и откуда они взялись. Это можно сделать вручную и через Search Console.

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

• Поиск по сайту в Google с оператором site:example.com inurl:?.
• Отчёт по страницам в Google Search Console: ищите URL с параметрами.
• Сырые логи сервера, если есть доступ: какие параметры чаще всего запрашиваются ботами.
• Внутренние ссылки в теме и плагинах: не генерируют ли они адреса с хвостами.

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

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

Универсального рецепта нет. Для разных типов параметров работают разные подходы. Вот короткое сравнение.

Для параметров вроде utm_* и служебных хвостов обычно лучше сочетать каноникал на чистый URL и запрет на индексацию через мета-тег или заголовок. Для страниц поиска по сайту, сортировки и фильтров — смотреть по ситуации, но не блокировать всё подряд в robots.txt без анализа.

Пошаговое решение для WordPress

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

Шаг 1. Составьте список параметров

Обычно в список попадают:

• utm_source, utm_medium, utm_campaign и другие UTM-метки;
• gclid, fbclid и похожие рекламные параметры;
• replytocom;
• параметры сортировки и фильтров: sort, order, filter, price и т. п.;
• служебные параметры плагинов, если они не несут ценности для поиска.

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

Шаг 2. Добавьте канонический URL без параметров

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

<?php
add_filter('get_canonical_url', function ($canonical, $post) {
    if (is_admin() || ! $canonical) {
        return $canonical;
    }

    if (is_singular() || is_page() || is_single()) {
        return remove_query_arg(
            array('utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'gclid', 'fbclid', 'replytocom'),
            $canonical
        );
    }

    return $canonical;
}, 10, 2);

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

Шаг 3. Для отдельных шаблонов добавьте noindex

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

<?php
add_action('wp_head', function () {
    if (empty($_GET)) {
        return;
    }

    $blocked_params = array('sort', 'order', 'filter', 'utm_source', 'utm_medium', 'utm_campaign', 'gclid', 'fbclid', 'replytocom');
    $has_blocked = false;

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

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

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

Шаг 4. Если есть доступ к серверу, уберите мусор на уровне редиректа

Иногда проще не объяснять поисковику, а сразу приводить URL к чистому виду. Для UTM и рекламных хвостов можно сделать 301-редирект на адрес без параметров, если они не нужны пользователю после загрузки страницы.

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

    $remove_params = array('utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'gclid', 'fbclid');
    $has_params = false;

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

    if (! $has_params) {
        return;
    }

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

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

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

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

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

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

Проверка в браузере и через curl

Откройте URL с параметром и убедитесь, что:

• каноникал указывает на чистый адрес;
• в <head> есть noindex,follow, если он нужен;
• при редиректе URL действительно меняется на чистый.

Для быстрой проверки удобно использовать curl:

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

Смотрите на код ответа и заголовок Location, если включён редирект. Если редиректа нет, проверьте HTML-ответ и канонический URL.

Проверка в Search Console

В Search Console откройте проверку URL и посмотрите, как Google видит страницу с параметром. Если всё сделано правильно, технический URL не должен становиться основной версией, а в индексе со временем останется чистая страница.

Не ждите мгновенного эффекта. После правок поисковику нужно переобойти сайт, а старые URL могут висеть в отчётах ещё какое-то время.

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

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

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

Ставят noindex на все страницы подряд

Иногда разработчик делает условие слишком широким и получает noindex даже на нормальных страницах с параметрами, которые нужны пользователю. Проверяйте логику по типам страниц и по конкретным параметрам, а не по факту наличия $_GET.

Редиректят всё на главную

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

Не учитывают плагины SEO и кеша

Если у вас уже стоит SEO-плагин, проверьте, не генерирует ли он собственный canonical или robots meta. Иначе получится конфликт: один код ставит noindex, другой — index. То же касается кеша: после правок очистите кеш страниц и CDN, иначе вы будете смотреть на старую версию.

Что делать, если параметр нужен для аналитики

UTM-метки часто нужны маркетингу, но не нужны поиску. В этом случае обычно лучше оставить их для трекинга, но не давать им становиться отдельными страницами. Рабочая схема выглядит так:

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

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

Когда имеет смысл использовать плагин

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

Плагин удобен, когда:

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

Код лучше, когда логика нестандартная и зависит от типа страницы, роли пользователя или конкретного шаблона.

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

Не храните список «плохих» параметров в нескольких местах. Если он есть и в теме, и в плагине, и в .htaccess, вы потом не поймёте, что именно сработало. Лучше держать одну точку правды: либо mu-plugin, либо SEO-плагин, либо серверное правило.

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

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