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

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

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

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

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

Типичные источники дублей в WordPress

?replytocom= в комментариях;
?utm_* из рекламных и email-кампаний;
?sort=, ?filter=, ?price= в каталогах и списках;
?amp или другие служебные параметры плагинов;
параметры поиска вида ?s=, если они индексируются без контроля;
страницы пагинации и сортировки, которые дублируют основной листинг.

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

Диагностика: какие URL уже попали в индекс

Сначала проверьте, что именно индексируется. Без этого легко закрыть нужные страницы и оставить мусор нетронутым.

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

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

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

Здесь важен не список «всех плохих параметров», а логика. Закрываем то, что не несёт самостоятельной ценности в поиске. Оставляем то, что меняет контент и может быть полезно как отдельная посадочная.

Подход	Когда подходит	Минус
canonical на основную страницу	Параметр меняет только сортировку, трекинг или внешний вид	Не убирает URL из обхода полностью
`noindex,follow`	Страница не должна попадать в поиск, но ссылки по ней можно обходить	Нужно убедиться, что робот видит мета-тег
301-редирект	Параметр не нужен вообще и не должен жить как отдельный адрес	Нельзя применять к полезным вариантам страниц

На практике для UTM и служебных параметров чаще достаточно canonical или noindex. Для совсем лишних адресов — редирект или серверное правило. Для фильтров каталога решение зависит от того, есть ли у них SEO-ценность.

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

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

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

<?php
// Пример: формируем чистый URL без query string.
$clean_url = remove_query_arg( array( 'utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content' ) );
echo esc_url( $clean_url );

Функция remove_query_arg() штатная для WordPress и безопаснее, чем ручная сборка строки. Её можно использовать в шаблонах, в хуках и в коде плагина.

2. Добавьте canonical для параметризованных страниц

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

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

    if ( ! empty( $_GET ) ) {
        $canonical = home_url( add_query_arg( array(), $GLOBALS['wp']->request ) );
        $canonical = remove_query_arg( array_keys( $_GET ), $canonical );

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

Этот пример показывает идею, но в реальном проекте лучше ограничить его конкретными типами страниц и параметрами. Не стоит выводить canonical по всем URL с любым query string без разбора: иногда это ломает поиск, фильтры и служебные страницы.

3. Закройте ненужные параметры через robots meta

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

<?php
add_action( 'wp_head', function () {
    if ( isset( $_GET['replytocom'] ) || isset( $_GET['sort'] ) || isset( $_GET['filter'] ) ) {
        echo '<meta name="robots" content="noindex,follow" />' . "\n";
    }
}, 1 );

Такой код нужно применять аккуратно: не вешайте его на все параметры подряд. Например, utm_* обычно не требуют отдельного noindex, потому что это просто метки кампаний, а не отдельный контент.

4. Для лишних адресов используйте 301

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

<?php
add_action( 'template_redirect', function () {
    if ( isset( $_GET['replytocom'] ) ) {
        wp_safe_redirect( remove_query_arg( 'replytocom' ), 301 );
        exit;
    }
} );

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

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

Когда задача типовая, часть работы можно закрыть SEO-плагином или инструментом для чистки сайта. Но даже тогда нужно понимать, что именно делает настройка: canonical, noindex или редирект. Иначе легко получить красивую галочку без эффекта.

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

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

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

Откройте страницу с параметром и проверьте исходный код: есть ли canonical и meta robots.
Посмотрите ответ сервера через curl -I или инструменты разработчика: нет ли лишних редиректов.
Проверьте, что чистый URL открывается без параметров и отдаёт 200 OK.
В Search Console отправьте на переобход несколько проблемных URL и сравните статус через некоторое время.
Убедитесь, что внутренние ссылки на сайте больше не ведут на параметризованные адреса без необходимости.

curl -I "https://example.com/page/?replytocom=1"
curl -I "https://example.com/page/"

Если вы закрывали параметр через canonical, в HTML должен быть один канонический адрес без query string. Если ставили noindex, проверьте, что мета-тег присутствует именно на нужных типах страниц, а не на всём сайте.

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

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

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

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

Поставили noindex на полезные фильтры

Если фильтр создаёт посадочные страницы с реальным спросом, их нельзя закрывать автоматически только потому, что в URL есть параметр. Иногда лучше сделать отдельные ЧПУ-страницы или сохранить индексируемыми только выбранные комбинации.

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

Canonical указывает на неправильный адрес

Иногда тема или плагин формирует canonical с параметрами, пагинацией или даже с HTTP вместо HTTPS. Это ломает склейку и создаёт новые дубли.

Исправление: проверьте шаблон вывода canonical, настройки SEO-плагина и фильтры, которые могут подменять URL.

Редирект зацикливается

Если правило не исключает уже очищенный URL, пользователь и бот попадают в бесконечный переход. Такое часто случается при ручной обработке template_redirect.

Исправление: сравнивайте исходный и целевой URL, редирект делайте только один раз и только для конкретных параметров.

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

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

Проверяйте наличие параметра через isset() или array_key_exists(), а не через «всё подряд».
Используйте esc_url() и wp_safe_redirect() для вывода и редиректов.
Не встраивайте логику в functions.php без необходимости, если её можно вынести в маленький mu-plugin.
Перед выкладкой протестируйте изменения на staging-копии.
После правок очистите кеш страницы и CDN, иначе вы будете смотреть на старую версию HTML.

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

Для проверки полезно сравнить три вещи: что отдаёт сервер, что видит браузер в HTML и что показывает поисковик в индексе. Только совпадение всех трёх уровней означает, что решение действительно работает.