Если в Search Console появляются странные дубли страниц, а в исходном коде у одной и той же записи несколько rel="canonical", проблема обычно не в поисковике, а в шаблоне, SEO-плагине или кастомном коде темы. В WordPress это встречается чаще, чем кажется: один canonical добавляет ядро, второй — плагин, третий — разработчик в wp_head.
Ниже — рабочий порядок действий: как быстро найти источник дубля, как исправить его без поломки индексации и как проверить, что на странице остался ровно один корректный canonical.
Когда проблема действительно в canonical, а не в индексации
Сначала стоит убедиться, что речь именно о конфликте canonical, а не о другом SEO-сигнале. Типичные признаки:
- в HTML страницы видно два и более тега
<link rel="canonical">; - в Search Console одна и та же страница попадает в отчёты как дубликат без выбранного canonical;
- после смены темы или SEO-плагина дубли появляются только на части шаблонов;
- canonical указывает не на текущий URL, а на главную, архив или старую версию адреса.
Если canonical один, но он неправильный, это уже другая задача: нужно искать источник неверного URL. Если canonical несколько, поисковик обычно берёт один из них не так, как вы ожидаете, и это создаёт нестабильную индексацию.
Диагностика: откуда берётся дубль
Проверка начинается с исходного кода страницы. Откройте проблемный URL и найдите все вхождения rel="canonical". Если их больше одного, посмотрите, какой код их выводит: SEO-плагин, тема или кастомный сниппет.
Что проверить в первую очередь
- SEO-плагин: Yoast SEO, Rank Math, All in One SEO и аналоги часто управляют canonical автоматически.
- Тема: в
header.phpили черезwp_headмогли добавить ручной тег. - Плагины для фильтров, пагинации и сортировок: они иногда подменяют canonical на архивных страницах.
- Кастомные функции в
functions.phpили mu-plugin: особенно если проект дорабатывали несколько разработчиков.
Если есть доступ к серверным логам или кода много, удобно временно найти все места, где вызывается rel_canonical() или где вручную печатается тег canonical.
// Быстрый поиск по теме и кастомным плагинам через grep на сервере:
grep -R "rel_canonical\|rel=\"canonical\"" wp-content/themes wp-content/pluginsЭто не заменяет нормальный аудит, но быстро показывает, где искать конфликт.
Пошаговое решение без лишнего риска
Дальше важно не «удалить всё лишнее», а оставить один источник canonical. В WordPress безопаснее всего выбрать один механизм управления SEO-тегами и отключить остальные.
Шаг 1. Определите основной источник canonical
Если сайт работает на SEO-плагине, canonical лучше оставить за ним. Тогда ручной вывод из темы нужно убрать. Если SEO-плагина нет, canonical может генерировать ядро WordPress через rel_canonical(), и этого часто достаточно для обычных записей и страниц.
Шаг 2. Уберите ручной вывод из темы
Если canonical добавлен в header.php или через хук wp_head, удалите этот код. Пример типичной проблемы:
<?php
add_action('wp_head', function () {
echo '<link rel="canonical" href="' . esc_url(home_url('/')) . '" />' . "\n";
});Такой код часто оставляют после временной правки и забывают удалить. Он опасен тем, что начинает подменять canonical на всех страницах.
Если нужно убрать именно этот вывод, а код находится в теме или дочерней теме, удалите его в исходнике. Если это чужой плагин, лучше отключить его фильтр, а не править сам плагин.
Шаг 3. Отключите лишний canonical точечно
Иногда нужно убрать canonical только на конкретном шаблоне или типе записи. Тогда используйте фильтр SEO-плагина, если он есть, или отключите стандартный вывод ядра на выбранной странице. Для ядра WordPress можно убрать стандартный тег так:
add_action('wp', function () {
if (is_page('landing')) {
remove_action('wp_head', 'rel_canonical');
}
});Этот вариант подходит, если вы точно понимаете, что canonical для этой страницы должен формироваться иначе. Не применяйте его глобально без необходимости: на большинстве страниц canonical всё же нужен.
Шаг 4. Проверьте пагинацию, фильтры и параметры URL
Частая причина дублей — страницы с параметрами ?sort=, ?filter=, ?utm_ или пагинацией. В таких случаях canonical должен указывать на чистый основной URL, а не на каждую комбинацию параметров. Если плагин или тема формируют canonical на основе текущей строки запроса, это нужно исправлять отдельно.
Для нестандартных архивов можно задать canonical через фильтр SEO-плагина или через собственную логику, но только если вы уверены, что URL действительно является дублем, а не самостоятельной страницей для индексации.
Сравнение подходов: плагин, код, ручная правка
| Подход | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Если canonical уже управляется плагином и нужен единый источник | Нужно проверить, не добавляет ли его тема вручную |
| Код в теме | Если проект кастомный и логика canonical зависит от шаблона | Легко сломать при обновлении темы без дочерней темы |
| Удаление лишнего вывода | Если дубль идёт от старого сниппета или стороннего плагина | Нужно точно найти источник, иначе можно убрать нужный тег |
Как проверить, что исправление сработало
После правки не ограничивайтесь визуальной проверкой страницы. Нужна проверка в исходнике и в инструментах индексации.
- Откройте страницу в браузере и убедитесь, что в HTML остался один canonical.
- Проверьте, что href указывает на финальный канонический URL без лишних параметров.
- Прогоните URL через инструмент проверки в Google Search Console, если страница уже в индексе.
- Сравните исходный код до и после правки, особенно если canonical генерируется через фильтр.
Если сайт использует кэш, очистите не только страницу, но и объектный кэш, если он есть. Иначе вы можете смотреть на старую версию HTML и решить, что исправление не помогло.
Частые ошибки и как их исправить
Оставили canonical и в теме, и в SEO-плагине
Это самый частый сценарий. Решение простое: оставьте только один источник. Обычно удобнее оставить SEO-плагин, а ручной вывод убрать.
Canonical указывает на главную страницу
Такое часто бывает после копирования кода из чужого проекта. Проверьте, не подставляется ли home_url() вместо текущего permalink. Для записей и страниц canonical должен вести на их собственный URL, если нет специальной причины для другого адреса.
Удалили canonical полностью
Это тоже ошибка. Полное отсутствие canonical на части страниц может ухудшить обработку дублей. Убирать его стоит только точечно и осознанно.
Не учли кэш и CDN
После правки старый HTML может продолжать отдаваться из кэша. Очистите серверный кэш, плагин кэширования и CDN, если он используется.
Практические советы по безопасности и производительности
Не редактируйте файлы плагинов напрямую: при обновлении правка исчезнет, а проблема вернётся. Если нужно вмешаться в логику, используйте дочернюю тему, mu-plugin или собственный мини-плагин.
Если на сайте много кастомных SEO-правок, держите их в одном месте, а не размазывайте по шаблонам. Это упрощает аудит и снижает риск случайно вывести несколько canonical на одной странице.
Для проектов с частыми правками полезно периодически проверять шаблоны на дублирующиеся SEO-теги: canonical, meta robots, Open Graph. Если нужен более системный аудит и чистка дублей, в WPShop есть Clearfy Pro, но использовать его стоит как инструмент контроля, а не как замену понимания, откуда именно берётся тег.
Если хотите, чтобы canonical был стабильным, сначала определите один источник генерации, потом уберите все остальные. В WordPress это почти всегда надёжнее, чем пытаться «подправить» несколько конфликтующих механизмов одновременно.