Привіт, друзі. Пора б мені вже довести до логічного завершення тему про управління індексацією сайту. Я вам нагадаю, які методи управління індексацією взагалі існують: файл robots.txt, мета-тег robots, заголовок X-Robots-Tag, ну і 301-редирект тут можна згадати, як метод боротьби з дублями, що так само є невід’ємною частиною якісної індексації. І про це я вам вже розповідав, але є ще один дуже важливий і цікавий спосіб боротьби з дублями, в чомусь альтернатива редіректу, це атрибут rel=”canonical”, який присвоюється тегу link і розташовується в частині будь-який html-сторінки.

Виглядає це якось так:

Що важливо – цей тег підтримується всіма пошуковими системами, в тому числі нашими улюбленими Яндекс і Google.

Отже, сьогодні я розповім вам, як і для чого потрібно використовувати тег rel canonical, в яких ситуаціях він дійсно ефективний, а заодно переконаємося в цій самій ефективності на реальному експерименті. Приготуйтеся 🙂

Для початку нагадаю вам про тих постах, що я порушив на початку:

X-Robots-Tag HTTP header як спосіб керування індексацією вмісту сайту
Особливості індексації сайтів при використанні robots.txt і мета-тега robots
Теорія, практика та правила використання редиректів

Спершу варто пройтися по теорії, щоб зрозуміти для чого цей атрибут взагалі був створений, які цілі переслідувалися і дізнатися, що ж рекомендують пошуковики.

Теорія і довідка від пошукових систем

Наводжу посилання на офіційну позицію пошукових систем: Google про атрибут rel=”canonical” та Яндекс про атрибут rel=”canonical” тега . Зрозуміло, і mail.ru тут як тут – про значення canonical в теге — не могли ж вони відстати від Яндекса, але це і добре, все під копірку, нам найпростіше.

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

Що таке канонічна сторінка? Це рекомендований примірник з набору сторінок з дуже схожим змістом.

Навіщо потрібно вказувати канонічну сторінку? Якщо пошукова система бачить, що сторінки дуже схожі або однакові, то згідно алгоритмам в результатах пошуку з’явиться тільки одна краща сторінка, яка, на думку пошукової системи, яка краще всього відповідає на запит користувача.

А як ми знаємо, пошуковик не завжди вгадує наші бажання, тому краще перестрахуватися і вказати потрібну сторінку самостійно. Зробити це можна додавши посилання rel=”canonical” в розділ неканонічних версій всіх сторінок HTML.

Ще виявляється, можна вказувати канонічну посилання для HTML вмісту, а, наприклад, для pdf, doc або інших файлів за допомогою заголовків. Типу як X-Robots-Tag HTTP header, тільки тут буде Link HTTP header. Але це вже зовсім для гік-маніяків, так що розповідати про це не буду.

Чи повинна ця посилання бути абсолютною або відносною? Можна вказувати і так і так, але щоб уникнути помилок і наступних непорозумінь, варто використовувати абсолютні посилання.

Що буде, якщо атрибут rel=”canonical” вказує на неіснуючу сторінку? А якщо канонічними призначено кілька сторінок набору? У цьому випадку пошукова система просто проігнорує дані правила і буде діяти, як і раніше — обчислювати підходящий екземпляр з набору сторінок згідно з алгоритмами.

Можна використовувати атрибут rel=”canonical” для вказівки канонічного URL на іншому домені? Можна, але не потрібно. Важливо розуміти, що атрибут canonical це лише порада або рекомендація, а не суворе правило на відміну від редиректа, який варто використовувати в даному випадку.

На підставі всього вищезазначеного, а так само за інформацією з інших офіційних джерел (блоги пошукових систем і блоги їх співробітників) можна зробити висновки про те, що тег link rel=”canonical”:

  • Це рекомендація, а не правило, а тому може бути проігнорований у наступних випадках:
    • Документ канонічного адресою не існує, віддає відповідь 404;
    • Канонічна сторінка закрита від індексації robots.txt або мета-тегами;
    • У html-коді сторінки зазначено відразу кілька атрибутів rel canonical;
    • Адреса канонічного документа вказує на інший домен або піддомен;
    • Присутній ланцюжок призначень rel=”canonical”, тобто для документа А канонічним вказаний документ Б, а в цей час для документа Б вказано канонічним документ;
  • Необхідно вказувати тільки для дублюючих або дуже схожих сторінок, а не для склеювання двох різних сторінок або передачі ваги;
  • Адреса канонічної сторінки може вказувати сам на себе;
  • Підтримується всіма пошуковими системами: в Яндексі з 23 травня 2011 року, в Google з 12 лютого 2009.

Практичне застосування і експеримент

Все, з теорією покінчено, тепер я вам розповім, навіщо і для чого я використовую тег rel=”canonical” на своїх сайтах. Головне й основне – це боротьба і попередження появи дублів. В основному це дублі, пов’язані з параметрами або мітками в url. Не завжди доречно боротися з цими проблемами за допомогою редиректів. Мітки іноді дуже важливими, наприклад, коли ведеться кампанія в контексті і в мітках важливі статистичні відомості, та й багато ще чого можна відстежувати мітками. Закривати такі адреси robots.txt мені не по душі, використовувати мета роботс не вийде, а редирект знищить всі дані.

Класичний приклад використання канонічних адрес це інтернет магазини з купою сортувань з ще більшою купі різних параметрів товарів – мені здається, заради цього і придумали цей атрибут.

Це все зрозуміло. Але от тільки про самому головне для нас seo’шників ніде не сказано – а як справи з передачею посилального ваги? Якщо на неканонічний адреса стоять посилання, що ж буде з канонічної сторінкою, чи отримає вона від цього бонуси? А якщо спершу з’явилася посилання, а rel=”canonical” був вказаний пізніше? А що буде, якщо все навпаки?

Запитань багато, а офіційних коментарів немає. На питання хто винен і що робити, відповідь одна – треба ставити експеримент! Хотів я такий експеримент поставити, але виявилося, що його вже не так давно провів Ігор, автор блогу bakalov.info за що йому величезне спасибі.

Ось цитата з його блогу про те, яка мета, які варіанти розвитку подій і очікуваний результат:

Мета експерименту: з’ясувати, чи буде переданий «вага посилань зі сторінки А на сторінку З, в тому випадку, якщо сторінка, А посилається на сторінку Б, а на сторінці Б варто rel=”canonical”, який вказує, що канонічної сторінкою є сторінка С.

Якщо зі сторінки А на сторінку З «вага посилання» передається, то необхідно з’ясувати чи має значення «першочерговість».

Варіант №1. Сторінка А посилається на сторінку Б і це посилання проіндексована пошуковими системами. Через деякий час на сторінці Б встановлюється rel=”canonical”, який вказує, що канонічною є сторінка, що в підсумку призводить до виключення сторінки Б з індексу.

Варіант №2. На сторінці Б встановлюється rel=”canonical”, який вказує, що канонічною є сторінка, що призводить до виключення сторінки Б з індексу. Через деякий час після цього зі сторінки А на сторінку Б встановлюється посилання.

Необхідно з’ясувати в якому з двох варіантів буде переданий «вага посилань зі сторінки А на сторінку С. Під «вагою» посилання ” я розумію так званий «анкорный вагу», тобто якщо сторінка акцептор шукається за текстом стоїть на неї посилання, то вважаємо, що «вага посилання» передається, якщо не шукається, то не передається.

Повний опис і хід експерименту дивіться за посиланням.

Я ж повідомлю результати експерименту та висновки:

Для Яндекса не має значення, що з’явилося раніше – rel=”canonical”, або зовнішнє посилання – в будь-якому випадку «вага посилання» буде переданий з неканонічного URL на канонічний.

Для Google насправді все аналогічно, хоча в пості Ігоря йдеться інакше: якщо канонічний адресу було вказано сторінки вже склеїлися, а потім з’явилася зовнішня посилання, то вага передається, а якщо зовнішня посилання з’явилася раніше, ніж каноникал, то вага не перетікає.
Просто «перетікання» ваги у другому випадку зайняло трохи більше часу, адже згідно з коментарем на блозі сказано, що канонічна сторінка все ж шукається за анкорному тексту.

Коротше, все працює!

В черговий раз узагальнюючи всю інформацію, викладену в пості, хочу сказати, що використовувати тег link rel=”canonical” потрібно. В першу чергу це відмінний спосіб запобігти дублювання контенту (особливо це стосується помилок і недоробок більшості CMS) і накладення санкцій за це з боку пошукових систем.

Удачі вам, друзі! Залишайте коментарі і задавайте питання.

З повагою, Олександр Алаєв