Canonical: 5 ошибок которые ломают SEO больших сайтов

Тег <link rel="canonical"> — на первый взгляд один из самых простых SEO-инструментов: указываешь поисковику, какая страница «настоящая», и он не плодит дубли в индексе. На практике именно с ним связаны самые болезненные индексационные катастрофы. На крупных сайтах (e-commerce, агрегаторы, новостные порталы) одна неправильная canonical-настройка может выбросить из индекса 60% страниц за неделю.

В этой статье — пять самых частых ошибок canonical, реальные сценарии когда они возникают, и способы их выявить.

Что canonical делает на самом деле

Сначала база — но коротко, потому что главное впереди.

<link rel="canonical" href="..." /> в <head> страницы говорит поисковикам: «эта страница — копия страницы по указанному URL. В индексе храните оригинал, мне ваши усилия отдавайте оригиналу». Это сильная рекомендация, не директива — поисковики могут её проигнорировать, если уверены, что вы ошибаетесь, но в 95% случаев следуют указанию.

Цели:

Объединить «вес» дубликатов на одну страницу (не дробить ссылочный профиль)
Не показывать в выдаче несколько похожих страниц по одному запросу
Контролировать какой именно URL индексируется (с www или без, с / на конце или без, с UTM или без)

Ошибка 1: Самоссылка на главную с каждой страницы

Самый распространённый «спецэффект» некачественной разработки. Шаблон главной страницы содержит <link rel="canonical" href="/" />, и этот же шаблон используется на всех остальных страницах сайта.

Что происходит: Каждая страница сайта говорит поисковику «я — дубликат главной». Поисковик старается доверять — и постепенно деиндексирует всё кроме главной.

Симптомы:

Резкое падение количества проиндексированных страниц в Google Search Console и Я.Вебмастере
Внутренние страницы выпадают из выдачи по своим запросам
Главная начинает «перетягивать» весь трафик, но не справляется с разной семантикой

Как выявить: В Search Console → отчёт «Покрытие» → «Страница исключена из-за выбранного канонического URL». Если там сотни-тысячи строк с одинаковым canonical на главную — это оно.

Как фиксить: Шаблон должен генерировать canonical динамически: <link rel="canonical" href="${currentURL}" /> для каждой страницы. В Next.js это alternates: { canonical: '/some-path/' } в metadata, в WordPress — стандартное поведение Yoast/RankMath.

Ошибка 2: Canonical-цепочки

Страница А указывает canonical на страницу Б. Страница Б указывает canonical на страницу В. Страница В указывает canonical на страницу Г. Это цепочка из трёх редиректов canonical.

Что происходит: Поисковики обычно следуют по цепочке до 3-х шагов, потом сдаются и считают, что-то сломано. Часто в результате сигналы вообще не доходят до финальной страницы.

Откуда берётся: Обычно — миграции структуры сайта. Когда несколько раз меняли URL, и каждая редакция оставила свой canonical. Или CMS, генерирующая canonical на основе устаревших правил.

Как выявить: Screaming Frog → отчёт Canonical Chains. Или вручную: crawl скриптом всех страниц, парсинг canonical, поиск цепочек длиннее 1 шага.

Как фиксить: Все canonical должны указывать сразу на финальный URL, без посредников. Если страница А = страница Г, то в А пишем <link rel="canonical" href="URL Г" />, не пытаемся идти через Б и В.

Ошибка 3: Canonical на страницу, которая возвращает 404 или редирект

Страница работает. Canonical на ней — указывает на URL, которого больше не существует или который редиректит.

Что происходит: Поисковик пытается перейти по canonical и получает 404 или 30x. В лучшем случае — игнорирует canonical и индексирует текущую страницу. В худшем — деиндексирует текущую страницу (потому что её canonical-цель недоступна) и не индексирует целевую (потому что она недоступна).

Откуда берётся: Чаще всего — удалили страницу из каталога, забыв пройтись по всем дублирующим вариантам с canonical на удалённую.

Как выявить: Crawl всех страниц + проверка HTTP-статуса всех canonical-целей. Любая canonical, ведущая на не-200 — потенциальная проблема.

Как фиксить: Либо вернуть целевую страницу, либо обновить canonical на актуальный live-URL.

Ошибка 4: Конфликт canonical и noindex

Страница имеет <meta name="robots" content="noindex"> и одновременно <link rel="canonical" href="/other-page/" />.

Что происходит: Это противоречивый сигнал. С одной стороны вы говорите «не индексировать», с другой — «индексировать /other-page/ вместо этой». Google и Яндекс это решают по-разному, и часто в результате noindex побеждает, но canonical-сигнал на /other-page/ при этом теряется.

Откуда берётся: Сочетание разных систем настроек. Например, canonical настроен в шаблоне, а noindex выставлен через CMS-плагин для специфических типов страниц (фильтры, страницы пагинации, теги).

Как выявить: Crawl-инструмент с одновременным сбором canonical и meta robots. Любая страница с обоими сигналами одновременно — потенциальная проблема.

Как фиксить: Если страница должна быть скрыта от индекса — оставить только noindex, убрать canonical (он становится бессмысленным). Если страница должна объединяться с другой — убрать noindex, оставить canonical. Не использовать оба одновременно.

Ошибка 5: Canonical, ломающий пагинацию

Сайт с большим каталогом или блогом имеет пагинацию: /blog/, /blog/page/2/, /blog/page/3/. На каждой странице пагинации стоит canonical на первую страницу: <link rel="canonical" href="/blog/" />.

Что происходит: Раньше (до 2019 года) Google рекомендовал использовать rel="next" и rel="prev" для пагинации. Потом отменил эту рекомендацию. И многие SEO-специалисты «на всякий случай» прописали canonical с пагинации на первую страницу, считая что это безопасно.

На практике это приводит к деиндексации страниц пагинации и всего что находится только на дальних страницах — потому что Google теперь думает что все они дубликаты первой. Если у вас 200 статей с пагинацией по 10 — статьи со 11-й по 200-ю могут потерять видимость.

Как выявить: Search Console → проверка проиндексированности 5-й, 10-й, 20-й страницы пагинации. Если они исключены с маркером «выбран другой канонический URL» — есть проблема.

Как фиксить: Каждая страница пагинации должна иметь self-canonical, то есть canonical на саму себя:

/blog/ → <link rel="canonical" href="https://site.com/blog/" />
/blog/page/2/ → <link rel="canonical" href="https://site.com/blog/page/2/" />
/blog/page/3/ → <link rel="canonical" href="https://site.com/blog/page/3/" />

Pas. Поисковик сам разберётся в структуре.

Бонус: типичные мелкие ошибки

В дополнение к пяти «крупным» — небольшие, но частые проблемы:

Canonical с относительным URL: <link rel="canonical" href="/page/" /> вместо <link rel="canonical" href="https://site.com/page/" />. Технически работает, но рекомендуется использовать абсолютный URL — меньше шансов недопонимания.

Canonical с протоколом, отличным от текущего: Страница доступна по https, но canonical указывает на http-версию. Создаёт лишний редирект-цикл для поисковика.

Canonical на разные домены без явной необходимости: Если страница на site1.com указывает canonical на site2.com, у поисковика возникают вопросы. Это используется для cross-domain canonical, но требует чёткого технического обоснования.

Canonical с UTM-параметрами: Никогда не включайте ?utm_source=... в canonical. Это значит «индексируйте версию с UTM-параметрами», что приводит к индексации тысяч дублей.

Динамический canonical, зависящий от пользователя: Если canonical меняется в зависимости от состояния куки или сессии — это поломка. Canonical должен быть стабилен и однозначен для каждого URL.

Инструменты для аудита

Для регулярной проверки canonical на сайте:

Screaming Frog SEO Spider (десктоп, $200/год) — мощный crawler с детальным анализом canonical, цепочек, конфликтов
Sitebulb (десктоп, $150/мес) — визуальные диаграммы canonical-структуры
Ahrefs Site Audit (онлайн, $99+/мес) — облачный crawl + интеграция с другими данными
Бесплатный crawl своими силами — Python + Beautiful Soup + список URL из sitemap, ~100 строк кода

Регулярность аудита — раз в квартал для стабильных сайтов, раз в месяц для активно меняющихся.

Резюме

Canonical — это инструмент с большим эффектом и большой ценой ошибки. На небольшом сайте (до 100 страниц) проблемы видны быстро и фиксятся легко. На крупном сайте (10 000+ страниц) одна ошибка в шаблоне может месяцами сидеть незамеченной, потихоньку убивая индексацию.

Если вы не помните когда последний раз делали полный canonical-аудит вашего сайта — это, наверное, пора. Можем сделать сами — напишите нам, вернёмся с отчётом за 2 рабочих дня.