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

На WordPress часто индексируются не только обычные страницы, но и их копии с параметрами в URL: ?sort=, ?filter=, ?utm_, ?replytocom=, а иногда и внутренний поиск. В итоге в поиске появляются дубли, а краулинговый бюджет уходит на мусорные адреса. При этом полностью запрещать такие URL нельзя: часть из них нужна для фильтров, сортировки и пользовательской навигации.

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

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

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

Что искать в логах и в индексации

• URL с ?sort=, ?order=, ?filter_, ?utm_*.
• Страницы поиска вида /?s=....
• Переходы с внутренних ссылок, где параметры добавляются скриптом или плагином.
• Дубли одной и той же страницы в выдаче с разными query string.

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

Диагностика: какие URL можно закрывать, а какие нельзя

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

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

1. Нормализуйте канонический URL

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

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

    if (is_search() || !empty($_GET)) {
        $canonical = home_url(add_query_arg([], $GLOBALS['wp']->request ?? ''));
        if (is_search()) {
            $canonical = home_url('/');
        }

        echo '<link rel="canonical" href="' . esc_url($canonical) . '" />' . "\n";
    }
}, 1);

Этот пример не пытается «умно» собирать все варианты URL. Для реального проекта лучше опираться на SEO-плагин, если он уже управляет canonical. Код нужен только там, где плагин не справляется или его нет.

2. Добавьте noindex,follow для мусорных параметров

Если страница с параметром не должна попадать в индекс, но по ней должны ходить роботы и пользователи, используйте noindex,follow. Это безопаснее, чем блокировать URL в robots.txt: поисковик увидит страницу, но не будет держать её в выдаче.

<?php
add_filter('wp_robots', function (array $robots) {
    $blocked_params = ['utm_source', 'utm_medium', 'utm_campaign', 'sort', 'order', 'replytocom'];

    foreach ($blocked_params as $param) {
        if (isset($_GET[$param])) {
            $robots['noindex'] = true;
            $robots['follow'] = true;
            break;
        }
    }

    if (is_search()) {
        $robots['noindex'] = true;
        $robots['follow'] = true;
    }

    return $robots;
});

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

3. Уберите параметры из внутренних ссылок, где они не нужны

Иногда проблема не в индексации, а в том, что сайт сам генерирует ссылки с параметрами на каждом шаге. Например, кнопки сортировки или рекламные метки попадают в меню, хлебные крошки или блоки контента. Тогда поисковик видит бесконечный набор вариантов одной страницы.

Если параметр нужен только для фронтенда, формируйте ссылку без него в HTML, а состояние передавайте через JS или храните в cookie/localStorage. Для серверной части это уменьшает количество дублей и упрощает каноникал.

Если нужно закрыть только часть параметров

Не все query string надо резать одинаково. Полезно завести белый список параметров, которые действительно влияют на уникальный контент. Всё остальное — в noindex или в редирект на чистую версию.

<?php
function wpstudy_allowed_query_params(): array {
    return ['filter_color', 'filter_size', 'page'];
}

add_action('template_redirect', function () {
    if (is_admin() || is_search()) {
        return;
    }

    if (empty($_GET)) {
        return;
    }

    $allowed = wpstudy_allowed_query_params();
    $incoming = array_keys($_GET);
    $unexpected = array_diff($incoming, $allowed);

    if (!$unexpected) {
        return;
    }

    // Для UTM и технических параметров можно оставить страницу доступной, но без индексации.
    // Жёсткий редирект здесь не ставим, чтобы не ломать аналитику и переходы.
});

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

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

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

• Откройте URL с параметром в браузере и проверьте исходный код страницы.
• Убедитесь, что есть один canonical на чистую версию.
• Проверьте наличие noindex,follow там, где он нужен.
• Сравните ответ сервера для URL с параметром и без него.
• Проверьте, не создаёт ли кеш отдельную копию для каждого query string.

Полезная быстрая проверка через curl:

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

Смотрите на заголовки X-Robots-Tag, Location при редиректе и на то, не отдаёт ли сервер разные версии там, где должна быть одна.

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

Закрыли всё в robots.txt

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

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

Так легко сломать фильтры, сортировку и UTM-метки. Редирект нужен только для тех параметров, которые не несут пользовательской ценности. Для остальных лучше использовать canonical и robots meta.

Оставили разные canonical в теме и SEO-плагине

Если тема выводит свой canonical, а плагин — свой, поисковик может получить противоречивые сигналы. Оставьте один источник правды. Обычно это SEO-плагин или собственный код, но не оба сразу.

Не учли кеш

Страницы с параметрами часто кешируются отдельно. В результате один и тот же URL может вести себя по-разному после очистки кеша. После внедрения обязательно сбросьте кеш плагина, серверный кеш и CDN, если он есть.

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

Не используйте тяжёлую логику в template_redirect для каждого запроса без необходимости. Проверка параметров должна быть дешёвой: несколько isset() и ранний выход. Это особенно важно на сайтах с большим трафиком и агрессивным кешированием.

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

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

Что должно быть в итоговой проверке

• Чистый URL остаётся основной версией страницы.
• URL с мусорными параметрами не попадает в индекс.
• Фильтры и сортировка продолжают работать для пользователя.
• В исходном коде нет конфликтующих canonical и robots meta.
• Кеш не раздаёт старую версию после правок.

Если после всех изменений в индексации всё ещё остаются дубли, обычно причина в одном из трёх мест: тема генерирует лишние ссылки, SEO-плагин переопределяет мета-теги, либо кеш/CDN сохраняет старые заголовки. В таком случае проще идти от ответа сервера и исходного HTML, а не от визуального вида страницы.