Что такое canonical и зачем он нужен
rel=canonical - это способ подсказать поисковику, какой URL считать основной (канонической) версией, если у страницы есть дубли или почти одинаковые варианты.
Важно: canonical - это подсказка, а не жесткая команда. Поисковик может не принять вашу версию, если видит противоречия (например, canonical указывает на URL, который закрыт от индексации или отдает не 200 OK).
Canonical помогает:
- не размазывать сигналы по дублям (ссылки, релевантность, поведенческие)
- уменьшать мусор в индексе (параметры, UTM, сортировки, технические версии)
- стабилизировать выдачу, когда один и тот же контент доступен по разным адресам
Как выглядит canonical и где его задают
Чаще всего canonical задают в HTML в <head>:
<link rel="canonical" href="https://site.ru/kategoriya/tovar/" />
Базовые правила:
- на странице должен быть ровно один canonical
- canonical должен быть абсолютным URL (с протоколом и доменом)
- canonical должен указывать на финальную версию URL (правильный https/http, www/без www, со слешем или без - как принято на сайте)
- на канонической странице обычно ставят self-canonical (то есть canonical на саму себя)
Иногда canonical задают в HTTP-заголовке Link (чаще для файлов или нестандартных сценариев), но в большинстве проектов достаточно тега в HTML.
Сервисы для SEO-аудита онлайн
Главное правило: canonical работает только в согласованной системе сигналов
Поисковики сравнивают canonical с другими сигналами и ждут логики. Если сигналы конфликтуют, canonical часто игнорируется.
Быстрая проверка “системы сигналов”:
- каноническая страница отдает
200 OK - она доступна роботу (не закрыта от обхода в robots.txt)
- она индексируемая (нет
noindexв meta robots, нетX-Robots-Tag: noindex) - внутренние ссылки ведут на канонические URL, а не на дубли
- в
sitemap.xmlлежат канонические URL, а не параметрические версии - редиректы и canonical не спорят друг с другом (если есть редирект, canonical должен смотреть на финальную страницу)
Когда canonical уместен, а когда лучше другое решение
| Ситуация | Что делать | Почему |
|---|---|---|
| Дубли из-за UTM и рекламных параметров | Canonical на “чистый” URL без параметров | Параметры нужны аналитике, но не нужны в индексе |
Сортировки (?sort=price) | Чаще всего canonical на базовую категорию без сортировки | Сортировка редко дает уникальную ценность для поиска |
Фильтры (?color=black&size=m) | Зависит от стратегии: либо отдельные индексируемые посадочные, либо закрытие от индексации и canonical на базовую | Фильтры могут быть точками роста, а могут быть мусором |
| Варианты товара (цвет, размер) | Canonical на основную карточку, если варианты не должны ранжироваться отдельно | Склеиваем сигналы в одну страницу товара |
| Реально разные страницы (разный интент, другой контент) | Не “склеивать” canonical, решать архитектурой, редиректами или контентом | Canonical не лечит неправильную структуру и может убить нужную страницу |
| Переезд URL навсегда | Делать 301-редирект, а не canonical | Редирект надежнее и быстрее консолидирует сигналы |
Типовые ловушки canonical
Ловушка 1. Canonical на страницу, которая не индексируется
Самый частые ошибки:
- canonical указывает на URL с
noindex - canonical указывает на URL, который закрыт от обхода в robots.txt
- canonical указывает на URL, который отдает
404/410или уходит в редирект (или в цепочку редиректов)
Что бывает в итоге:
- в индексе остается дубль
- поисковик выбирает другой canonical сам
- страница “гуляет” по статусам и может временно просесть по видимости
Ловушка 2. Несовпадение сигналов (sitemap, внутренние ссылки, canonical)
Если сайт сам “голосует” за дубли, поисковику сложнее поверить canonical.
Пример логики конфликта:
- в
sitemap.xmlлежат URL с параметрами - внутренняя перелинковка ведет на параметрические версии
- canonical при этом указывает на “чистые” URL
В таких случаях сначала выравнивают внутренние ссылки и sitemap, и только затем canonical начинает работать заметно стабильнее.
Ловушка 3. Цепочки canonical
Плохо, когда canonical ведет не на финальную страницу:
- страница A указывает canonical на B
- страница B указывает canonical на C
Лучше, чтобы все дубли указывали сразу на финальный канонический URL. Цепочки повышают шанс, что поисковик выберет по-своему.
Ловушка 4. Canonical на первую страницу категории для пагинации “по умолчанию”
Вокруг пагинации нет единственного “правильного” решения - это стратегия, которая зависит от целей проекта (обход, индекс, выдача) и от того, насколько хорошо товары/материалы доступны по другим путям.
Стратегия 1 (часто практикуют): canonical со страниц 2+ на страницу 1.
Её выбирают, когда важно, чтобы в выдаче по общим запросам показывалась основная страница категории, а не /page/2, /page/3. Это может работать как сигнал “главная версия листинга здесь”.
Риски и что держать в голове:
- canonical - подсказка, а не запрет: поисковик может всё равно показывать
/page/2, если сочтёт её более релевантной конкретному запросу - если перелинковка до “глубоких” товаров слабая, чрезмерная “склейка” пагинации может ухудшить доступность дальних позиций для робота
Стратегия 2: canonical со страниц 2+ на страницу 1 + noindex для страниц 2+ (если canonical не помогает).
Подходит, когда вы принципиально не хотите видеть пагинацию в индексе и в выдаче. Использовать аккуратно: убедитесь, что товары/материалы хорошо находятся и переобходятся без участия страниц пагинации (через категории, фильтры/посадочные, хабы, sitemap, внутренние ссылки на карточки).
Стратегия 3 (тоже допустима): не “склеивать” пагинацию и не закрывать её.
В этом подходе:
- на каждой странице пагинации стоит self-canonical (страница 2 указывает canonical на страницу 2)
- задача “чтобы в выдаче чаще была страница 1” решается усилением страницы 1 (внутренние ссылки, корректные Title/H1 под основной интент), а страницы 2+ получают явный признак “страница 2/3…” в Title, чтобы реже конкурировать по общим запросам
Отдельный сценарий: если есть страница “показать все” (view-all) и она реально быстрая, полноценная и доступная роботу, иногда canonical ведут на неё. Но это рискованный путь: view-all легко становится тяжелой и начинает мешать обходу.
Ловушка 5. Canonical как попытка “закрыть от индексации”
Canonical не заменяет noindex. Он не запрещает индексацию напрямую, он предлагает основную версию.
Если задача - убрать URL из выдачи, обычно используют:
noindex(meta robots или X-Robots-Tag), если страница должна быть доступна роботу, но не должна индексироваться- 301, если есть замена и перенос навсегда
- 410, если страницу нужно удалить без замены
Ловушка 6. Cross-domain canonical без реальной необходимости
Canonical может указывать на другой домен (например, при синдикации контента), но это рискованный инструмент:
- ошибка в настройке может “увести” страницы из индекса на чужой домен
- поисковик может игнорировать такой canonical при несоответствии сигналов
Используйте только когда понимаете, зачем это делается и кто управляет доменом, который указан как канонический.
Практичные кейсы
Кейс 1. UTM-метки попадают в индекс
Симптомы:
- в поиске и в отчетах появляются URL вида
?utm_source=... - растет число дублей и “похожих страниц”
Типовой подход:
- оставляем UTM для аналитики
- ставим canonical на чистый URL без UTM
- проверяем, что внутренние ссылки ведут на чистые URL (а не на размеченные)
Кейс 2. Сортировка в категориях плодит десятки дублей
Симптомы:
- индексируются варианты
?sort=price,?sort=popular,?sort=new - страницы отличаются только порядком товаров
Типовой подход:
- canonical на базовую категорию без сортировки
- по возможности не создавать внутренние ссылки, которые делают сортировки точками входа для робота
- сортировки остаются для пользователя, но не становятся “отдельными страницами для поиска”
Кейс 3. Фильтры в e-com: где рост, а где мусор
Симптомы:
- фильтры создают тысячи комбинаций URL
- часть комбинаций имеет спрос, а часть просто засоряет индекс
Рабочая логика стратегии:
- выделяем небольшое число комбинаций, которые должны ранжироваться (делаем посадочные под кластеры и ведем на них структуру)
- остальное не индексируем и не даем этому конкурировать с посадочными (настройка правил индексации и canonical должна поддерживать эту стратегию)
Ключевая мысль: canonical должен поддерживать семантику и структуру, а не пытаться заменить их.
Кейс 4. Варианты товара (цвет, размер) создают дубли карточек
Симптомы:
- у товара появляются URL вариантов, например через параметры
- варианты не несут отдельного интента, но “распыляют” сигналы
Типовой подход:
- canonical на основной URL карточки
- основной URL должен быть индексируемым и указанным в sitemap
- во внутренних ссылках основным должен быть базовый URL, а не вариант
Мини-чеклист: как быстро проверить canonical
-
Найдите canonical в исходном коде страницы (обычно это
<link rel="canonical" ...>), а если в HTML его нет - проверьте, не отдаётся ли canonical, только для поисковых ботов (по User-Agent). -
Проверьте, что canonical:
- один
- абсолютный
- ведет на страницу с
200 OK
- Проверьте конфликты сигналов:
- на канонической странице нет
noindex - каноническая страница не запрещена в robots.txt
- в sitemap и внутренних ссылках преобладает каноническая версия URL
- Если используете инструменты вебмастера, смотрите расхождение между:
- canonical, который вы указали
- canonical, который поисковик выбрал фактически
Если поисковик выбрал другой canonical, почти всегда причина в конфликте сигналов или в том, что “каноническая” страница для него выглядит слабее, чем дубль.