Страница с тегом canonical

Почему дублирование контента — реальная проблема для SEO

Дублирование контента на сайте создаёт серьёзные последствия для поисковой видимости. Когда на одном ресурсе находится несколько версий одной страницы с идентичным или почти одинаковым содержимым, поисковые системы вроде Google и Яндекс встают перед выбором: какую версию считать основной, а какую исключить из ранжирования.

Главная проблема — распределение SEO-веса. Все внешние ссылки, которые указывали на разные версии одной страницы, делят авторитет между собой. Если на товар есть пять ссылок на версию с параметром ?category=shirts и пять ссылок на версию с параметром ?category=new, поисковик распределяет авторитет 50 на 50. При одинаковом контенте весь этот вес мог бы работать на один адрес, но вместо этого раскидывается по разным URL.

Результат: Google выбирает одну версию для показа в выдаче, часто не ту, которую вы хотели. Основной адрес товара может остаться невидимым в результатах поиска, а в выдаче появится версия с некрасивыми параметрами. Трафик теряется, позиции по нужным запросам падают.

Где и как возникают дубли

Дубли страниц на сайте создаются разными способами. Для интернет-магазина это — почти неизбежность архитектуры.

Один товар существует в нескольких категориях. Красная рубашка может быть доступна по адресам: — example.com/catalog/mens-clothes/shirts/red-shirt — example.com/catalog/new-arrivals/red-shirt — example.com/catalog/sale/red-shirt

Описание товара, его характеристики и цена остаются одинаковыми, но URL разные. Каждому адресу соответствует отдельная страница, которую должен индексировать робот поисковой системы.

Параметры фильтров и сортировки усугубляют ситуацию. Когда покупатель применяет фильтр — ?color=red&size=m&price=50-100 — генерируется новый URL. На странице может быть один и тот же товар, только отфильтрованный, но для Google это совершенно отдельная страница. Каждой комбинации параметров соответствует уникальный адрес.

Блог создаёт дубли через пагинацию. На странице категории технологических статей: — example.com/blog/tech/?page=1 — example.com/blog/tech/?page=2 — example.com/blog/tech/?page=3

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

Архивные страницы также дублируют контент. Одна статья может быть доступна несколькими путями: — По ID: /blog/post/12345 — В архиве месяца: /archive/2024/01/post-title — В архиве категории: /news/post-title — На главной в блоке новостей (как отдельная страница)

Мобильные версии раньше часто размещались на отдельных поддоменах (m.example.com), создавая полное дублирование контента с основным сайтом на www.example.com. Хотя адаптивный дизайн решил эту проблему для новых проектов, старые системы по-прежнему могут иметь отдельные версии для разных устройств.

Технические параметры добавляют ещё дублей. Сессионные ID, параметры отслеживания аналитики, значения для реклам — всё это генерирует новые адреса одной и той же страницы содержимого.

Как поисковые системы обрабатывают дублирующиеся версии

Когда робот Google сканирует сайт и обнаруживает несколько версий одной страницы, запускается процесс автоматической консолидации.

Поисковый робот проходит по всем ссылкам сайта и индексирует каждую найденную страницу. Если обнаруживаются дубли, алгоритм анализирует несколько сигналов, чтобы определить основную версию:

Количество внешних ссылок на каждый URL — версия с большим числом ссылок часто считается более авторитетной. Возраст страницы в индексе — какая из версий была добавлена раньше. Качество внутренних ссылок с сайта — какая версия чаще упоминается внутри. История в индексе Google — как долго каждая версия уже индексируется. Явное указание канонического адреса через rel canonical тег.

После анализа этих факторов Google выбирает одну версию страницы как основную для ранжирования. Остальные версии остаются в индексе (робот их видит, индекс их хранит), но они не появляются в выдаче поиска и не получают основной трафик. Весь SEO-вес внешних ссылок консолидируется на выбранный адрес.

Проблема в том, что Google часто выбирает совсем не то, что вам нужно. Вы хотите, чтобы основной был чистый URL example.com/product/shirt, а Google может счесть основной версию example.com/product/shirt?color=red&sort=price, если на неё указано больше ссылок или если её история в индексе дольше.

Яндекс работает по похожему принципу, но с важными отличиями. Поисковая система Яндекса более строга к дублям контента. Если на сайте обнаружено много версий одной страницы без явного указания, какую считать канонической:

• Яндекс может снизить общее доверие к сайту
• Переиндексация может потребовать больше времени
• Неправильные версии возникнут в выдаче
• SEO-вес распределится менее благоприятно для вас

Именно поэтому для сайтов, ориентированных на аудиторию России, правильно указывать каноническую ссылку особенно важно.

Неканонические версии не удаляются из индекса. Google и Яндекс продолжают их хранить, потому что пользователи могут на них попасть по внешним ссылкам. Но в выдаче они показываются редко или не показываются совсем. Весь переходящий SEO-вес работает в пользу основного адреса.

Как работает rel canonical: механика консолидации

Rel canonical — это HTML-атрибут, который явно указывает поисковым системам, какой адрес считать основной версией страницы. Это решение проблемы дублирования контента, которое вы полностью контролируете.

На каждой неканонической странице в разделе head размещается тег link с атрибутом rel:

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

Атрибут rel всегда равен строке «canonical». Атрибут href содержит полный адрес той страницы, которую вы указываете как основную.

Когда поисковый робот сканирует эту неканоническую страницу, он ищет в разделе head этот тег. Находит его, читает значение href и сразу же понимает: основная версия этой страницы находится по указанному адресу. Все ссылки, которые указывают на текущую неканоническую версию, должны рассчитываться как ссылки на адрес в href.

Google затем консолидирует весь SEO-вес со всех версий на каноническую ссылку. Если было пять внешних ссылок на параметризованную версию, они начинают работать на основной адрес из href. Это не редирект — пользователь по-прежнему видит в браузере тот URL, на который он зашёл. Это указание только для поисковиков.

Важное уточнение: rel canonical не редирект. Редирект отправляет пользователя с одной страницы на другую (например, 301 редирект). Canonical просто указывает поисковикам на основной адрес, но не меняет то, что видит пользователь. Это различие критично — редирект замедляет загрузку типа страницы, canonical не влияет на скорость.

Href в canonical должна быть абсолютной ссылкой с протоколом и доменом:

<!-- Правильно -->

<link rel="canonical" href="https://example.com/product/shirt">

<!-- Неправильно — относительная ссылка -->

<link rel="canonical" href="/product/shirt">

<!-- Неправильно — без протокола -->

<link rel="canonical" href="example.com/product/shirt">

Относительные ссылки поисковики могут интерпретировать неправильно, особенно если страница находится на поддомене или в подпапке. Всегда используйте полный адрес.

Примеры применения canonical

Для интернет-магазина: один товар в разных категориях.

На сайте магазина рубашка продаётся в нескольких местах каталога: — shop.example.com/catalog/mens-clothes/shirts/red-shirt — shop.example.com/catalog/new-arrivals/red-shirt

На обеих страницах размещается одинаковый тег canonical:

<link rel="canonical" href="https://shop.example.com/catalog/mens-clothes/shirts/red-shirt">

Этот тег говорит Google: основной адрес товара — первый URL. Вторая версия — просто дополнительная навигация, не конкурирует за позиции в выдаче.

С фильтрами сложнее. Когда пользователь применяет фильтры — ?color=red&size=m&brand=nike — URL становится параметризованной версией. На этой странице нужен canonical, указывающий на основную версию категории без параметров:

<link rel="canonical" href="https://shop.example.com/catalog/mens-clothes/shirts/">

Это говорит, что все возможные комбинации фильтров — это варианты одной основной категории, и весь авторитет должен консолидироваться на чистом URL.

Для блога: пагинация списка статей. Когда статей много, разбивают на несколько страниц. На первой странице:

<link rel="canonical" href="https://blog.example.com/category/tech/">

На второй странице пагинации:

<link rel="canonical" href="https://blog.example.com/category/tech/">

На третьей:

<link rel="canonical" href="https://blog.example.com/category/tech/">

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

Альтернативный подход — каждой странице пагинации указать на саму себя:

<!-- На странице ?page=2 -->

<link rel="canonical" href="https://blog.example.com/category/tech/?page=2">

Это правильно, если каждая из страниц пагинации содержит уникальное и важное содержимое.

Для архивов статей: одна статья доступна несколькими путями: — /article/12345 — основной адрес — /archive/2024/01/article-title — в архиве месяца — /category/tech/article-title — в категории

На всех версиях укажите один и тот же canonical:

<link rel="canonical" href="https://blog.example.com/article/12345">

Это консолидирует весь авторитет на основной адрес статьи.

Где размещать canonical и правила синтаксиса

Тег rel canonical должен быть расположен в разделе head документа, между открывающим <head> и закрывающим </head>. Это не обсуждается — head — единственное правильное место. Если разместить в body или footer, поисковик может его не найти.

Пример правильного размещения:

<title>Page Title</title>

<link rel="canonical" href="https://example.com/page">

<!-- Содержимое страницы -->

На каждой странице может быть только один canonical тег. Если разместить несколько с разными href, поисковики могут проигнорировать их все или выбрать один произвольно. Это приведёт к непредсказуемому результату.

Canonical может быть:

Самоуказывающим — страница указывает на саму себя. Это полезно для чистоты: явно говорит, что данная версия основная. Указывающим на другую страницу — неканоническая версия указывает на основную. Кросс-доменным — если у вас есть международные версии сайта на разных доменах, можно указывать на основной домен.

Все эти варианты поддерживаются Google и Яндекс.

Кроме тега link в head, canonical можно указать через HTTP-заголовок Link. Это полезно, если контент генерируется динамично:

Link: https://example.com/canonical; rel="canonical"

Но для большинства сайтов проще использовать тег в head.

Критично: canonical должна указывать на страницу, которая действительно существует. Нельзя указывать на адрес с ошибкой 404. Если поисковик перейдёт по href и получит код 404, он может проигнорировать весь тег.

Также canonical должна быть логичной. Если две разные страницы указывают друг на друга (A указывает на B, B указывает на A), Google и Яндекс могут обе проигнорировать.

Почему правильный canonical важен для продвижения

Rel canonical — один из главных инструментов контроля над индексацией сайта. Правильное использование canonical решает несколько задач:

Консолидация авторитета. Все внешние ссылки работают на один адрес, в результате чего страница получает максимальный SEO-вес и может лучше ранжироваться в выдаче Google и Яндекс.

Контроль над бюджетом сканирования. Вы явно указываете роботу, какие страницы основные, какие вторичные. Робот тратит меньше времени на сканирование дублей и больше времени на важные страницы сайта.

Предотвращение штрафов. Если поисковик обнаружит много дублей без указания canonical, он может снизить доверие к сайту в целом. Правильная настройка canonical этого избегает.

Упрощение управления. Вместо удаления дублей (что может быть невозможно или вредно для UX), можно просто указать canonical и оставить всё архитектурно как есть.

Улучшение видимости в выдаче. Правильный canonical гарантирует, что в результатах поиска будут показаны те версии страниц, которые вы хотите продвигать, а не случайно выбранные поисковиком дубли.