На WordPress часто индексируются не только «чистые» страницы, но и их версии с параметрами: ?utm_source=, ?replytocom=, фильтры поиска, сортировки, служебные query string. Для поисковика это разные URL, а для сайта — дубли, которые размывают сигналы и засоряют отчёты в Search Console.
Проблема обычно всплывает после запуска рекламы, подключения внешней аналитики, фильтров в каталоге или комментариев с переходом по якорям. Ниже — как понять, что именно индексируется, и что делать без лишнего риска для важных страниц.
Как понять, что у вас уже есть проблема
Сначала проверьте не только robots.txt, а реальные URL в индексе. Если закрыть шаблонно «всё с параметрами», можно случайно задеть полезные страницы поиска или фильтров, которые должны работать для пользователей.
Что смотреть в первую очередь
- отчёт Страницы в Google Search Console — ищите дубли с параметрами;
- результаты поиска по сайту через
site:example.com inurl:?; - логи сервера или отчёты аналитики — какие параметры реально ходят по сайту;
- исходный код страниц — есть ли корректный
rel="canonical"на чистый URL.
Если на одной и той же записи встречаются адреса с ?utm_*, ?fbclid=, ?gclid= или ?replytocom=, поисковику нужно явно показать, какая версия основная. Одного robots.txt для этого недостаточно: он может запретить обход, но не всегда убирает уже найденный URL из индекса.
Какие варианты решения есть на практике
Для WordPress обычно используют три подхода: каноникал, noindex и редирект. У каждого свой сценарий. Если перепутать их местами, можно испортить индексацию нужных страниц или потерять часть измерений в аналитике.
| Подход | Когда подходит | Ограничение |
|---|---|---|
| Canonical | Для дублей одной и той же страницы с параметрами | Не удаляет URL мгновенно, а только подсказывает основную версию |
| Noindex | Для страниц, которые не должны попадать в поиск, но должны открываться пользователю | Нужно, чтобы поисковик мог увидеть тег при обходе |
| 301 redirect | Для служебных параметров, которые не нужны пользователю | Нельзя редиректить всё подряд, если параметр влияет на контент |
Пошаговое решение для WordPress
1. Нормализуйте канонический URL
Если параметр не меняет содержимое страницы, основная версия должна указывать на чистый адрес. В большинстве тем WordPress это уже делает SEO-плагин, но стоит проверить вручную. Для кастомной логики можно добавить свой canonical через wp_head.
<?php
add_action('wp_head', function () {
if (is_singular()) {
echo '<link rel="canonical" href="' . esc_url(get_permalink()) . '" />' . "\n";
}
}, 1);
Этот пример не заменяет SEO-плагин, а показывает принцип: canonical должен вести на чистый URL без служебных параметров. Если у вас уже есть Yoast SEO, Rank Math или другой плагин, не выводите второй canonical вручную — получите конфликт.
2. Закройте служебные параметры через noindex, если они нужны для просмотра
Иногда страница с параметром должна открываться, но не индексироваться. Например, результаты внутреннего поиска или сортировка. В таком случае лучше добавить noindex,follow только для конкретных query string.
<?php
add_filter('wp_robots', function (array $robots) {
$blocked_params = ['replytocom', 'sort', 'filter', 'utm_source', 'utm_medium', 'utm_campaign'];
foreach ($blocked_params as $param) {
if (isset($_GET[$param])) {
$robots['noindex'] = true;
$robots['follow'] = true;
break;
}
}
return $robots;
});
Это рабочий способ для современных версий WordPress, где используется фильтр wp_robots. Он не ломает страницу для пользователя и даёт поисковику понятный сигнал. Но не применяйте его ко всем параметрам без разбора: некоторые query string могут быть частью важной навигации.
3. Уберите мусорные параметры из внутренней перелинковки
Частая ошибка — сайт сам генерирует ссылки с UTM или другими параметрами внутри шаблона. Тогда поисковик получает новые URL прямо с ваших страниц. Проверьте меню, кнопки, блоки в контенте и виджеты.
Если параметр нужен только для аналитики, лучше добавлять его на уровне рекламных ссылок, а не в шаблоне сайта. Для внутренних переходов используйте чистые адреса, а аналитику собирайте отдельными событиями.
4. Для параметров, которые не нужны вообще, используйте 301
Если параметр не влияет на содержимое и не нужен пользователю, можно перенаправлять его на чистый URL. Это особенно полезно для старых служебных хвостов, которые появились после миграции или интеграции.
<?php
add_action('template_redirect', function () {
$remove_params = ['fbclid', 'gclid'];
foreach ($remove_params as $param) {
if (isset($_GET[$param])) {
$url = remove_query_arg($param, home_url(add_query_arg([], $_SERVER['REQUEST_URI'])));
wp_safe_redirect($url, 301);
exit;
}
}
});
Здесь важно не редиректить параметры, которые реально меняют страницу, например сортировку в каталоге или пагинацию поиска. Для них лучше noindex или canonical, а не принудительный редирект.
Если нужен быстрый путь без кода
Когда сайт уже на SEO-плагине, часть задачи можно закрыть настройками. Но проверяйте, что именно делает плагин: одни умеют ставить canonical, другие — noindex для архивов и параметров, третьи только прячут URL от индексации в интерфейсе.
Если вам нужен более широкий набор инструментов для чистки дублей, технических страниц и служебных настроек, можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином логику параметров лучше проверить вручную, особенно если на сайте есть поиск, фильтры и рекламные метки.
Как проверить, что решение сработало
После внедрения не ограничивайтесь открытием страницы в браузере. Проверьте именно те признаки, по которым поисковик понимает вашу логику.
- в исходном коде есть один canonical на чистый URL;
- для нужных параметров выводится
noindex; - страницы с мусорными параметрами не создают цепочки редиректов;
- в Search Console уменьшается число дублей и страниц с параметрами;
- внутренние ссылки больше не ведут на URL с лишними query string.
Техническая проверка может выглядеть так:
curl -I "https://example.com/page/?utm_source=test"
В ответе смотрите, есть ли 301, какой Location возвращается и не уходит ли запрос в бесконечную цепочку. Если вы используете noindex, проверьте HTML-ответ страницы, а не только заголовки.
Частые ошибки и как их исправить
Закрыли всё через robots.txt
Это частая попытка «быстро убрать из индекса». Но если поисковик не может зайти на страницу, он не увидит canonical и noindex. В итоге URL может остаться в индексе как найденный, но недоступный для обхода. Для дублей с параметрами robots.txt — не первый выбор.
Ставят noindex на все страницы с вопросительным знаком
Так ломают поиск по сайту, фильтры и иногда пагинацию. Нужно фильтровать только конкретные параметры, а не любой URL с query string. Сначала составьте список реально проблемных параметров по логам и аналитике.
Редиректят параметры, которые меняют контент
Если параметр влияет на сортировку, язык, фильтр или состояние формы, 301 может уничтожить полезную функциональность. Пользователь будет попадать не туда, куда ожидал, а поисковик увидит несоответствие контента и URL.
Оставляют UTM во внутренних ссылках
UTM нужны для внешних кампаний, но внутри сайта они создают шум. Для внутренних переходов используйте чистые адреса, а кампании размечайте только там, где это действительно нужно.
Что учесть для безопасности и производительности
Не добавляйте обработку параметров в каждый шаблон отдельно. Лучше централизовать логику в теме или небольшом mu-plugin, чтобы не размножать условия по проекту. Это проще сопровождать и легче отключить при отладке.
Если вы используете $_GET, всегда работайте только с белым списком параметров. Не пытайтесь строить редиректы на основе произвольного значения из запроса без проверки — это уже риск открытого редиректа или некорректного URL.
Для крупных сайтов полезно вести отдельный список параметров, которые разрешены к индексации, и обновлять его после запуска новых фильтров или интеграций. Тогда техническая оптимизация не превращается в ручную борьбу с дублями каждые пару месяцев.