Дубли с параметрами в URL — типичная проблема для WordPress-сайтов, где в адреса попадают ?utm_, ?replytocom, сортировки, фильтры, пагинация или служебные параметры плагинов. Снаружи это выглядит безобидно, но для поисковиков такие URL часто становятся отдельными страницами, а для владельца сайта — источником размывания индекса и лишних обходов.
Ниже разберём, как быстро найти такие дубли, что можно закрыть на уровне шаблона, а что лучше решать через сервер и настройки SEO-плагина. Без магии: только рабочие подходы, которые можно проверить руками.
Когда проблема действительно есть
Сначала стоит убедиться, что речь именно о дублях, а не о нормальных посадочных страницах с параметрами. На практике проблема проявляется так:
- в поиске находятся одинаковые страницы с разными параметрами в конце URL;
- в отчётах сканирования много адресов вида
/post/?utm_source=...или/category/page/2/?sort=...; - в индексе всплывают страницы с сортировкой, фильтрами, внутренним поиском или трекингом;
- канонический URL указывает на одну страницу, а в индексе живут её копии.
Что проверить в первую очередь
Откройте несколько проблемных URL и сравните:
<link rel="canonical">в исходном коде;- мета-тег robots, если он есть;
- ответ сервера: 200, 301 или 404;
- есть ли одинаковый контент при разных параметрах.
Если параметр меняет только трекинг или сортировку, а контент по сути тот же, это кандидат на каноникализацию или закрытие от индексации.
Как найти дубли с параметрами
Самый быстрый путь — посмотреть, какие URL уже попали в индекс и какие из них содержат параметры. Для этого полезны:
- отчёт «Страницы» в Google Search Console;
- логи сервера, если нужно понять, что реально сканирует бот;
- краулер вроде Screaming Frog или Sitebulb;
- поиск по сайту через оператор
site:с параметрами в URL.
Если у вас есть доступ к логам, ищите запросы с ? и повторяющимися путями. Это помогает отличить редкий мусорный трафик от системной проблемы.
Что делать: сравнение подходов
| Подход | Когда подходит | Минус |
|---|---|---|
| Canonical | Параметр не меняет смысл страницы | Не всегда быстро убирает URL из индекса |
| Noindex | Страница нужна пользователю, но не поиску | Нужно следить, чтобы страница не блокировалась robots.txt раньше noindex |
| 301 redirect | Параметр вообще не нужен | Нельзя применять к полезным страницам с фильтрами или сортировкой |
| robots.txt | Нужно снизить обход мусорных URL | Не решает проблему индексации сам по себе |
Пошаговое решение для WordPress
1. Уберите лишние параметры там, где они не нужны
Если параметр служебный и не должен влиять на контент, лучше отдать поисковику чистый URL. Для этого можно настроить редирект на уровне сервера или через WordPress, если речь о простом случае.
<?php
add_action('template_redirect', function () {
if (is_admin()) {
return;
}
$remove_params = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'replytocom'];
$has_bad_param = false;
foreach ($remove_params as $param) {
if (isset($_GET[$param])) {
$has_bad_param = true;
break;
}
}
if (!$has_bad_param) {
return;
}
$clean_url = remove_query_arg($remove_params);
wp_safe_redirect($clean_url, 301);
exit;
});Этот вариант годится для трекинговых параметров и replytocom, если вы не используете его как часть важного сценария. Для фильтров каталога или сложной сортировки такой редирект может сломать навигацию.
2. Добавьте canonical для страниц с допустимыми параметрами
Если параметр нужен пользователю, но не должен создавать отдельную страницу в индексе, canonical обычно безопаснее, чем редирект. В WordPress это можно сделать через фильтр SEO-плагина или через вывод в wp_head.
<?php
add_action('wp_head', function () {
if (is_admin()) {
return;
}
if (!empty($_GET['sort']) || !empty($_GET['filter'])) {
$canonical = remove_query_arg(['sort', 'filter']);
echo '<link rel="canonical" href="' . esc_url($canonical) . '" />' . "\n";
}
}, 1);Важно: canonical должен указывать на действительно существующую чистую страницу. Если вы ставите каноникал на URL, который сам отдаёт 404 или редиректит, пользы не будет.
3. Закройте мусорные параметры от индексации через SEO-плагин
Если у вас уже стоит SEO-плагин, проверьте, умеет ли он задавать noindex для страниц поиска, архивов с параметрами или отдельных шаблонов. Это удобнее, чем писать всё вручную, если проблема массовая.
Для сайтов с большим количеством технических дублей иногда проще использовать инструменты чистки и управления SEO-настройками, например Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином нужно понимать, какие именно URL вы закрываете и почему.
4. Ограничьте индексацию на уровне robots.txt только для обхода
Если бот постоянно тратит бюджет на мусорные URL, можно добавить директивы в robots.txt. Но это не замена canonical или noindex: если URL уже в индексе, robots.txt сам по себе не уберёт его оттуда.
User-agent: *
Disallow: /*?replytocom=
Disallow: /*?utm_
Disallow: /*?sort=
Disallow: /*?filter=Такой вариант полезен как дополнительная мера, но не как единственная. Сначала решайте судьбу страницы, потом ограничивайте обход.
Как проверить, что решение сработало
После внедрения не ограничивайтесь визуальной проверкой. Нужны конкретные признаки:
- URL с параметрами отдают 301 на чистый адрес, если вы выбрали редирект;
- в исходном коде у проблемной страницы canonical указывает на чистый URL;
- в Search Console уменьшается число проиндексированных URL с параметрами;
- краулер перестаёт находить новые дубли в обходе;
- в логах снижается количество запросов к мусорным адресам.
Проверять лучше в таком порядке: сначала ответ сервера, потом HTML, потом отчёты поисковиков. Если смотреть только на Search Console, можно пропустить техническую ошибку в шаблоне.
Частые ошибки и как их исправить
Закрыли URL в robots.txt, но не поставили canonical
В результате бот перестаёт обходить страницу, но старый URL может остаться в индексе. Если нужен именно вывод из индекса, сначала настройте canonical или noindex, затем ограничивайте обход.
Сделали 301 на все параметры подряд
Это ломает полезные фильтры, сортировки и страницы с состоянием интерфейса. Перед редиректом проверьте, влияет ли параметр на пользовательский сценарий. Если влияет — чаще нужен canonical или noindex, а не редирект.
Поставили canonical на несуществующую страницу
Такой canonical поисковик может проигнорировать. Канонический адрес должен быть доступен по 200 и содержать тот же основной контент.
Оставили несколько источников дублей одновременно
Например, плагин SEO выводит canonical, тема добавляет свой, а кастомный код ещё один. В итоге поисковик получает противоречивые сигналы. На странице должен быть один понятный canonical.
Практические советы по безопасности и производительности
Если вы пишете обработку параметров в теме или плагине, не собирайте URL вручную из $_SERVER['REQUEST_URI'] без необходимости. Используйте remove_query_arg(), add_query_arg() и wp_safe_redirect() — так меньше шансов сломать адрес или открыть лишнюю поверхность для ошибок.
Не ставьте тяжёлые проверки на каждый запрос, если проблема касается только нескольких шаблонов. Лучше ограничить код условием по типу страницы, например для записей, архивов или поиска. Это снижает нагрузку и упрощает отладку.
Если дубли порождает плагин фильтрации, проверьте его настройки до написания кода. Иногда достаточно отключить индексируемые параметры или изменить способ формирования URL, чтобы не плодить новые адреса каждый день.
Короткий чек-лист перед публикацией правок
- Определить, какие параметры нужны пользователю, а какие служебные.
- Для служебных параметров настроить 301 на чистый URL.
- Для полезных параметров оставить страницу доступной, но поставить canonical на основную версию.
- Проверить, не конфликтуют ли правила с SEO-плагином и темой.
- Сверить ответ сервера, canonical и robots meta на нескольких URL.
- Проверить логи и Search Console через несколько дней после изменений.
Если у сайта уже накопилось много дублей, не пытайтесь решить всё одним правилом для всех параметров. Сначала разделите URL по смыслу: трекинг, сортировка, фильтры, поиск, служебные хвосты. Для каждой группы обычно нужен свой способ обработки.