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

Автор: Максим Громов | Опубликовано: 04.09.2026

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

Проблема обычно всплывает не сразу: в Search Console растёт число страниц с параметрами, в логах видны запросы к адресам вида ?replytocom=, ?utm_source=, ?sort=, ?filter=, а в выдаче появляются не те URL, которые вы хотели бы ранжировать. Ниже — как понять, что именно закрывать, чем закрывать и как проверить результат без лишнего риска.

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

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

Типичные сценарии

UTM-метки в ссылках из рассылок и рекламы.
Параметры сортировки и пагинации в архивах.
Внутренний поиск по сайту с адресами вида ?s=.
Технические параметры комментариев, например ?replytocom=.
Фильтры и фасеты, если они генерируют много почти одинаковых страниц.

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

Диагностика: какие URL реально попадают в индекс

Начинать стоит не с правил, а с проверки фактов. Откройте отчёт по индексированию в Google Search Console и посмотрите, какие URL с параметрами уже известны поисковику. Затем проверьте серверные логи или хотя бы отчёт по сканированию, если он есть в вашей аналитике. Важно понять, это единичные адреса или массовая генерация.

Полезно вручную проверить несколько шаблонов URL:

https://example.com/post-name/?utm_source=newsletter
https://example.com/post-name/?replytocom=123
https://example.com/?s=wordpress
https://example.com/category/news/?sort=popular

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

Что выбрать: robots.txt, noindex или canonical

У каждого способа своя задача. Ошибка многих сайтов — пытаться решить всё одним инструментом. Это работает не всегда.

Подход	Когда использовать	Ограничения
`robots.txt`	Для блокировки сканирования технических URL и мусорных параметров	Не убирает URL из индекса, если он уже известен поисковику
`noindex`	Когда страницу можно сканировать, но не нужно индексировать	Страница должна быть доступна для обхода роботом
`rel=canonical`	Когда есть основная версия страницы и её параметрические копии	Не всегда срабатывает, если страницы сильно отличаются по смыслу

На практике для UTM и похожих меток чаще всего достаточно каноникала на чистый URL. Для внутреннего поиска и некоторых фасетов лучше noindex, follow. Для совсем технических адресов можно добавить блокировку в robots.txt, но не как единственную меру.

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

Шаг 1. Уберите генерацию лишних параметров там, где это возможно

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

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

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

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

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

    $tracking_params = array( 'utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content' );

    foreach ( $tracking_params as $param ) {
        if ( isset( $_GET[ $param ] ) ) {
            return remove_query_arg( $tracking_params, home_url( add_query_arg( array(), $GLOBALS['wp']->request ) ) );
        }
    }

    return $canonical;
} );

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

Шаг 3. Закройте внутренний поиск и похожие технические страницы

Страницы поиска по сайту с параметром ?s= редко должны индексироваться. Для них обычно ставят noindex. Это можно сделать через SEO-плагин или кодом, если вы не хотите зависеть от дополнительных настроек.

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

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

Шаг 4. Добавьте точечные правила в robots.txt

Блокировка в robots.txt полезна для мусорных параметров, которые не должны сканироваться вообще. Но не используйте её как универсальную кнопку «скрыть из поиска». Если URL уже в индексе, робот может видеть только запрет на обход, а не сигнал на удаление.

Пример аккуратного набора правил:

User-agent: *
Disallow: /*?replytocom=
Disallow: /*?s=
Disallow: /*?sort=
Disallow: /*?filter=

Sitemap: https://example.com/sitemap_index.xml

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

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

После правок не ждите мгновенного эффекта. Сначала проверьте техническую часть:

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

Затем используйте проверку URL в Search Console. Если страница с параметром ещё индексируется, посмотрите, что именно видит робот: canonical, мета robots, ответ сервера, редирект. Иногда проблема не в индексации, а в том, что параметрический URL отдаёт 200 OK и выглядит для поисковика как самостоятельная страница.

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

Закрыли всё в robots.txt, а URL остались в индексе

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

Поставили noindex на страницу, которую робот не может сканировать

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

Сделали canonical на нерелевантную страницу

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

Сломали поиск и сортировку на фронтенде

Иногда разработчики слишком агрессивно режут query string на уровне сервера или плагина. В итоге перестают работать формы, AJAX-фильтры и переходы по страницам. Любое правило сначала тестируйте на одном типе URL, а не на всём сайте.

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

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

Не кэшируйте одинаково все URL с параметрами, если они не должны иметь отдельный контент.
Проверьте, не создаёт ли плагин фильтрации бесконечные комбинации параметров.
Не открывайте индексацию для служебных страниц только ради «полноты» карты сайта.
Если используете SEO-плагин, настройте canonical и noindex централизованно, а не в нескольких местах сразу.

Если нужен более системный подход к удалению дублей и технической чистке сайта, уместно посмотреть в сторону инструментов вроде Clearfy Pro: он помогает закрывать часть типовых дублей и упрощает техническую настройку WordPress. Но даже с плагином важно понимать, какие URL вы закрываете и почему.

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

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

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

⭐⭐⭐⭐⭐