Дубли страниц в WordPress часто появляются не из-за контента, а из-за параметров в URL: ?utm_, ?sort=, ?replytocom=, фильтров, поиска и служебных страниц. Для поисковика это могут быть разные адреса с одинаковым содержимым, а для сайта — лишний обход, распыление сигналов и мусор в индексе.
Если у вас уже есть нормальные канонические страницы, но в отчётах всплывают десятки похожих URL, сначала нужно понять, откуда они берутся. Только потом решать: закрывать от индексации, ставить canonical, редиректить или убирать генерацию таких ссылок совсем.
Как понять, что проблема именно в URL-параметрах
Типичный сценарий выглядит так: одна и та же статья доступна по обычному адресу и по версии с параметром. Например, /post-name/?utm_source=telegram или /category/news/?sort=popular. Визуально страница та же, но для робота это отдельный URL.
Что проверить в первую очередь
- Отчёт по страницам с дублирующимся title и description в SEO-плагине или Search Console.
- Логи обхода: какие URL чаще всего запрашивает бот.
- Ссылки внутри темы и плагинов: не добавляют ли они параметры без необходимости.
- Есть ли на сайте фильтры, сортировка, пагинация, поиск по сайту, трекинговые метки.
Если дубли идут только от маркетинговых меток, обычно достаточно правильно настроить canonical и не индексировать параметризованные версии. Если же параметры меняют выдачу контента, например сортировку товаров или постов, решение уже зависит от того, нужна ли эта страница в поиске.
Диагностика: какие URL реально создают дубли
Начните с выборки из Search Console и серверных логов. Если доступа к логам нет, можно быстро посмотреть, какие параметры попадают в URL на сайте, через поиск по базе и шаблонам темы.
// Быстрый вывод параметров, которые встречаются в текущем запросе на фронтенде.
add_action('wp_footer', function () {
if (empty($_SERVER['QUERY_STRING'])) {
return;
}
echo '<!-- query string: ' . esc_html($_SERVER['QUERY_STRING']) . ' -->';
});Этот приём полезен только для отладки на staging. На проде так делать не стоит: комментарии в HTML не решают проблему, а только помогают увидеть, какие параметры реально ходят по сайту.
Если нужно понять, какие параметры уже присутствуют в URL на уровне запроса WordPress, можно временно логировать их в error log:
add_action('template_redirect', function () {
if (!empty($_GET)) {
error_log('WP query params: ' . wp_json_encode(array_keys($_GET)));
}
});После пары часов наблюдения обычно видно, что именно создаёт шум: utm_*, gclid, fbclid, replytocom, внутренние фильтры, сортировка, параметры поиска.
Что делать: пошаговое решение
Шаг 1. Оставить один канонический URL
Если параметр не меняет смысл страницы, каноническим должен оставаться чистый адрес без параметров. Для большинства UTM-меток это стандартный подход. Важно не делать редирект на уровне аналитики, если метка нужна для трекинга кампаний: поисковику достаточно canonical, а пользователю — нормальная работа страницы.
В WordPress canonical обычно генерируется автоматически, но если тема или плагин его ломают, проверьте исходный код страницы. На параметризованной версии должен быть canonical на чистый URL.
Шаг 2. Закрыть служебные параметры от индексации
Если у вас есть параметры, которые не должны попадать в индекс, можно добавить заголовок X-Robots-Tag для таких запросов. Это особенно удобно для страниц поиска и некоторых фильтров.
add_action('send_headers', function () {
if (is_admin()) {
return;
}
$blocked_params = ['replytocom', 'sort', 'filter', 'utm_source', 'utm_medium', 'utm_campaign'];
foreach ($blocked_params as $param) {
if (isset($_GET[$param])) {
header('X-Robots-Tag: noindex, follow', true);
break;
}
}
});Это не заменяет canonical, а дополняет его. Для поисковика полезно, когда и канонический адрес, и запрет на индексацию параметризованной версии говорят одно и то же.
Шаг 3. Убрать лишние параметры из внутренних ссылок
Если параметры добавляет ваша тема или плагин, лучше не маскировать проблему, а убрать её источник. Например, UTM-метки не должны жить во внутренних ссылках между страницами сайта. То же касается параметров сортировки, если они вставляются в навигацию без необходимости.
Для ссылок, которые вы генерируете сами, используйте чистые URL:
$url = get_permalink($post_id);
echo '<a href="' . esc_url($url) . '">Читать статью</a>';Если нужно сохранить только безопасный набор параметров, фильтруйте их перед выводом:
function wpmobile_allowed_query_args(array $args): array {
$allowed = ['page', 'paged'];
return array_intersect_key($args, array_flip($allowed));
}
$current_args = wpmobile_allowed_query_args($_GET);
$link = add_query_arg($current_args, get_permalink());Шаг 4. Для некоторых параметров сделать 301 на чистый URL
Если параметр не нужен вообще и не влияет на контент, можно редиректить на чистую страницу. Это уместно для мусорных параметров, которые появляются из внешних источников или старых шаблонов.
add_action('template_redirect', function () {
if (is_admin()) {
return;
}
$remove = ['replytocom', 'ref', 'source'];
$has_bad = false;
foreach ($remove as $param) {
if (isset($_GET[$param])) {
$has_bad = true;
break;
}
}
if ($has_bad) {
wp_safe_redirect(remove_query_arg($remove), 301);
exit;
}
});Не редиректите всё подряд. UTM-метки, рекламные параметры и аналитические идентификаторы часто нужны для измерений. Если их убрать 301-редиректом, часть данных в аналитике может потеряться.
Когда лучше использовать плагин, а когда код
| Подход | Когда подходит | Ограничения |
|---|---|---|
| Плагин для SEO | Если нужно быстро настроить canonical, noindex и robots без правки кода | Не всегда удобно точечно управлять редиректами по параметрам |
| Код в теме или mu-plugin | Если параметры создаёт конкретный шаблон, плагин или кастомная логика | Нужно тестировать после обновлений темы |
| Комбинированный вариант | Если часть дублей закрывается SEO-настройками, а часть — редиректами | Важно не задублировать правила и не получить конфликт |
Если у вас уже стоит SEO-плагин, сначала проверьте его настройки для архивов, поиска и параметров. Если проблема точечная и связана с кастомной логикой, проще и надёжнее решить её кодом в mu-plugin, чем размазывать по нескольким плагинам.
Проверка результата после внедрения
После изменений не ограничивайтесь визуальной проверкой. Откройте чистый URL и URL с параметром, затем сравните исходный код страницы и заголовки ответа.
- У параметризованной страницы canonical указывает на чистый URL.
- Для ненужных параметров возвращается 301 на основной адрес.
- Внутренние ссылки больше не содержат мусорных параметров.
- Страницы поиска и фильтров не попадают в индекс без необходимости.
- В Search Console уменьшается число дублей и странных URL в отчётах обхода.
Дополнительно проверьте ответ сервера через curl:
curl -I "https://example.com/post-name/?replytocom=123"
curl -I "https://example.com/post-name/?utm_source=test"В первом случае вы должны увидеть редирект или noindex, во втором — корректный canonical без поломки страницы.
Частые ошибки и как их исправить
Редиректят UTM-метки и ломают аналитику
Это самая частая ошибка. Если параметр нужен маркетингу, не удаляйте его редиректом без согласования. Лучше оставить параметр в URL для трекинга, но закрыть его от индексации и указать canonical на чистую страницу.
Ставят noindex на саму основную страницу
Иногда правило пишут слишком грубо и под него попадает весь архив или весь тип записей. Проверяйте условие: noindex должен срабатывать только на конкретных параметрах, а не на всех страницах подряд.
Дубли остаются из-за внутренних ссылок
Если тема или плагин продолжают генерировать URL с параметрами, поисковик будет снова и снова обходить эти адреса. В таком случае править нужно источник ссылок, а не только индексацию.
Конфликтуют редиректы и canonical
Если одна часть кода редиректит URL, а другая оставляет его доступным и каноническим, поведение становится непредсказуемым. Сначала определите один сценарий для каждого параметра: либо редирект, либо canonical + noindex.
Что ещё стоит проверить ради безопасности и производительности
Параметры URL часто используются не только для дублей, но и для мусорного трафика, который нагружает сайт. Если ботам и скриптам легко генерировать бесконечные комбинации параметров, сервер будет тратить ресурсы на бессмысленные запросы.
Практически полезно:
- ограничить генерацию ссылок с параметрами в шаблонах;
- не индексировать внутренний поиск, если он не даёт ценного трафика;
- проверить, не создаёт ли плагин бесконечные комбинации фильтров;
- следить за логами 404 и редиректов после внедрения правил.
Если у вас много технических дублей, удобно держать под рукой инструменты для чистки SEO-артефактов и дубликатов. В экосистеме WPShop для этого часто используют Clearfy Pro, но даже с ним важно понимать, какие именно URL вы закрываете и зачем: автоматическая настройка не заменяет диагностику.
Главный ориентир простой: если параметр не меняет смысл страницы, он не должен создавать отдельный индексируемый URL. Если меняет — у него должен быть осознанный статус, а не случайное поведение по умолчанию.