Если на сайте начали плодиться URL вида ?utm_source=..., ?sort=..., ?filter=... или другие вариации одной и той же страницы, поисковик быстро получает десятки дублей. Это не всегда критично для пользователей, но почти всегда мешает индексации: краулинговый бюджет распыляется, в выдаче появляются не те адреса, а каноникал и сигналы качества начинают работать хуже.
Ниже — рабочая схема для WordPress: что именно закрывать, чем отличаются noindex, canonical и robots.txt, как проверить результат и где обычно ошибаются.
Когда проблема уже есть: как понять, что индексируются лишние параметры
Сначала не трогайте код, а проверьте симптоматику. В Search Console и в логах сайта обычно видно одно и то же: поисковик ходит по страницам с параметрами, а в индексе появляются их копии. Особенно часто это случается после подключения UTM-меток, фильтрации каталога, сортировки записей, поиска по сайту или трекинга кампаний.
Признаки, которые стоит проверить
- в выдаче находятся URL с
utm_*, хотя они не должны ранжироваться; - одна и та же страница доступна с разными параметрами и отдает одинаковый контент;
- в отчете о страницах с дубликатами растет число адресов с query string;
- внутренние ссылки на сайте случайно ведут на URL с параметрами;
- канонический URL указывает на саму себя, но рядом есть альтернативы с параметрами.
Если у вас фильтры или сортировки реально меняют контент, не все параметры нужно закрывать одинаково. Например, ?sort=price может быть полезен пользователю, но не обязан попадать в индекс. А вот ?utm_source=... почти всегда нужен только для аналитики и в поиске не должен жить.
Что именно закрывать: UTM, сортировки, фильтры и служебные параметры
Удобнее разделить параметры на три группы. Это помогает не переборщить и не закрыть то, что должно индексироваться.
| Тип параметра | Пример | Что делать | Комментарий |
|---|---|---|---|
| Маркетинговые | utm_source, utm_medium, gclid | Обычно закрывать от индексации | Нужны для аналитики, но не для поиска |
| Навигационные | sort, order, page | Зависит от сценария | Часто лучше canonical на основную страницу |
| Фильтры | filter_color, brand, price | Чаще закрывать | Если фильтр создает тонкие дубли, индексировать не стоит |
Для WordPress обычно достаточно двух уровней защиты: убрать такие URL из индекса через noindex и привести канонический адрес к чистой версии страницы. robots.txt тоже полезен, но он не решает задачу сам по себе, если URL уже известен поисковику.
Пошаговое решение: как закрыть параметры без поломки сайта
Шаг 1. Определите список параметров
Не пытайтесь закрыть все подряд. Сначала соберите реальные параметры, которые появляются в логах, Search Console и отчетах аналитики. Для типового сайта это utm_*, gclid, fbclid, а также параметры фильтров и сортировки, которые добавляет тема или плагин.
Если у вас есть SEO-плагин, проверьте, не умеет ли он задавать canonical и мета-robots для архивов и страниц с параметрами. Но на практике для query string часто нужен отдельный код.
Шаг 2. Добавьте noindex,follow для страниц с нежелательными параметрами
Ниже пример, который можно положить в functions.php дочерней темы или в небольшой mu-plugin. Он добавляет noindex,follow на фронтенде, если в URL есть типичные маркетинговые параметры. Это не ломает переходы по ссылкам и не мешает поисковику проходить по сайту дальше.
<?php
add_filter('wp_robots', function (array $robots) {
$params = array('utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'gclid', 'fbclid');
foreach ($params as $param) {
if (isset($_GET[$param])) {
$robots['noindex'] = true;
$robots['follow'] = true;
break;
}
}
return $robots;
});Этот вариант безопаснее, чем пытаться массово резать URL на уровне сервера. Он работает на уровне WordPress и не мешает сбору статистики по кампаниям.
Шаг 3. Приведите canonical к чистому URL
Если страница открыта с параметром, канонический адрес должен указывать на версию без него. Это особенно важно для фильтров и сортировок. В WordPress canonical часто формируется автоматически, но при query string он не всегда ведет себя так, как нужно.
<?php
add_filter('get_canonical_url', function ($canonical, $post) {
if (is_admin() || empty($canonical)) {
return $canonical;
}
$remove_params = array('utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'gclid', 'fbclid', 'sort', 'order');
if (!empty($_GET)) {
$clean_url = remove_query_arg($remove_params, $canonical);
return $clean_url;
}
return $canonical;
}, 10, 2);Здесь есть важный нюанс: не надо бездумно удалять все параметры. Если на сайте есть рабочие фильтры, которые должны менять контент, сначала проверьте, не сломает ли это навигацию и пагинацию.
Шаг 4. Если нужно, добавьте правила в robots.txt
robots.txt полезен как дополнительный сигнал, но не как единственная защита. Он помогает сократить обход мусорных URL, однако уже известные поисковику адреса могут оставаться в индексе без полноценного noindex.
User-agent: *
Disallow: /*?utm_
Disallow: /*?gclid=
Disallow: /*?fbclid=
Disallow: /*?sort=
Disallow: /*?filter_Такой набор правил не универсален. Некоторые поисковые роботы и CMS-роутинг могут интерпретировать шаблоны по-разному, поэтому после правки обязательно проверяйте реальный обход и индексирование.
Сравнение подходов: плагин, код или robots.txt
Для небольшого сайта можно обойтись кодом. Для проекта с несколькими типами архивов и фильтров удобнее использовать SEO-плагин или связку плагина и точечной доработки. Ниже — практическое сравнение.
| Подход | Плюсы | Минусы | Когда брать |
|---|---|---|---|
| Код в теме / mu-plugin | Точный контроль, без лишних зависимостей | Нужна проверка после обновлений | Когда список параметров известен и стабилен |
| SEO-плагин | Удобно управлять canonical и robots | Не всегда закрывает query string так, как нужно | Если уже используете SEO-плагин и не хотите плодить код |
robots.txt | Снижает обход мусорных URL | Не гарантирует удаление из индекса | Как дополнительный слой, не как основа |
Если нужен более широкий набор инструментов для чистки дублей, canonical и технических мелочей, можно посмотреть на Clearfy Pro. Но даже с плагином полезно понимать, какие именно параметры вы закрываете и почему.
Проверка результата после внедрения
После правки не ограничивайтесь визуальной проверкой страницы в браузере. Нужно убедиться, что поисковый робот видит нужные сигналы.
Что проверить вручную
- откройте URL с
?utm_source=testи посмотрите исходный код страницы; - убедитесь, что в
<meta name="robots">естьnoindexдля нежелательных параметров; - проверьте canonical: он должен вести на чистый адрес без мусорного query string;
- сравните заголовки ответа и HTML для обычной и параметризованной версии;
- посмотрите, не появились ли ошибки 404 или редирект-цепочки.
Если у вас есть доступ к консоли, удобно проверить заголовки так:
curl -I "https://example.com/page/?utm_source=test"
curl -s "https://example.com/page/?utm_source=test" | grep -iE 'robots|canonical'В Search Console полезно проверить, как индексируются страницы с параметрами, и нет ли среди них тех, что должны быть исключены. Если после изменения прошло немного времени, не ждите мгновенного обновления индекса: поисковику нужно переобойти URL и увидеть новые сигналы.
Частые ошибки и как их исправить
Закрывают параметры только в robots.txt
Это распространенная ошибка. Если URL уже в индексе, один только Disallow не заставит поисковик удалить его. Нужен noindex или корректный canonical, а robots.txt — как дополнительная мера.
Ставят noindex на все страницы с параметрами подряд
Так можно случайно закрыть полезные страницы сортировки или фильтрации, которые реально нужны пользователям. Сначала разделите параметры на маркетинговые, навигационные и контентные, потом применяйте правила.
Удаляют все query string без разбора
Это ломает пагинацию, поиск по сайту, некоторые формы и внутренние сценарии. Если параметр участвует в логике страницы, его нельзя слепо вырезать из canonical и редиректов.
Оставляют внутренние ссылки с UTM
Даже если страница закрыта от индексации, внутренние ссылки с параметрами создают лишний шум. Проверьте меню, кнопки, баннеры и шаблоны писем: UTM должны быть для внешних кампаний, а не для внутренних переходов.
Делают 301-редирект со всех параметров на главную
Это грубая ошибка. Если параметр был на конкретной статье или архиве, редирект на главную искажает смысл страницы и может ухудшить поведенческие сигналы. В большинстве случаев лучше canonical + noindex, а не массовый 301.
Практические советы по безопасности и производительности
Чем больше параметров вы обрабатываете, тем внимательнее нужно относиться к производительности. Не пишите тяжелые регулярки на каждый запрос, если достаточно проверить несколько ключей в $_GET. Для больших проектов лучше вынести логику в mu-plugin, чтобы она не зависела от активной темы.
Еще один момент — кэш. Если у вас включен page cache, убедитесь, что параметризованные URL не отдают случайно закэшированную версию без нужных мета-тегов. После внедрения очистите кэш страницы, CDN и, если используется, объектный кэш.
Для безопасности не принимайте список параметров из пользовательского ввода и не строите на его основе динамические правила индексации. Все параметры должны быть явно перечислены в коде или в настройках, которые вы контролируете.
Если задача шире и включает чистку дублей, служебных URL и технических хвостов, иногда удобнее собрать это в одном месте через специализированный плагин, чем размазывать по теме. Но принцип остается тем же: сначала диагностируете реальные URL, потом задаете правила, потом проверяете исходный код и индексирование.
