Если в индексе появляются дубли страниц, а в Search Console всплывают странные URL с параметрами, часто проблема не в контенте, а в rel="canonical". На практике конфликт canonical в WordPress возникает не только из-за SEO-плагина: его могут подменять тема, фильтры, page builder, мультиязычность или кастомный код. ИИ здесь полезен не как «магия исправления», а как быстрый разбор большого числа шаблонов и поиск места, где canonical начинает расходиться с реальным каноническим URL.
Когда стоит подозревать конфликт canonical
Симптомы обычно заметны не в коде, а в поведении индексации. Одна и та же страница может попадать в отчет как несколько URL, а в HTML-исходнике canonical указывает не на ту версию, которую вы считаете основной. Иногда проблема проявляется только на архивных страницах, пагинации, страницах с UTM-параметрами или в записях, которые выводятся через шаблонный файл с собственными фильтрами.
Типичные признаки:
- в Search Console у одной страницы несколько вариантов URL;
- canonical указывает на главную, категорию или другую запись;
- в исходнике страницы есть два тега canonical;
- canonical меняется в зависимости от языка, параметра или типа устройства;
- SEO-плагин показывает одно значение, а в HTML — другое.
Что именно проверять в первую очередь
Не начинайте с правки кода. Сначала нужно понять, кто именно выводит canonical. В WordPress это может быть:
- SEO-плагин, который подключает свой тег через
wp_head; - тема, где canonical добавлен вручную в
header.php; - плагин кэширования или оптимизации, который не должен трогать canonical, но вмешивается в HTML;
- кастомный фильтр
rel_canonicalилиwpseo_canonical; - шаблон архива, где canonical собирается на основе неправильного объекта.
Диагностика проблемы с помощью ИИ
Самый рабочий сценарий — собрать несколько примеров страниц, где canonical ведет себя неправильно, и отдать их ИИ вместе с фрагментами исходника. Не просите «починить SEO». Просите сравнить шаблоны и найти источник расхождения. ИИ хорошо справляется с повторяющимися паттернами: одинаковый тег из двух мест, неправильный фильтр, лишний вывод в дочерней теме.
Какие данные собрать
Для диагностики достаточно трех вещей: URL проблемной страницы, фрагмент HTML из <head> и список активных SEO/кэш-плагинов. Если есть доступ к коду, добавьте файл темы, где формируется head, и любые фильтры, связанные с canonical. Чем меньше лишнего, тем точнее вывод.
Пример запроса к ИИ:
У меня в WordPress на странице https://site.ru/article/ canonical в исходнике указывает на https://site.ru/, а SEO-плагин в настройках показывает правильный URL.
Вот фрагмент head:
<link rel="canonical" href="https://site.ru/" />
<link rel="canonical" href="https://site.ru/article/" />
Активные плагины: Yoast SEO, WP Rocket, Polylang.
Найди вероятный источник конфликта canonical и предложи порядок проверки: плагин, тема, фильтры, кэш.Если вы работаете с несколькими страницами, полезно дать ИИ таблицу с URL и фактическим canonical. Тогда он быстрее увидит закономерность: проблема только на записях, только в категории, только на страницах с параметрами или только в одном языке.
Пошаговое решение: как убрать конфликт canonical
Правильный порядок — сначала найти источник, потом отключить дублирующий вывод, и только после этого править логику. Если сразу удалить тег из шаблона, можно сломать страницы, где canonical нужен для нормальной индексации.
Шаг 1. Найдите все места, где canonical может выводиться
Поиск по проекту должен охватывать не только тему, но и mu-plugins, дочернюю тему и кастомные плагины. Ищите строки canonical, rel_canonical, wp_head, а также фильтры SEO-плагинов.
grep -Rni "rel_canonical\|canonical\|wp_head\|wpseo_canonical" wp-content/themes wp-content/plugins wp-content/mu-pluginsЕсли у вас нет SSH, используйте поиск по файлам в IDE. Важно не ограничиваться только header.php: canonical часто добавляют в functions.php или в отдельный файл подключаемого модуля.
Шаг 2. Сравните вывод темы и SEO-плагина
У WordPress есть встроенный вывод canonical через rel_canonical, но SEO-плагины обычно заменяют его своим. Если тема тоже печатает тег вручную, вы получите дубль. В таком случае нужно оставить только один источник.
Если canonical добавлен в теме вручную, его можно убрать из header.php или отключить через фильтр, если код уже разнесен по нескольким файлам. Пример безопасного отключения встроенного вывода WordPress для конкретного шаблона:
add_action('wp', function () {
if (is_singular('post')) {
remove_action('wp_head', 'rel_canonical');
}
});Этот пример не решает все случаи, но показывает принцип: сначала убираем лишний источник, потом проверяем, кто должен остаться основным.
Шаг 3. Исправьте фильтр, если canonical собирается программно
Если canonical меняется через фильтр, проверьте, не подставляется ли туда URL из home_url(), site_url() или текущего запроса без учета языка, пагинации и параметров. Частая ошибка — брать URL из $_SERVER['REQUEST_URI'] и не отрезать query string.
Пример более аккуратной логики для кастомного canonical:
add_filter('rel_canonical', function ($canonical) {
if (is_singular()) {
return get_permalink();
}
if (is_category() || is_tag() || is_tax()) {
$term = get_queried_object();
if (!empty($term->term_id)) {
return get_term_link($term);
}
}
return $canonical;
});Если у вас уже работает SEO-плагин, не дублируйте эту логику без необходимости. Такой код нужен только тогда, когда вы точно понимаете, кто должен быть источником canonical и почему стандартный вывод не подходит.
Шаг 4. Проверьте конфликт с кэшем и минификацией
Иногда canonical выглядит сломанным только в кэшированной версии страницы. Это бывает после ручной правки шаблона, когда старый HTML продолжает отдаваться из кэша. Очистите кэш страницы, объектный кэш и CDN, если он есть. После этого проверьте исходник без авторизации и в режиме инкогнито.
| Подход | Когда уместен | Минус |
|---|---|---|
| Исправить в SEO-плагине | Если canonical задается настройкой или шаблоном плагина | Нужно знать, какой плагин реально выводит тег |
| Исправить в теме | Если тег добавлен вручную в шаблоне | Легко забыть о дочерней теме или include-файле |
| Исправить кодом через фильтр | Если нужна точечная логика для отдельных типов страниц | Можно случайно перекрыть поведение SEO-плагина |
Как использовать ИИ для проверки паттернов, а не только одной страницы
Одна страница может быть случайностью. ИИ полезнее, когда вы даете ему несколько примеров и просите найти общий источник. Например, canonical ломается только на страницах с пагинацией, только в категориях с подкатегориями или только у записей определенного типа. В этом случае ИИ помогает не «чинить руками», а сузить область поиска до конкретного шаблона или фильтра.
Хороший запрос выглядит так:
Сравни эти 5 URL и их canonical. Найди общий шаблон, при котором canonical уходит на главную или на URL без параметров языка.
1) ...
2) ...
3) ...
Вот список активных плагинов и фрагмент functions.php.
Скажи, где вероятнее всего ошибка: тема, SEO-плагин, фильтр или кэш.Проверка результата после внедрения
После правки не ограничивайтесь просмотром страницы в браузере. Нужно проверить именно HTML-исходник и поведение индексации. В идеале canonical должен быть один, он должен совпадать с предпочтительным URL, и он не должен меняться между обновлениями страницы.
- откройте страницу в режиме инкогнито и проверьте исходный код;
- убедитесь, что в
<head>только одинlink rel="canonical"; - проверьте несколько типов страниц: запись, категория, архив, страница с параметром;
- если есть мультиязычность, сравните canonical на каждом языке;
- после очистки кэша повторите проверку еще раз.
Если есть доступ к Search Console, следите не за мгновенным результатом, а за тем, как Google переобходит страницы. Canonical — это сигнал, а не жесткая команда, поэтому изменения могут не отразиться сразу.
Частые ошибки и как их исправить
Самая частая ошибка — удалить canonical совсем. Это хуже, чем конфликт: поисковик теряет подсказку о предпочтительной версии страницы. Вторая ошибка — оставить canonical только на части шаблонов, например на записях, но забыть про архивы и пагинацию.
Ошибка: два canonical в исходнике
Причина почти всегда одна из двух: тема печатает тег вручную, а SEO-плагин делает то же самое; либо подключены два SEO-решения одновременно. Исправление простое: оставьте один источник и проверьте, что второй отключен не только в настройках, но и в коде.
Ошибка: canonical ведет на URL с параметрами
Такое бывает, если canonical собирается из текущего запроса без очистки query string. Нужно формировать URL из постоянного объекта — записи, термина или страницы — а не из адресной строки браузера.
Ошибка: canonical меняется после очистки кэша
Это признак того, что часть логики живет в кэшируемом фрагменте или в динамическом блоке. Проверьте, не вставляет ли тег отдельный плагин оптимизации, и убедитесь, что HTML не собирается из устаревшего шаблона.
Ошибка: ИИ предлагает удалить все фильтры
Такой совет обычно слишком грубый. Сначала нужно локализовать источник, а затем убрать только конфликтующий участок. Иначе вы легко сломаете canonical на страницах, где он работает корректно.
Безопасность и производительность
Если вы правите canonical через код, делайте это в дочерней теме или в небольшом кастомном плагине, а не в ядре темы. Так проще откатить изменения и не потерять их после обновления. Перед правкой сохраните резервную копию файла и проверьте изменения на staging, если он есть.
Для ускорения аудита можно использовать ИИ вместе с поиском по проекту и выгрузкой HTML нескольких страниц. Но не передавайте в модель лишние секреты: токены, доступы, приватные URL админки. Для анализа canonical достаточно исходника, списка плагинов и фрагментов кода.
Если вам нужен более широкий аудит технических дублей и мусорных SEO-элементов, удобнее сначала привести в порядок шаблоны и мета-вывод, а уже потом проверять отдельные сигналы. В некоторых проектах для этого используют Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с таким инструментом canonical лучше проверять вручную, потому что конфликт часто сидит в кастомном коде, а не в стандартных настройках.
Короткий чек-лист перед публикацией правки
- найдено все место, где выводится canonical;
- оставлен только один источник тега;
- canonical совпадает с предпочтительным URL без параметров;
- проверены запись, категория, архив и страница с параметром;
- очищен кэш сайта и CDN;
- исходник проверен в инкогнито;
- в Search Console отслеживается переобход страниц.
Если после всех проверок canonical все еще расходится, значит проблема не в одном теге, а в логике формирования URL. Тогда ИИ полезно кормить уже не только HTML, но и конкретным куском темы или фильтра, который собирает адрес. Это быстрее, чем искать вслепую по всему проекту.