Как запретить индексацию страниц с параметрами в WordPress

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

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

Когда проблема уже есть: что искать в индексe и логах

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

Типичные признаки

• в индексе есть URL вида /post-name/?utm_source=...;
• поисковик показывает версии страниц с сортировкой или фильтрами;
• в отчётах много «Просканировано, но не проиндексировано» для технических URL;
• внутренний поиск сайта создаёт отдельные страницы, которые не должны ранжироваться;
• в логах бот регулярно запрашивает одни и те же адреса с разными параметрами.

Какие параметры чаще всего создают дубли

В WordPress и вокруг него чаще всего всплывают utm_*, gclid, fbclid, replytocom, параметры сортировки и фильтрации, а также служебные query string от плагинов. Не все из них одинаково опасны: часть нужна для аналитики, часть — только для интерфейса, а часть вообще не должна попадать в индекс.

Что делать: сравнение подходов

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

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

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

Шаг 1. Закройте технические страницы через noindex

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

<?php
add_action('wp_head', function () {
    if (is_search()) {
        echo '<meta name="robots" content="noindex,follow" />' . "\n";
        return;
    }

    if (!empty($_GET['sort']) || !empty($_GET['filter'])) {
        echo '<meta name="robots" content="noindex,follow" />' . "\n";
    }
}, 1);

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

Шаг 2. Добавьте canonical на чистую версию URL

Если страница открывается с параметром, но по сути это тот же контент, canonical должен указывать на основной адрес без query string. Это особенно полезно для UTM-меток и похожих параметров, которые нужны аналитике, но не контенту.

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

    $remove_params = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'gclid', 'fbclid'];

    $current = home_url(add_query_arg([], $_SERVER['REQUEST_URI']));
    $clean = remove_query_arg($remove_params, $current);

    return $clean ?: $canonical;
}, 10, 2);

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

Шаг 3. Уберите мусорные параметры редиректом там, где это безопасно

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

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

    $remove_params = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'gclid', 'fbclid'];
    $has_trash = false;

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

    if (!$has_trash) {
        return;
    }

    $clean_url = remove_query_arg($remove_params, home_url(add_query_arg([], $_SERVER['REQUEST_URI'])));

    wp_safe_redirect($clean_url, 301);
    exit;
});

Редирект — хороший вариант для маркетинговых меток, но не для всех случаев. Если вам нужно сохранить параметры для аналитики на стороне сервера или в скриптах, сначала проверьте, не потеряете ли вы данные при 301.

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

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

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

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

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

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

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

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

Закрыли не те параметры

Самая частая ошибка — попытка убрать все query string одним правилом. В результате ломаются фильтры, поиск по сайту, сортировка или даже авторизация. Исправление простое: составьте список конкретных параметров, которые действительно создают дубли, и работайте только с ними.

Поставили noindex, но оставили мусорный canonical

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

Сделали 301 на всё подряд

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

Ожидали мгновенного исчезновения из индекса

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

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

• Определены конкретные параметры, которые создают дубли.
• Для каждой группы URL выбран свой способ: noindex, canonical или редирект.
• Не затронуты рабочие фильтры, поиск и служебные сценарии.
• Canonical указывает на чистый URL без лишних параметров.
• Проверен ответ сервера и исходный код страницы.
• В Search Console добавлены URL для повторной проверки.

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

Если параметров много, не стоит решать всё только на уровне PHP-шаблона. Лучше сначала нормализовать URL на уровне логики сайта, а уже потом добавлять точечные правила. Чем меньше лишних страниц генерируется, тем меньше нагрузка на сервер и тем чище отчёты в аналитике.

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