Дубли URL с параметрами — типичная проблема для WordPress-сайтов, где в адресах появляются ?utm=, ?replytocom=, фильтры, сортировки или служебные параметры. Поисковик видит такие страницы как отдельные URL, а сайт начинает распылять сигналы: часть ссылок уходит на дубли, часть страниц индексируется не так, как вы ожидали.
На практике задача не в том, чтобы «запретить всё подряд», а в том, чтобы оставить поисковику одну основную версию страницы и не мешать обходу нужных разделов. Для этого обычно комбинируют canonical, аккуратные правила в robots.txt и, если нужно, правки на уровне темы или плагина.
Когда проблема действительно есть
Сначала стоит убедиться, что речь именно о дублях, а не о нормальном поведении сайта. Если в индексе много URL с параметрами, это видно в отчётах Search Console, в логах сервера или просто через поиск по сайту. Часто всплывают такие сценарии:
- страницы с
?replytocom=после комментариев; - UTM-метки в ссылках из рассылок и рекламы;
- параметры сортировки и фильтров в каталогах и архивах;
- служебные параметры от темы, плагина или виджета;
- страницы пагинации, которые дублируют основной контент без явной канонической связи.
Что проверить до правок
Не начинайте с robots.txt вслепую. Сначала посмотрите, как именно WordPress и плагины формируют ссылки. Если параметр добавляется в навигации, в хлебных крошках или в кнопках шаринга, его лучше убрать у источника, а не только закрывать от индексации.
- откройте несколько проблемных URL и сравните
<link rel="canonical">; - проверьте, не меняется ли контент страницы при разных параметрах;
- посмотрите, не блокирует ли текущий
robots.txtважные CSS/JS или разделы; - убедитесь, что в sitemap попадают только чистые URL без параметров.
Какой подход выбрать: canonical, noindex или robots.txt
Здесь часто ошибаются: пытаются закрыть всё через robots.txt, хотя поисковику нужно не просто не ходить по URL, а понимать, какая версия страницы основная. Для разных типов параметров подходят разные инструменты.
| Сценарий | Что делать | Компромисс |
|---|---|---|
| UTM и рекламные метки | Оставить доступ, поставить canonical на чистый URL | Параметр может оставаться в логах и аналитике |
replytocom и похожие служебные параметры | Убрать генерацию ссылки или добавить canonical | Иногда нужен дополнительный фильтр в теме |
| Фильтры и сортировки | Закрывать выборочно, в зависимости от ценности страницы | Риск потерять полезные посадочные страницы |
| Технические дубли | Исправить генерацию URL и редиректы | Требует правки кода или плагина |
Если страница не должна индексироваться вообще, тогда уместен noindex. Если URL просто дублирует основной контент, чаще достаточно canonical. robots.txt полезен для обхода мусорных URL, но он не решает вопрос канонизации сам по себе.
Пошаговое решение для WordPress
1. Уберите генерацию лишних параметров там, где это возможно
Например, если на сайте всплывают ссылки с replytocom, проверьте тему и плагины комментариев. Иногда достаточно отключить одну опцию или заменить шаблон вывода ссылок. Если параметр добавляет ваш код, проще исправить источник, чем потом бороться с последствиями в индексации.
2. Настройте canonical для страниц с параметрами
WordPress и многие SEO-плагины уже выводят canonical автоматически. Но если у вас кастомный шаблон или нестандартный архив, проверьте, что canonical указывает на чистую версию URL без параметров.
<?php
add_action('wp_head', function () {
if (is_singular()) {
global $post;
if ($post instanceof WP_Post) {
echo '<link rel="canonical" href="' . esc_url(get_permalink($post)) . '" />' . "\n";
}
}
}, 1);Этот пример показывает принцип: canonical должен вести на основную версию записи. Если у вас уже есть SEO-плагин, не дублируйте тег вручную, иначе получите конфликт и две канонические ссылки на странице.
3. Добавьте точечные правила в robots.txt
Если на сайт регулярно приходят мусорные параметры, можно ограничить обход отдельных шаблонов URL. Но не закрывайте всё подряд. Плохой вариант — запретить целые разделы, которые должны индексироваться.
User-agent: *
Disallow: /*?replytocom=
Disallow: /*?utm_
Disallow: /*?fbclid=
Sitemap: https://example.com/sitemap_index.xmlТакой подход не делает страницы «невидимыми» для поисковика, но снижает вероятность лишнего обхода. Если URL уже в индексе, одного robots.txt обычно мало: нужен canonical, а иногда и редирект.
4. Для фильтров и сортировки решите, что индексировать, а что нет
Если у вас есть страницы с фильтрами, не все из них надо закрывать. Посадочные страницы по популярным сочетаниям могут быть полезны, а бесконечные комбинации параметров — нет. Здесь лучше действовать по списку: ценным фильтрам дать чистые ЧПУ-адреса, остальное закрыть от индексации или привести к основной странице.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой. Откройте проблемный URL и убедитесь, что:
- canonical ведёт на чистый адрес без параметров;
- страница с параметром не попала в sitemap;
- в
robots.txtнет лишних запретов для важных разделов; - в Search Console новый URL не получает статус «дублируется, отправленный URL не выбран как канонический» без причины;
- при повторном обходе поисковик видит основную версию страницы.
Полезно сравнить заголовки ответа сервера для чистого и параметризованного URL. Если параметр должен просто склеиваться с основной страницей, а сервер отдаёт отдельный HTML без canonical, это уже не косметика, а техническая ошибка.
curl -I "https://example.com/page/?utm_source=test"
curl -I "https://example.com/page/"Если ответы отличаются только кодом и заголовками, а контент тот же, canonical должен быть особенно аккуратным. Если же параметр меняет содержимое, например сортировку или фильтр, решение надо принимать отдельно для каждого типа URL.
Частые ошибки и как их исправить
Закрыли нужные страницы в robots.txt
Это самая неприятная ошибка. Поисковик перестаёт обходить URL, но старые версии могут ещё долго висеть в индексе. Если вы случайно закрыли важный раздел, уберите запрет, верните доступ к странице и дождитесь переобхода.
Поставили canonical на главную вместо основной версии
Иногда разработчики ставят canonical «на всякий случай» на главную страницу сайта. Для дублей это неверно: canonical должен указывать на ближайшую эквивалентную страницу, а не на произвольный URL.
Дублируете canonical через тему и SEO-плагин
Если в wp_head уже выводится canonical от плагина, ручная вставка создаст конфликт. В HTML может оказаться два canonical-тега, и поисковик выберет один из них не так, как вы ожидали.
Пытаетесь решить всё через noindex
noindex полезен для страниц, которые не должны попадать в поиск, но для дублей он не всегда лучший вариант. Если страница должна склеиться с основной, canonical обычно понятнее и безопаснее.
Практические советы по безопасности и производительности
Чем меньше лишних параметров и переадресаций, тем проще и быстрее сайт обрабатывается и браузером, и поисковым роботом. Не стоит строить сложную логику на каждом запросе в template_redirect, если проблему можно решить на уровне генерации ссылок или настроек плагина.
Если вы правите код темы, держите изменения в дочерней теме или в небольшом mu-plugin. Так проще обновлять основной шаблон и не потерять исправления. Для массовой чистки дублей и служебных элементов в WordPress иногда удобнее использовать инструменты вроде Clearfy Pro, если задача совпадает с его набором функций: удаление дублей, чистка сайта и контроль технических SEO-настроек.
Главное правило здесь простое: сначала убираем источник дубля, затем задаём canonical, и только потом при необходимости ограничиваем обход в robots.txt. Если сделать наоборот, можно получить красивую конфигурацию на бумаге и хаос в индексации на практике.