Параметры в URL — одна из самых частых причин, почему в WordPress появляются десятки почти одинаковых страниц: ?utm_source=, ?sort=, ?filter=, ?replytocom=, служебные параметры плагинов и темы. Для пользователя это один и тот же контент, а для поисковика — разные адреса. В итоге расползается индексация, в отчётах растут дубли, а канонический URL иногда выбирается не тот, который нужен вам.
Ниже — рабочая схема: как найти такие URL, как понять, какие из них реально вредят, и что делать на уровне WordPress, сервера и поисковой оптимизации.
Когда проблема действительно в параметрах URL
Сначала важно не лечить не ту причину. Параметры URL дают дубли, если они меняют адрес, но не меняют смысл страницы или меняют его незначительно. Типичный пример — карточка статьи с UTM-метками, сортировка в архиве, пагинация с лишними параметрами, комментарии с replytocom.
Проверять стоит не только Search Console. Откройте несколько вариантов URL вручную и сравните:
- одинаковый ли заголовок страницы;
- совпадает ли основной текст;
- меняется ли canonical;
- не создаёт ли параметр отдельную страницу в карте сайта;
- не индексируется ли адрес в
site:-поиске.
Быстрый признак, что это именно дубль
Если URL с параметром открывается, отдаёт 200 OK и показывает тот же контент, что и чистый адрес, это уже кандидат на дубль. Если при этом в HTML отсутствует корректный rel="canonical" на основную страницу, проблема почти наверняка техническая, а не контентная.
Диагностика: где искать лишние URL
Удобнее идти от источников, которые реально создают параметры. Обычно это:
- рекламная разметка:
utm_*,gclid,fbclid; - сортировка и фильтры в архивах;
- комментарии WordPress:
replytocom; - поисковые формы с параметром
s; - плагины, которые добавляют служебные query vars;
- внутренние ссылки, где тема или блоки вставляют URL с параметрами.
Для проверки удобно выгрузить список URL из логов сервера, Search Console или аналитики и посмотреть, какие параметры встречаются чаще всего. Если у вас есть доступ к серверным логам, можно быстро отфильтровать запросы с вопросительным знаком:
grep -E '\?.+=' /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -50Это не заменяет полноценный аудит, но быстро показывает, какие параметры реально живут на сайте.
Что делать: рабочая схема без лишнего риска
Универсального решения нет. Для каждого типа параметров подход разный: где-то нужен noindex, где-то canonical, а где-то лучше вообще убрать параметр из генерации ссылок.
| Подход | Когда использовать | Плюс | Минус |
|---|---|---|---|
| Canonical | Когда параметр не меняет смысл страницы | Сохраняет доступность URL | Не всегда быстро убирает дубли из индекса |
| Noindex | Для служебных или малополезных вариантов | Прямо ограничивает индексацию | Нужно следить, чтобы страница не блокировалась robots.txt раньше времени |
| Редирект 301 | Когда параметр не нужен вообще | Убирает дубль на уровне URL | Нельзя применять к параметрам, которые реально нужны пользователю |
1. Уберите параметр из генерации ссылок
Если параметр добавляет тема или ваш код, лучше исправить источник, а не маскировать последствия. Например, не стоит оставлять UTM в внутренних ссылках. Для WordPress это обычно решается на уровне шаблона или фильтра вывода меню, кнопок и блоков.
Пример: если в теме где-то формируется ссылка с параметрами, соберите чистый URL до вывода:
<?php
$url = add_query_arg(
array(
'utm_source' => 'newsletter',
'utm_medium' => 'email',
),
home_url( '/novosti/' )
);
// Для внутренних ссылок так делать не нужно — здесь пример только для внешней разметки.
echo esc_url( $url );
Для внутренних страниц лучше хранить и выводить чистый адрес, а параметры добавлять только там, где они действительно нужны для аналитики.
2. Поставьте canonical на основную версию
Если параметр нужен для интерфейса, но не должен создавать отдельную страницу, canonical должен указывать на чистый URL. В большинстве тем WordPress это уже делает ядро и SEO-плагины, но при нестандартной логике лучше проверить вручную.
Если нужно принудительно поправить canonical для конкретного набора параметров, можно использовать фильтр wpseo_canonical в Yoast SEO или аналогичный механизм вашего SEO-плагина. Но применять это стоит только если вы точно понимаете, какой URL должен считаться основным.
<?php
add_filter( 'wpseo_canonical', function( $canonical ) {
if ( isset( $_GET['sort'] ) ) {
return remove_query_arg( array( 'sort' ), home_url( add_query_arg( array(), $GLOBALS['wp']->request ) ) );
}
return $canonical;
} );
Этот пример нужно адаптировать под вашу структуру URL. Смысл простой: canonical должен вести на чистую версию страницы без лишнего параметра.
3. Закройте служебные параметры от индексации
Для параметров вроде replytocom или технических query vars обычно достаточно не давать им становиться отдельными индексируемыми страницами. Важно не путать это с полной блокировкой в robots.txt: если вы закроете URL от сканирования слишком рано, поисковик может не увидеть canonical или meta robots.
Если параметр создаёт отдельные страницы только из-за шаблона, иногда проще убрать его обработку в WordPress. Например, для комментариев можно проверить, не генерирует ли тема лишние ссылки на ответ с replytocom, и отключить эту механику, если она не нужна.
Пример: убрать replytocom и не плодить дубли
Параметр replytocom часто появляется на сайтах с комментариями. Он не всегда критичен, но на больших проектах может создавать много лишних URL. Если вы не используете threaded comments или готовы отказаться от этой ссылки, можно убрать её из генерации.
<?php
add_filter( 'comment_reply_link', function( $link ) {
return preg_replace( '/\?replytocom=\d+/', '', $link );
} );
После этого проверьте, не ломается ли ответ на комментарий в вашей теме. Если threaded comments нужны, лучше оставить функциональность, но убедиться, что такие URL не попадают в sitemap и не индексируются как самостоятельные страницы.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой. Нужны как минимум три проверки:
- Откройте URL с параметром и убедитесь, что canonical указывает на чистую страницу.
- Проверьте HTTP-статус: служебный параметр не должен превращаться в отдельную индексируемую страницу без причины.
- Сравните отчёт по страницам с дублями в Search Console через несколько обходов робота.
Если вы меняли canonical или редиректы, проверьте заголовки ответа и HTML. Для быстрой диагностики удобно использовать curl:
curl -I 'https://example.com/article/?utm_source=test'
curl -s 'https://example.com/article/?utm_source=test' | grep -i canonicalЕсли canonical отсутствует, указывает на параметризованный URL или редирект ведёт не туда, решение нужно доработать. Если страница с параметром отдаёт 301 на чистый адрес — это уже хороший признак, но проверьте, не затронули ли вы полезные параметры.
Частые ошибки и как их исправить
Закрыли параметры в robots.txt слишком рано
Это частая ошибка: URL перестаёт сканироваться, но поисковик не видит canonical и не понимает, что делать с дублем. Если страница уже в индексе, сначала лучше дать роботу увидеть canonical или редирект, а не просто запретить обход.
Поставили noindex на все страницы с параметрами подряд
Так можно случайно выкинуть полезные страницы фильтрации или сортировки, если они реально нужны пользователю и дают трафик. Сначала разделите параметры на служебные и пользовательские, потом применяйте правило.
Оставили внутренние ссылки с UTM
Это создаёт самоподдерживающийся поток дублей: сайт сам генерирует параметризованные URL и снова их же раздаёт. Для внутренних переходов UTM не нужны.
Использовали 301 там, где параметр нужен для интерфейса
Если сортировка или фильтр должны работать, редирект убьёт функциональность. В таких случаях лучше canonical, noindex или пересмотр логики шаблона.
Чек-лист перед публикацией правок
- Проверены основные параметры, которые реально встречаются на сайте.
- Для каждого параметра выбран свой сценарий: убрать, canonical, noindex или редирект.
- Внутренние ссылки не содержат UTM и технических query string.
- Canonical на параметризованных URL указывает на чистую версию.
- Служебные URL не попали в sitemap.
- После правок проверены заголовки ответа и HTML на нескольких типах страниц.
Когда лучше не править вручную
Если дублей много, а параметры создаёт сразу несколько плагинов, ручной разбор по шаблонам быстро превращается в поддержку чужого кода. В такой ситуации сначала стоит найти источник генерации URL, а уже потом решать, где править: в теме, в плагине или на уровне SEO-настроек. Иногда проще отключить конфликтующий модуль, чем строить поверх него ещё один слой правил.
Если используете SEO-плагин с инструментами для canonical и meta robots, проверьте, не решает ли он часть задачи без кастомного кода. Но даже тогда полезно оставить у себя понятную схему: какие параметры разрешены, какие редиректятся, а какие просто не должны появляться во внутренних ссылках.