Лишние параметры в URL в WordPress обычно появляются не из-за одной ошибки, а из-за набора мелочей: UTM-метки, сортировки, фильтры, служебные query string, параметры от плагинов и темы. Проблема в том, что для пользователя это просто длинная ссылка, а для поисковика — отдельный адрес. Если такие URL начинают индексироваться, вы получаете дубли, размывание веса и лишнюю нагрузку на обход.
Ниже — практический сценарий: как понять, какие параметры действительно вредят, что лучше закрывать canonical, что лучше редиректить, а что вообще не трогать. Без попытки «почистить всё подряд».
Когда параметры в URL становятся проблемой
Не каждый query string нужно удалять. Например, ?utm_source= нужен аналитике, но не должен становиться отдельной страницей в индексе. А вот ?replytocom=, ?orderby=, ?filter= или параметры пагинации в неправильной комбинации уже могут создавать мусорные версии страниц.
Типичный симптом — в поиске всплывают адреса с параметрами, а в Search Console растёт число URL, которые отличаются только хвостом после знака ?. Ещё один признак — каноникал указывает на чистый URL, но в индексе всё равно есть параметризованные версии, потому что где-то на сайте на них есть внутренние ссылки.
Что обычно можно оставить как есть
- UTM-метки для аналитики, если они не попадают во внутренние ссылки.
- Параметры, которые нужны только для фронтенд-логики и не создают отдельный контент.
- Служебные параметры, которые не индексируются и не участвуют в навигации.
Что чаще всего нужно убирать или нормализовать
- Параметры сортировки и фильтрации, если они создают дубли контента.
- Параметры комментариев и предпросмотра, если они доступны из поиска.
- Ссылки с техническими хвостами, которые появляются из-за темы или плагина.
Диагностика: откуда берутся лишние URL
Сначала не меняйте код. Сначала найдите источник. Иначе легко закрыть не тот параметр и сломать рабочую навигацию.
- Откройте Search Console и посмотрите, какие URL с параметрами уже попали в отчёты по страницам.
- Проверьте логи сервера или хотя бы статистику обхода: какие адреса чаще всего запрашивает бот.
- Посмотрите исходный код шаблонов и меню: нет ли внутренних ссылок с параметрами.
- Проверьте, не добавляет ли параметр сам плагин — например, фильтр каталога, кнопка шаринга или трекинг.
Если параметр появляется только в адресной строке после действий пользователя и нигде не используется во внутренних ссылках, обычно достаточно canonical и запрета на индексацию. Если же WordPress сам генерирует такие ссылки в шаблоне, лучше исправлять источник.
Что выбрать: canonical, noindex или редирект
У этих вариантов разная задача. Ошибка многих сайтов — ставить редирект там, где нужен canonical, или наоборот.
| Подход | Когда использовать | Минус |
|---|---|---|
| canonical | Когда параметр нужен пользователю, но основной контент один и тот же | Не убирает URL из обхода полностью |
| noindex | Когда страница с параметром не должна быть в индексе, но доступна для пользователя | Нужно следить, чтобы страница не блокировалась robots.txt до обхода |
| 301 редирект | Когда параметр не нужен вообще и есть однозначная чистая версия URL | Можно сломать функциональность, если параметр реально нужен |
Если коротко: canonical — для дублей, noindex — для мусорных страниц, редирект — для лишних URL без ценности.
Пошаговое решение
Шаг 1. Уберите параметр из внутренних ссылок
Если параметр попадает в меню, хлебные крошки, блоки или шаблонные ссылки, сначала исправьте генерацию URL. Это самый надёжный вариант: поисковику просто нечего будет обходить.
Пример: если тема добавляет параметр к ссылке на архив, лучше формировать чистый URL через стандартные функции WordPress, а не собирать строку вручную.
<?php
$archive_url = get_post_type_archive_link( 'post' );
echo esc_url( $archive_url );
?>Если у вас в коде встречается ручная конкатенация вида $url . '?foo=bar', это первый кандидат на пересмотр.
Шаг 2. Для UTM и похожих параметров задайте canonical на чистую страницу
Если параметр нужен для аналитики или временной кампании, но страница та же самая, canonical должен указывать на URL без параметра. В WordPress это можно сделать через фильтр wpseo_canonical, если используется Yoast SEO, или через собственный вывод <link rel="canonical"> в теме. Ниже пример без привязки к конкретному SEO-плагину: он меняет canonical только для набора параметров, которые вы явно перечислите.
<?php
add_filter( 'get_canonical_url', function( $canonical, $post ) {
if ( is_admin() || ! is_singular() ) {
return $canonical;
}
$allowed = array( 'utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content' );
foreach ( $allowed as $param ) {
if ( isset( $_GET[ $param ] ) ) {
return remove_query_arg( $allowed, $canonical );
}
}
return $canonical;
}, 10, 2 );Этот пример стоит использовать аккуратно: он не должен затронуть параметры, которые реально меняют контент страницы.
Шаг 3. Для мусорных параметров сделайте 301 на чистый URL
Если параметр не нужен ни пользователю, ни аналитике, лучше убрать его редиректом. Самый безопасный вариант — редиректить только конкретные параметры и только на ту же страницу без query string.
<?php
add_action( 'template_redirect', function() {
if ( is_admin() ) {
return;
}
$bad_params = array( 'replytocom', 'orderby', 'filter', 'sessionid' );
foreach ( $bad_params as $param ) {
if ( isset( $_GET[ $param ] ) ) {
$clean_url = remove_query_arg( $bad_params, home_url( add_query_arg( array(), $_SERVER['REQUEST_URI'] ) ) );
wp_safe_redirect( $clean_url, 301 );
exit;
}
}
} );Здесь есть важная оговорка: не редиректите всё подряд на главную. Нужен именно чистый вариант текущей страницы, иначе вы потеряете релевантность и можете создать цепочки редиректов.
Шаг 4. Закройте от индексации страницы, которые должны жить только для пользователя
Если параметризованная версия нужна для интерфейса, но не должна попадать в индекс, добавьте noindex,follow. Это особенно полезно для страниц сортировки и фильтрации, когда редирект невозможен.
Важный момент: не закрывайте такие URL в robots.txt, если поисковик должен увидеть meta robots или canonical. Иначе бот может не дойти до страницы и не увидеть ваш сигнал.
Проверка результата после внедрения
После правок не ограничивайтесь открытием страницы в браузере. Нужно проверить именно то, как адрес видит бот.
- Откройте URL с параметром и убедитесь, что он не создаёт отдельную индексируемую версию.
- Проверьте исходный код: canonical должен вести на чистый адрес.
- Если настроен редирект, убедитесь, что ответ сервера —
301, а не302. - Сравните заголовки ответа и финальный URL после перехода.
- Проверьте Search Console: число параметризованных URL должно перестать расти.
Быстрая проверка через curl помогает увидеть цепочку редиректов и заголовки без влияния браузерного кэша:
curl -I "https://example.com/page/?utm_source=test"
Если вы используете canonical, откройте исходный код страницы и найдите строку rel="canonical". Если там всё ещё параметризованный адрес, значит фильтр не сработал или его перебивает SEO-плагин.
Частые ошибки и как их исправить
Редирект на главную вместо чистой версии
Это самая грубая ошибка. Пользователь теряет контекст, а поисковик получает нерелевантный сигнал. Редирект должен вести на ту же страницу без лишнего параметра.
Закрыли страницу в robots.txt, а canonical не успел сработать
Если бот не может обойти URL, он может не увидеть canonical или noindex. В результате мусорный адрес продолжает жить в индексе дольше, чем нужно.
Параметр убрали из индекса, но оставили внутренние ссылки
Это частая причина повторного появления дублей. Если ссылка есть в меню, блоке или хлебных крошках, поисковик снова найдёт этот URL. Сначала убирайте источник, потом — сигналы индексации.
Сломали фильтры и сортировку
Если параметр реально влияет на выдачу товаров, статей или записей, не редиректите его без анализа. Для таких случаев чаще подходит canonical или noindex, а не 301.
Практические советы по безопасности и производительности
Чем меньше лишних параметров обрабатывает WordPress, тем меньше мусора в логах и тем проще кэширование. Но не стоит пытаться решить всё на уровне сервера без понимания логики сайта.
- Не используйте универсальные правила, которые режут все query string: можно сломать поиск, фильтры и служебные переходы.
- Проверяйте, не создаёт ли параметр отдельную версию страницы в кэше CDN или плагина кэширования.
- Если у вас много технических дублей, имеет смысл посмотреть в сторону инструментов чистки SEO-обвязки и дублей, например Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае логику параметров лучше проверить вручную.
Главный принцип здесь простой: сначала определить, зачем параметр существует, потом выбрать один из трёх сценариев — оставить, нормализовать или убрать. Если сделать наоборот, вы почти наверняка получите либо лишние дубли, либо поломанные ссылки.