Если в Search Console начинают всплывать дублированные страницы, а в исходном коде у разных URL повторяются одинаковые title, meta description и rel="canonical", проблема часто не в контенте, а в шаблонах темы, SEO-плагине или нескольких источниках генерации мета-данных одновременно. На практике это выглядит так: одна и та же запись доступна по основному URL, по страницам архива, по параметрам сортировки, по пагинации и иногда по служебным версиям с ?amp, ?replytocom или UTM-параметрами. Поисковик видит это как набор похожих страниц и сам выбирает, что считать каноническим. Не всегда удачно.
Когда дубли метаданных реально мешают индексации
Проблема заметна не только по отчетам о дублях. Есть несколько типичных симптомов, которые можно проверить руками:
- в выдаче показывается не та страница, которую вы продвигаете;
- в HTML у разных URL одинаковый
titleиdescription; - на страницах архива и пагинации стоит один и тот же canonical на первую страницу или, наоборот, canonical отсутствует;
- SEO-плагин и тема одновременно выводят мета-теги;
- в индекс попадают служебные URL с параметрами, хотя они не нужны для поиска.
Если у вас уже есть плагин для SEO, сначала проверьте, не дублирует ли тема его вывод. Это частая причина, когда в коде страницы видно по два meta description или несколько canonical.
Диагностика: где именно рождается дубль
Начинать лучше не с правок, а с проверки источника. Откройте проблемный URL и посмотрите исходный код страницы. Ищите:
<title>и<meta name="description">;<link rel="canonical">;noindexв robots meta;- повторяющиеся теги, которые выводятся дважды.
Если есть доступ к серверу, полезно быстро проверить заголовки и HTML через curl:
curl -I https://example.com/page/Для более точной проверки метаданных можно посмотреть фрагмент HTML:
curl -s https://example.com/page/ | grep -iE 'canonical|meta name="description"|<title>'Если canonical указывает на другой URL, а страница при этом должна индексироваться отдельно, значит правило формируется не там, где вы ожидаете. Обычно это либо SEO-плагин, либо фильтр в теме, либо хук в кастомном плагине.
Что делать: пошаговое решение без лишней магии
1. Оставьте один источник мета-данных
Если используется SEO-плагин, отключите вывод title/description/canonical в теме. В нормальной схеме тема не должна печатать SEO-мета вручную, если этим занимается плагин. Проверьте файлы header.php, functions.php и шаблоны архивов.
Если вы поддерживаете собственную тему и хотите убрать дубли на уровне кода, можно оставить генерацию canonical только для тех страниц, где WordPress не делает это сам или где нужен контроль. Пример ниже убирает лишний canonical для архивов с параметрами сортировки и сохраняет базовый URL без query string:
add_filter('get_canonical_url', function ($canonical, $post) {
if (is_admin() || ! $canonical) {
return $canonical;
}
$canonical = remove_query_arg(array('utm_source', 'utm_medium', 'utm_campaign', 'replytocom', 'sort', 'orderby'), $canonical);
return $canonical;
}, 10, 2);Этот вариант не решает все сценарии, но хорошо убирает мусорные параметры, которые часто плодят дубли.
2. Закройте служебные параметры от индексации
UTM, replytocom, сортировка и фильтры не должны создавать отдельные индексируемые страницы. Если они нужны пользователям, но не нужны поиску, canonical должен указывать на чистый URL без параметров. Для некоторых шаблонов можно дополнительно ставить noindex на страницы с параметрами:
add_action('wp_head', function () {
if (is_admin()) {
return;
}
$params = array('replytocom', 'utm_source', 'utm_medium', 'utm_campaign', 'sort', 'orderby');
foreach ($params as $param) {
if (isset($_GET[$param])) {
echo "<meta name=\"robots\" content=\"noindex,follow\" />\n";
break;
}
}
}, 1);Важно: не ставьте noindex на все подряд. Если параметр используется для реальной навигации по сайту, сначала проверьте, не ломаете ли вы доступность нужных страниц.
3. Исправьте архивы и пагинацию
Частая ошибка — когда первая страница архива и все последующие страницы имеют одинаковый canonical на первую. Для поисковика это сигнал, что страницы 2, 3, 4 не самостоятельны. Иногда это правильно, но не всегда. Если на пагинации есть уникальный набор записей, canonical должен вести на саму страницу пагинации, а не на первую страницу архива.
Проверьте, как это делает ваша тема. Если canonical подменяется вручную, уберите эту логику и дайте WordPress или SEO-плагину сформировать его корректно. Если нужна точечная правка, используйте фильтр, а не прямой вывод в шаблоне.
Сравнение подходов: плагин, код или правка темы
| Подход | Когда подходит | Минусы |
|---|---|---|
| SEO-плагин | Нужно централизованно управлять title, description, canonical и robots | Конфликтует с самописным выводом в теме, если не убрать дубли |
| Код в теме/дочерней теме | Нужна точечная логика для параметров, архивов, отдельных шаблонов | Легко сломать при обновлении, если править не в child theme |
| Комбинированный вариант | SEO-плагин отвечает за базу, код — за редкие исключения | Нужно дисциплинированно разделить зоны ответственности |
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой. Смотрите на конкретные признаки:
- в исходном коде страницы остался один
title, одинmeta descriptionи один canonical; - canonical указывает на нужный URL без лишних параметров;
- страницы с UTM и сортировкой не попадают в индекс как отдельные документы;
- в Search Console уменьшается количество URL, отмеченных как дублированные или выбранные неканонические.
Для быстрой локальной проверки удобно снова использовать curl и сравнить несколько адресов:
curl -s https://example.com/post/ | grep -i canonical
curl -s 'https://example.com/post/?utm_source=test' | grep -i canonicalЕсли canonical одинаковый и ведет на чистый URL, это хороший знак. Если на параметризованной странице canonical отсутствует или указывает на сам параметризованный URL, правку нужно доработать.
Частые ошибки и как их исправить
Дубли выводятся и темой, и плагином
Это самый частый сценарий. Решение простое: оставьте один источник. Если SEO-плагин уже управляет мета-данными, удалите ручной вывод из header.php и связанных шаблонов.
Canonical переписывается слишком агрессивно
Иногда разработчик пытается всегда убирать все query string. В результате ломаются страницы поиска, фильтры или пагинация. Убирайте только те параметры, которые действительно не должны индексироваться.
Noindex ставится на нужные страницы
Если правило срабатывает по слишком общему условию, можно случайно закрыть от индексации нормальные записи. Проверяйте логику через конкретные URL, а не по общему шаблону.
Правки внесены в родительскую тему
После обновления все изменения исчезнут. Для кастомной логики используйте дочернюю тему или отдельный мини-плагин.
Чек-лист перед публикацией правок
- проверен исходный код страницы на дубли
title,descriptionиcanonical; - определен единственный источник мета-данных;
- служебные параметры не создают отдельные индексируемые URL;
- canonical на архиве и пагинации соответствует реальному сценарию;
- правки вынесены в дочернюю тему или отдельный плагин;
- после изменений проверены несколько URL с параметрами и без них.
Практика безопасности и производительности
Не добавляйте тяжелую логику в wp_head без необходимости. Если вы на каждой странице делаете сложные проверки по множеству параметров, это лишняя нагрузка на генерацию HTML. Для точечных условий достаточно простых проверок isset($_GET['...']) и раннего выхода.
Если вы используете сторонний SEO-плагин, не пытайтесь дублировать его функции в теме. Лучше оставить один слой ответственности. Для технической чистки и контроля дублей в WordPress иногда удобнее подключать специализированные инструменты вроде Clearfy Pro, но только если они не конфликтуют с уже настроенной SEO-логикой и не подменяют то, что вы контролируете вручную.
Когда проблема затрагивает десятки шаблонов, сначала исправляйте базовую архитектуру: один источник мета-данных, один canonical-слой, отдельная логика для параметров. Это надежнее, чем точечно латать каждую страницу вручную.