Параметры в URL — частая причина дублей в WordPress. Один и тот же контент может открываться с разными хвостами: ?utm_source=, ?sort=, ?filter=, ?replytocom=. Для пользователя это одна и та же страница, а для поисковика — разные адреса. В итоге расползается индекс, каноникал начинает работать не так предсказуемо, а в отчётах появляются лишние URL.
Задача здесь не в том, чтобы «запретить все параметры подряд». Нужен точечный контроль: оставить рабочие сценарии для аналитики и фильтрации, но убрать мусорные адреса из индекса и из обхода роботом.
Когда проблема действительно есть
Сначала проверьте, что речь именно о дублях, а не о нормальной функциональности. В WordPress параметры часто появляются из-за:
- UTM-меток в рекламных и email-ссылках;
- сортировки и фильтров в каталогах и архивах;
- комментариев с
replytocom; - внутреннего поиска и служебных параметров плагинов;
- пагинации и AJAX-виджетов, которые подмешивают query string.
Как быстро диагностировать
Откройте несколько вариантов одной страницы с разными параметрами и сравните HTML. Если контент одинаковый, а URL меняется, это кандидат на закрытие. Дополнительно проверьте:
- есть ли у варианта с параметром отдельный
<link rel="canonical">; - появляется ли этот URL в Sitemap;
- индексируется ли он в поиске по
site:example.com; - не ломается ли страница без параметра после изменений.
Если у вас уже есть статьи про пагинацию, старые slug и страницы поиска, не смешивайте их с этой задачей. Здесь речь именно о query string, а не о путях.
Что закрывать, а что оставлять
Самая частая ошибка — пытаться закрыть все параметры через robots.txt. Это грубо и часто бесполезно: робот может перестать обходить URL, но дубли уже могут остаться в индексе, если на них есть внешние ссылки. Лучше разделить параметры на группы.
| Тип параметра | Что делать | Комментарий |
|---|---|---|
| UTM, gclid, fbclid | Не индексировать, каноникал на чистый URL | Для аналитики оставить, но не плодить дубли |
| replytocom | Обычно закрывать | Часто создаёт мусорные адреса на страницах комментариев |
| sort, filter, price | Решать отдельно | Если это важные посадочные, закрывать нельзя без проверки |
| служебные параметры плагинов | Смотреть по факту | Иногда нужны для функционала и не должны блокироваться |
Пошаговое решение через canonical и noindex
Если параметр не должен попадать в индекс, самый безопасный путь — отдавать на такой URL noindex,follow и каноникал на чистую версию страницы. Это не мешает пользователю открыть страницу, но подсказывает поисковику, какую версию считать основной.
Вариант через код темы или mu-plugin
Ниже пример, который можно положить в functions.php дочерней темы или в отдельный mu-plugin. Он ставит noindex для страниц с типовыми параметрами и не трогает чистые URL.
<?php
add_action('wp_head', function () {
if (is_admin() || !is_singular() && !is_archive()) {
return;
}
$params = array('utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'gclid', 'fbclid', 'replytocom');
foreach ($params as $param) {
if (isset($_GET[$param])) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
break;
}
}
}, 1);
add_filter('wpseo_canonical', function ($canonical) {
if (!empty($_GET)) {
$remove = array('utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'gclid', 'fbclid', 'replytocom');
$clean = remove_query_arg($remove);
return $clean ? $clean : $canonical;
}
return $canonical;
});Если у вас не Yoast SEO, фильтр wpseo_canonical не сработает. Тогда canonical лучше задавать через SEO-плагин или выводить свой тег аккуратно, чтобы не получить два canonical на странице.
Когда лучше не писать код
Если параметры генерирует плагин фильтров, кеша или аналитики, сначала проверьте его настройки. У многих решений уже есть опции для исключения query string из кеша, индексации или каноникализации. Код нужен тогда, когда штатных настроек нет или они не покрывают ваш сценарий.
Как закрыть параметры на уровне сервера и robots.txt
robots.txt полезен только как дополнительный слой, но не как основное решение. Его имеет смысл использовать для явных служебных параметров, если вы точно понимаете, что они не нужны поисковику и не должны обходиться.
User-agent: *
Disallow: /*?replytocom=
Disallow: /*?utm_
Disallow: /*?gclid=
Disallow: /*?fbclid=Такой подход выглядит просто, но у него есть ограничения: правила с query string поддерживаются не всеми роботами одинаково, а запрет обхода не равен удалению из индекса. Поэтому robots.txt стоит считать вспомогательным инструментом, а не заменой canonical и noindex.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой страницы. Нужна короткая техническая валидация:
- откройте URL с параметром и без параметра;
- сравните canonical в исходнике;
- проверьте наличие
noindexна параметризованной версии; - убедитесь, что страница без параметра индексируется как обычно;
- посмотрите, не сломались ли UTM-метки в аналитике;
- если есть кеш, очистите его и проверьте HTML не только в браузере, но и через
curl.
Пример быстрой проверки:
curl -I 'https://example.com/page/?utm_source=test'
curl -s 'https://example.com/page/?utm_source=test' | grep -i 'robots\|canonical'Если в ответе нет нужного meta robots или canonical всё ещё указывает на параметризованный URL, значит правка не применилась или её перехватывает другой плагин.
Частые ошибки и как их исправить
Закрыли слишком много параметров
Иногда под запрет попадает рабочая сортировка, фильтры каталога или служебные параметры плагина. В результате ломаются посадочные страницы и внутренние сценарии. Исправление простое: оставьте в блокировке только те параметры, которые реально создают дубли, и отдельно проверьте каждый важный URL.
Поставили noindex, но оставили self-canonical
Если страница с параметром каноникалит сама на себя, поисковик получает противоречивый сигнал. Для дублей canonical должен вести на чистую версию, если это действительно одна и та же страница.
Заблокировали в robots.txt и ждёте удаления из индекса
Если URL уже известен поисковику, одного Disallow может быть мало. Нужен доступ робота к странице, чтобы он увидел canonical или noindex, либо удаление через инструменты вебмастера, если речь о старом мусоре.
Не учли кеш
Страница могла уже отдаваться из кеша без новых мета-тегов. После изменений очистите серверный кеш, кеш плагина и CDN, иначе проверка будет ложной.
Безопасность и производительность
Чем меньше лишних URL попадает в обход, тем меньше мусора в логах и отчётах. Но не стоит превращать эту задачу в массовую блокировку всего подряд. Для производительности важнее убрать генерацию дублей на уровне шаблона и плагинов, чем потом пытаться их «лечить» robots.txt.
Если у вас много технических дублей, имеет смысл посмотреть в сторону инструментов для чистки SEO-обвязки и лишних мета-тегов. Например, Clearfy Pro закрывает часть типовых задач по удалению дублей и технической чистке сайта, но даже с таким плагином всё равно нужно проверять, какие параметры он трогает, а какие нет.
Практический ориентир простой: если параметр нужен только для трекинга, он не должен менять индексируемую версию страницы. Если параметр меняет смысл страницы, его нельзя закрывать без отдельной SEO-логики и проверки спроса.