Проблема с URL вида ?sort=, ?filter=, ?utm_ или служебными параметрами обычно всплывает не сразу. Сайт уже проиндексирован, в Search Console растёт число «Страница с перенаправлением», «Просканировано — сейчас не проиндексировано» или просто мусорные URL с параметрами начинают конкурировать с чистыми страницами. Если ничего не делать, поисковик тратит краулинговый бюджет на варианты одной и той же страницы, а аналитика смешивает полезный трафик с техническим.
Когда это действительно проблема
Не каждый параметр нужно запрещать. Часть из них нужна для работы сайта: пагинация, сортировка, фильтры, служебные токены. Но если параметр не меняет содержимое страницы для пользователя или создаёт множество почти одинаковых URL, его лучше исключить из индексации и, при необходимости, нормализовать.
Типичные сценарии
- страницы категорий с параметрами сортировки:
/category/?sort=price; - поисковые страницы сайта:
/?s=...; - UTM-метки в ссылках из рекламы и рассылок;
- фильтры в архиве записей или каталоге;
- технические параметры, которые появляются после плагинов аналитики, кеша или форм.
Если параметр нужен только для интерфейса, но не для отдельной поисковой выдачи, его обычно не стоит оставлять открытым для индексации. Если же параметр меняет смысл страницы и по нему есть спрос, решение нужно принимать отдельно, а не рубить всё подряд.
Диагностика: что именно попало в индекс
Сначала проверьте, какие URL реально индексируются. Не ориентируйтесь только на количество страниц в админке или на отчёты плагина SEO. Нужны фактические примеры из поиска и логики сайта.
- Откройте Google Search Console и посмотрите отчёт по страницам с параметрами.
- Сделайте поиск по сайту в формате
site:example.com inurl:?и посмотрите, какие варианты всплывают. - Проверьте, не создаёт ли тема или плагин отдельные архивы для фильтров.
- Сравните HTML чистого URL и URL с параметром: меняется ли заголовок, canonical, robots, контент.
Если на странице с параметром контент тот же, а меняется только сортировка или UTM, это почти всегда кандидат на запрет индексации. Если же параметр влияет на выдачу товаров, записей или товаров по фильтру, лучше сначала решить, нужен ли такой URL в поиске вообще.
Что делать: рабочая схема без лишнего риска
На практике лучше сочетать несколько уровней защиты: canonical, noindex для технических страниц, а для совсем мусорных параметров — нормализацию через редирект или игнорирование в логике шаблона. Один только robots.txt здесь не спасает: URL может остаться в индексе как найденный по ссылкам.
| Подход | Когда использовать | Минус |
|---|---|---|
| Плагин SEO | Если нужно быстро закрыть типовые архивы и добавить canonical/noindex без кода | Не всегда удобно для точечных параметров |
| Код в теме или мини-плагине | Если параметры специфичны и нужна точная логика | Нужно тестировать после обновлений |
| Редирект 301 | Если параметр не нужен пользователю и не должен жить отдельно | Нельзя применять к параметрам, которые реально меняют контент |
Вариант 1: закрыть технические параметры через noindex
Если у вас есть страницы поиска или служебные URL, можно добавить мета-роботс точечно. Ниже пример для страниц поиска и для URL с конкретными параметрами. Код лучше держать в мини-плагине или в functions.php дочерней темы.
<?php
add_filter('wp_robots', function (array $robots) {
if (is_search()) {
$robots['noindex'] = true;
$robots['nofollow'] = true;
}
if (!empty($_GET['sort']) || !empty($_GET['filter']) || !empty($_GET['replytocom'])) {
$robots['noindex'] = true;
$robots['nofollow'] = true;
}
return $robots;
});
Это не универсальная кнопка «выключить всё». Если параметр нужен для отдельной посадочной страницы, не добавляйте его в общий список без проверки. Иначе можно случайно закрыть полезные страницы от индексации.
Вариант 2: указать canonical на чистый URL
Если страница с параметром должна открываться пользователю, но индексироваться должна основная версия, canonical помогает поисковику выбрать правильный адрес. В WordPress это можно сделать через фильтр wpseo_canonical в Yoast SEO или через собственную логику, если SEO-плагин не используется.
<?php
add_filter('wpseo_canonical', function ($canonical) {
if (is_search()) {
return home_url('/');
}
if (!empty($_GET['sort']) || !empty($_GET['filter'])) {
return remove_query_arg(array('sort', 'filter'));
}
return $canonical;
});
Если у вас не Yoast SEO, не пытайтесь использовать этот фильтр «наугад». Он относится именно к Yoast. Для других плагинов логика будет другой. В таком случае либо используйте их встроенные настройки, либо добавляйте canonical вручную в шаблон.
Вариант 3: убрать лишние параметры редиректом
UTM-метки и часть служебных параметров можно безопасно убирать редиректом на чистый URL. Это полезно, если параметр не нужен для отображения контента и только плодит дубли. Но редирект должен быть аккуратным: не ломайте формы, фильтры и пагинацию.
<?php
add_action('template_redirect', function () {
if (is_admin()) {
return;
}
$remove = array('utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content');
$has_tracking = false;
foreach ($remove as $key) {
if (isset($_GET[$key])) {
$has_tracking = true;
break;
}
}
if (!$has_tracking) {
return;
}
$clean_url = remove_query_arg($remove);
wp_safe_redirect($clean_url, 301);
exit;
});
Такой редирект полезен для рекламных ссылок и рассылок. Но если вы анализируете кампании через UTM, сначала убедитесь, что данные уже попадают в аналитику до редиректа, либо не убирайте параметры на стороне сервера.
Пошаговая настройка без лишних сюрпризов
- Составьте список параметров, которые реально создают дубли.
- Разделите их на три группы: служебные, аналитические, пользовательские.
- Для служебных и аналитических параметров добавьте canonical или редирект.
- Для страниц поиска и технических архивов добавьте
noindex. - Проверьте шаблоны темы: не выводят ли они одинаковый title и description для всех вариантов URL.
- После изменений отправьте на переобход только важные чистые URL.
Как проверить, что решение сработало
Проверка нужна не только в браузере. Важно увидеть, как страница отдаётся поисковику и что происходит с каноническим адресом.
- Откройте URL с параметром и посмотрите исходный код страницы.
- Убедитесь, что в
<meta name="robots">или в HTTP-ответе есть нужная директива. - Проверьте canonical: он должен вести на чистую версию, если это задумано.
- Посмотрите, нет ли цепочки редиректов.
- В Search Console используйте проверку URL и запросите переобход только после теста.
Если вы добавляли редирект, проверьте код ответа через curl -I "https://example.com/page/?utm_source=test". Если добавляли noindex, убедитесь, что он не конфликтует с canonical и не закрывает важную страницу по ошибке.
Частые ошибки и как их исправить
Ставят robots.txt вместо noindex
Это частая ошибка. Robots.txt может запретить обход, но не гарантирует удаление URL из индекса, если он уже известен поисковику. Для уже существующих дублей нужен noindex или canonical, а не только запрет в robots.
Закрывают все параметры одним правилом
Если вы без разбора закрыли ?filter=, ?page= и ?s=, можно сломать поиск, пагинацию или важные посадочные страницы. Сначала проверьте, что именно меняет параметр, и только потом пишите правило.
Делают редирект на главную для любого параметра
Это плохая практика. Пользователь теряет контекст, а поисковик получает неочевидную нормализацию. Если параметр не нужен, редиректите на соответствующую чистую страницу, а не на главную.
Не проверяют тему и плагины
Иногда дубли создаёт не WordPress как система, а конкретный шаблон: отдельные страницы для тегов, авторов, архивов дат, страниц поиска. В таких случаях полезно посмотреть, не закрывает ли задачу плагин вроде Clearfy Pro, если вам нужен быстрый контроль дублей, архивов и технической чистки сайта. Но даже с плагином стоит проверить, что именно он меняет в HTML и не конфликтует с SEO-настройками темы.
Практические советы по безопасности и производительности
Любой код, который работает с запросами, должен быть минимальным и предсказуемым. Не тяните тяжёлые проверки в каждый запрос без необходимости. Если вы добавляете редиректы, используйте wp_safe_redirect(), а не произвольный header(). Если закрываете страницы от индексации, не делайте это на уровне шаблона с лишними SQL-запросами.
Для больших сайтов лучше вынести логику в отдельный мини-плагин. Так её проще отключить, протестировать и перенести между темами. А если у вас уже есть SEO-плагин, сначала проверьте его встроенные возможности: иногда точечная настройка решается без кода и без риска сломать обновление темы.
Если задача шире, чем один параметр, и нужно одновременно чистить дубли, архивы и служебные страницы, имеет смысл собрать это в один технический регламент: какие URL индексируются, какие закрываются, какие редиректятся, а какие остаются только для пользователя. Именно такая схема обычно работает стабильнее, чем набор разрозненных правок.