гора.
запись · 12 мая 2026 г. · 8 мин чтения

Canonical URL: когда нужен, когда вредит

В марте один из проектов, который я веду, начал терять выдачу. Не главная — отдельные карточки продуктов. Страница ловила импрешены два месяца, висела в топ-20 по нескольким ключам, а потом — обвал. За неделю с 300 показов в день до пяти. По одному ключу — вообще выпала из индекса.

Я залез в Google Search Console, прогнал URL Inspection. Google пишет: «User-declared canonical: https://example.com/». То есть моя собственная страница говорит Google: «не индексируй меня, индексируй главную». Открываю DevTools, смотрю <head> — действительно стоит <link rel="canonical" href="https://example.com/">. На всех страницах. Один и тот же canonical, ведущий на корень домена.

Дальше пошёл смотреть, откуда это вылезло. Оказалось — кто-то правил next.config.js, добавил блок с метатегами по умолчанию, прописал туда canonical через process.env.SITE_URL без path. Шаблон применился ко всему сайту. Google послушно склеил всё в одну страницу.

На откат и переиндексацию ушло три недели. Часть позиций я не вернул до сих пор.

Это типичный случай. Canonical — мощный сигнал, и его легко сломать одной строчкой в конфиге. За последние полгода я разгребал такие истории на пяти разных проектах. Везде причины разные — где-то WordPress-плагин, где-то Next.js конфиг, где-то Shopify-тема, где-то правка от программиста, которая «должна была всё унифицировать». А последствия одинаковые: страницы вылетают из индекса, и ты не понимаешь почему, пока не залезешь в исходник.

Дальше — что это такое, когда он реально нужен, и где из помощника он превращается в выстрел в ногу.

Что такое canonical

Canonical — это указание Google, какую версию страницы считать главной, если в индексе их несколько похожих или одинаковых.

Технически он живёт в двух местах. Первое — HTML, в <head>:

<link rel="canonical" href="https://example.com/product/red-shoes">

Второе — HTTP-header, для не-HTML ресурсов (PDF, изображения, документы):

Link: <https://example.com/whitepaper.pdf>; rel="canonical"

Что важно понимать. Canonical — это не редирект. Это не блокировка. Это даже не директива. Это сигнал, подсказка. Google смотрит на canonical и решает, верить ему или нет. В URL Inspection ты увидишь два поля: «User-declared canonical» (что заявил ты) и «Google-selected canonical» (что выбрал Google). Они часто не совпадают.

Google может проигнорировать твой canonical, если:

  • он ведёт на noindex-страницу
  • он ведёт на 404 или 5xx
  • содержимое страниц радикально разное
  • canonical ведёт сам на цепочку других canonical
  • у тебя на одной странице стоит несколько canonical с разными URL

То есть это рекомендация, которую Google взвешивает по совокупности факторов. Но в 90% случаев — слушает. Поэтому и опасно: ты ставишь canonical в надежде «подсказать» Google, а получается, что ты по сути перенаправил весь поисковый трафик. Просто без редиректа и без следа в логах сервера.

Отдельная путаница — canonical против robots.txt против noindex. Это разные инструменты для разных задач. Robots.txt запрещает краулинг (Google вообще не загружает страницу). Noindex разрешает краулинг, но запрещает индексацию. Canonical разрешает и краулинг, и индексацию, но говорит: «в результаты добавь вот эту версию». Путать их — и ты получишь либо страницы, которые Google не видит, либо страницы, которые видит, но не показывает.

Когда canonical нужен

Есть пять сценариев, в которых canonical реально помогает.

Дубли URL с query parameters. Самый частый случай. У тебя интернет-магазин, страница продукта /product/red-shoes. Пользователь фильтрует — URL становится /product/red-shoes?size=42&color=red&utm_source=google. Контент тот же. Без canonical Google может проиндексировать обе версии и поделить ранжирование между ними. С canonical на /product/red-shoes — Google понимает, что это одна страница, и весь вес идёт на основной URL.

Старая HTTP/HTTPS, www/non-www история. Если сайт мигрировал с HTTP на HTTPS или с www на голый домен, и редиректы не везде проставлены — canonical может помочь. Хотя честно: 301-редирект в этом случае всегда лучше. Canonical — это запасной парашют, основной механизм должен быть редиректом на уровне nginx или CDN.

Print-version, AMP, mobile-версии. Если у тебя есть отдельная print-friendly версия страницы — /article?print=1 — она должна canonical'иться на основную. Та же история с AMP-версией: на ней стоит canonical на основной HTML-вариант. Это стандартная практика.

A/B-тесты. Тестируешь два варианта лендинга — /landing-a и /landing-b. Вариант B должен canonical'иться на вариант A (или оба — на нейтральный URL). Иначе ты сам себе создашь дубль, и Google поделит ранжирование между двумя половинками теста.

Sticky filters в списках. Категория с сортировкой: /catalog, /catalog?sort=price, /catalog?sort=date. Контент тот же, порядок разный. Canonical всех вариантов на /catalog — Google ранжирует одну страницу, а не три похожие.

Cross-domain canonical. Это интересный кейс. Если ты опубликовал статью у себя, а потом дал её перепечатать на другой сайт — на копии должен стоять canonical на твой оригинал. Google это уважает. Я видел случаи, когда статья на крупном медиа с canonical на мелкий блог-оригинал — и в выдаче поднимался именно блог. Работает.

Когда canonical вредит

А теперь — пять способов всё сломать. Все эти случаи я ловил руками либо у себя, либо у клиентов.

Canonical на главную со всех страниц. Моя история из начала поста. Это самая частая ошибка, и она убивает сайт полностью. Возникает из-за плохо настроенного next.config.js, шаблона Astro, плагина в WordPress, темы Shopify — везде, где canonical задаётся по умолчанию без учёта текущего URL. Google индексирует только главную. Все остальные страницы — в выдаче не появляются. Проверяется одной командой:

curl -sS https://example.com/some-page | grep canonical

Если в выводе href ведёт на корень — у тебя проблема.

Self-canonical с другим доменом или схемой. Сайт на https://example.com, а canonical стоит http://example.com/page (без s) или https://www.example.com/page (с www, хотя сайт без www). Возникает из-за hardcoded URL в шаблоне или из-за миграции, после которой канон не обновили. Google либо игнорит, либо склеивает с несуществующей версией. Поправить — пять минут, найти — иногда часы.

Canonical на noindex-страницу. Самопротиворечие. Ты говоришь: «вот эта главная версия», и тут же на этой главной — <meta name="robots" content="noindex">. Google в этом случае канон игнорит, но и оригинал может не проиндексировать — потому что ты явно сказал, что не та версия главная. Возникает обычно на staging-средах, которые случайно попали в индекс.

Цепочки canonical. Страница A canonical'ится на B, B canonical'ится на C. Google обрабатывает только первый шаг. То есть A → B он увидит, B → C — нет. В итоге в индексе остаётся B, хотя ты хотел C. Цепочки возникают на сайтах с историей миграций, когда canonical правили несколько раз и не привели в порядок.

Canonical при materially разном контенте. /search?q=seo имеет canonical на /search. Кажется логично — это же одна страница поиска. Но ?q=seo отдаёт результаты по «seo», а /search без параметра — пустая форма. Контент разный, query параметр материально меняет страницу. Google склеит — и ты потеряешь все SERP-позиции по конкретным поисковым запросам. То же касается фильтров каталога, которые сильно меняют выдачу: /laptops?brand=apple — это не дубль /laptops, это отдельная страница, которая может ранжироваться по «macbook».

Главный принцип: canonical нужен там, где контент дублируется. Если контент разный — canonical вреден.

Как проверить canonical

Три способа, по возрастанию точности.

curl. Самый быстрый. На любой странице:

curl -sS https://example.com/page | grep -i canonical

Должен вернуть строку <link rel="canonical" href="...">. Если href совпадает с URL запроса (с учётом схемы, www, trailing slash) — self-canonical, всё ок. Если ведёт куда-то ещё — разбирайся, это намеренно или баг.

DevTools. Открываешь страницу, F12, вкладка Elements, Ctrl+F, ищешь «canonical». Видишь, что отрендерил браузер. Это важно: иногда canonical вставляется JavaScript'ом, и в curl его не видно — а в DOM есть. Особенно на SPA вроде React/Next с client-side rendering.

Google Search Console → URL Inspection. Самый честный способ. Вбиваешь URL — Google показывает два поля:

  • User-declared canonical — что у тебя стоит в HTML
  • Google-selected canonical — что Google реально считает главной

Они должны совпадать. Если не совпадают — Google проигнорировал твой канон и выбрал что-то другое. Это сигнал: либо твой canonical явно сломан, либо контент похож на другую страницу и Google решил их объединить. И вот «Google-selected» — это то, что реально влияет на индексацию и ранжирование, а не то, что ты заявил.

Проверять — раз в месяц на ключевых страницах. На крупных каталогах — выборочно, через GSC API сразу по тысячам URL.

Самоканонические страницы

Best practice, который я ставлю на каждом проекте. Каждая уникальная страница ставит canonical на саму себя — полным абсолютным URL.

<!-- На странице /article/seo-tips -->
<link rel="canonical" href="https://example.com/article/seo-tips">

Зачем это нужно, если страница и так уникальная? Затем, что она может оказаться доступна через варианты URL, о которых ты не знаешь:

  • ?utm_source=... — рекламные параметры
  • ?fbclid=... — Facebook click ID
  • #section — якорь
  • /article/seo-tips/ — trailing slash
  • /Article/Seo-Tips — разный регистр

Без self-canonical Google может проиндексировать любую из этих версий как отдельную. С self-canonical — всё схлопывается на одну, ту, что ты прописал. Это страховка от случайностей.

Реализуется обычно в шаблоне Next.js / WordPress / любого CMS — функцией, которая берёт request.url, нормализует (убирает query, нормализует case, ставит trailing slash как у тебя принято) и подставляет в <link rel="canonical">. Один раз настроил — работает на всех страницах.

В Next.js это делается через metadata.alternates.canonical в layout.tsx или на уровне страницы:

export const metadata = {
  alternates: {
    canonical: 'https://example.com/article/seo-tips',
  },
}

Важно: URL абсолютный, со схемой и доменом. Относительные canonical (/article/seo-tips) формально валидны, но я видел случаи, когда Google интерпретировал их странно — особенно если страница доступна через несколько хостов (apex и www). Лучше всегда писать полный URL.

Итог

Canonical — это сигнал Google: «когда увидишь похожие страницы, индексируй вот эту». Полезен для query-параметров, фильтров, A/B-тестов, перепечаток. Вреден, когда ставится массово на главную, на noindex, на http при https-сайте, или когда query-параметры материально меняют контент.

Правило простое. Если контент дублируется — canonical нужен. Если контент уникальный — self-canonical. Если контент разный — canonical не нужен вообще, пусть будет своя страница со своим URL.

Проверяй через GSC URL Inspection. «Google-selected canonical» — единственная цифра, которая реально влияет на выдачу. Всё остальное — твои намерения.

См. также: 30+ факторов SEO 2026, что блокировать в robots.txt, hreflang: subdomain или subdirectory.

Canonical URL: когда нужен, когда вредит · hiregora.com