Канонические метки сошли с ума

  1. Канонические теги, добавленные в <body>
  2. Канонические теги, когда каждая версия ссылается на себя
  3. Забыли включить канонический тег или включить не ту страницу
  4. Канонические теги с параметрами URL
  5. Канонические теги игнорируются
  6. Канонические метки с другими метками
  7. Канонические теги и перенаправления
  8. Проверьте свои канонические теги

Будучи техническим SEO, я люблю копаться в любых странных проблемах, когда кажется, что все работает не так, как ожидалось.

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

Канонические теги, добавленные в <body>

В моем недавнем посте « Канонические теги - это легко, правда? «Я привел пример канонического тега, который выглядит хорошо, если вы просматриваете исходный код, но если вы используете« Inspect »в Chrome Dev Tools для просмотра дерева DOM, вы увидите, что раздел <head> на сайте Home Depot рано выходит из строя, и канонический тег добавляется в раздел <body>, где Google его игнорирует.

Что может быть худшего, если все ваши канонические теги игнорируются? Вы не сможете контролировать предпочитаемую версию или объединение сигналов. Многие страницы будут проиндексированы с неверной версией, или у вас может быть проиндексировано несколько версий одной и той же страницы без консолидации сигналов, и ни одна версия этой страницы не будет иметь такой высокий рейтинг.

Вот несколько различных поисков в Google, которые показывают параметры на веб-сайте Home Depot, которые индексируются, даже если у них есть канонический набор для чистого URL:

Интересно отметить, что канонические теги выглядят хорошо на мобильном сайте Home Depot. Вероятно, один из сценариев, которые они вызывают на настольной версии сайта, вызывает проблему, но проблема решится сама с предстоящим Индекс мобильной связи ,

Если Home Depot хочет исправить это раньше, им, вероятно, удастся сместить канонический тег в разделе <head>, чтобы он превысил все сценарии, или выяснить, что вызывает преждевременное закрытие раздела <head> (что, вероятно, тег, который не был закрыт должным образом).

Канонические теги, когда каждая версия ссылается на себя

Что происходит, когда у вас есть несколько версий одной и той же страницы, и каждая версия имеет канонический тег, который говорит, что это правильная версия? Ответ в том, что Google выберет один или оба, но это, вероятно, не будет последовательным.

Это именно то, что происходит на Meetup.com. На страницах Meetup есть как минимум две версии, используемые взаимозаменяемо: одна с названием Meetup в смешанном регистре в том виде, в котором она была введена, и одна строчная. Смешанный случай любого рода работает для URL-адресов на Meetup.com; попробуйте сделать любой из строчных символов заглавными, или наоборот.

Итак, если у нас есть две версии, которые обе работают, и обе говорят, что они верны, что произойдет?

<link rel = ”canonical” href = ”https://www.meetup.com/RaleighSEO/” />

<link rel = ”canonical” href = ”https://www.meetup.com/raleighseo/” />

В этом случае обе страницы индексируются, но отображается только одна. Обе версии имеют ссылки, и капитал в настоящее время разделен. Я добавил & filter = 0 к поиску Google на снимке экрана ниже, чтобы показать, что оба они действительно проиндексированы. Вы также можете проверить, выполнив команду info: для разных URL, чтобы увидеть канонизированную версию.

Напомним: обе версии страницы проиндексированы, обе имеют ссылки, и только одна из них может быть показана. Быстрое решение проблемы с Meetup здесь может объединить множество сигналов, которые в настоящее время разделены, и они, вероятно, увидят значительное увеличение трафика.

Забыли включить канонический тег или включить не ту страницу

Быстрый поиск «sams club tyres» покажет вам как настольную, так и мобильную версии страницы шин samsclub.com. Проблема здесь в том, что страница m.samsclub.com/tires вообще не имеет канонического тега, позволяющего показывать обе страницы.

Даже если м. На индексированной странице был установлен канонический тег, я не думаю, что он будет работать правильно - сайт рабочего стола ссылается на другую мобильную страницу в качестве альтернативы (https://m.samsclub.com/cat/tire-search/1056) и эта страница 302 перенаправляет на м. страница, показанная в поисковой выдаче выше (https://m.samsclub.com/tires).

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

Без установления связи между настольными и мобильными версиями страницы они будут рассматриваться как отдельные объекты - оба могут отображаться в результатах поиска, и ни один из них не будет оцениваться так высоко, как должен, если это было сделано правильно.

Когда я начал писать это, казалось, что были некоторые проблемы, связанные с канонизацией с тем, что казалось сервером разработки. Канонические теги использовали поддомен сервера dev, который был prod-i.samsclub.com. Эти страницы индексируются и иногда выбираются в качестве версии для показа, даже для домашней страницы сайта.

Похоже, что они недавно исправили это, когда перенаправили prod-i.samsclub.com на www.samsclub.com, но многие из этих страниц все еще можно увидеть в индексе с сайтом: поиск, и их кэшированные версии по-прежнему показывают неверный канонический тег. Если вы собираетесь представить такую ​​среду, я настоятельно рекомендую использовать проверку подлинности на стороне сервера, чтобы поисковые системы не могли ее сначала сканировать, чтобы избежать подобных проблем.

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

Канонические теги с параметрами URL

Существует множество способов, которыми канонические теги могут работать неправильно, если у вас есть несколько версий страницы. Во-первых, если у вас есть несколько версий страницы и нет канонических, то что происходит? Это верно, вы получаете несколько проиндексированных версий.

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

Что происходит, когда вы ссылаетесь только на одну версию мобильного сайта, но параметры URL позволяют использовать более одной версии страницы? Остальные индексируются, как и на этой странице - сайт: samsclub.com притворись игрой inurl: 1938 ,

Знаете ли вы, что есть также инструмент в консоли поиска Google для обработки параметров ?

Канонические теги игнорируются

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

Это происходит со страницей каналов в учетных записях YouTube; просто проверить сайт: youtube.com inurl: каналы , В некоторых ситуациях другие сигналы также могут подавлять канонические теги. Такие вещи, как то, как URL-адреса представляются в карте сайта, и как страницы связаны между собой, являются другими сигналами, и Google также имеет предпочтения для таких вещей, как версии HTTPS и более короткие URL-адреса.

Канонические метки с другими метками

Канонические теги могут иметь различные проблемы при использовании с другими тегами. Я бы сказал, не указывайте каноническое на странице 2 на странице 1 в разбивке на страницы, не используйте noindex на страницах с каноническим тегом и будьте очень осторожны с тегами hreflang, поскольку каждая страница должна быть индексированной версией. Существует множество других проблем, которые возникают, когда канонические теги взаимодействуют с другими тегами.

Канонические теги и перенаправления

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

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

  • https://www.amazon.com/shops/Shop_Name
  • 301> https://www.amazon.com/gp/shops/shopname?some-parameters=stuff
  • 302> https://sellercentral.amazon.com/gp/sc-redirect/seller-page.html?some-parameters=stuff
  • 302> https://www.amazon.com/gp/browse.html?some-parameters=stuff
  • 301> https://www.amazon.com/gp/node/index.html?some-parameters=stuff
  • 301> https://www.amazon.com/s?some-parameters=stuff
  • Последняя версия - это версия, в которой находятся многие списки магазинов Amazon, но мы еще не закончили.
  • Эта страница имеет канонический набор https://www.amazon.com/s?some-different-parameters=stuff (не совпадает с URL-адресом).
  • Этот URL 302 перенаправляет на https://www.amazon.com/ref=nb_sb_noss_null
  • И, наконец, эта страница имеет канонический набор https://www.amazon.com/ .

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

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

Проверьте свои канонические теги

Я нашел большинство своих примеров в статье с простым сайтом: поиск домена в Google и, возможно, удаление фильтрации, как в примере с Meetup, или поиск отдельного продукта или просто что-то, что я увидел в одном из тегов заголовка, чтобы увидеть если бы были другие версии.

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

Мнения, выраженные в этой статье, принадлежат автору гостя и не обязательно относятся к Search Engine Land. Штатные авторы перечислены Вот ,


Об авторе

Что может быть худшего, если все ваши канонические теги игнорируются?
Итак, если у нас есть две версии, которые обе работают, и обе говорят, что они верны, что произойдет?
Во-первых, если у вас есть несколько версий страницы и нет канонических, то что происходит?
Более интересный вопрос может быть, что происходит, когда у вас есть отдельная мобильная версия с параметрами?
Что происходит, когда вы ссылаетесь только на одну версию мобильного сайта, но параметры URL позволяют использовать более одной версии страницы?
Com/gp/shops/shopname?
Html?
Html?
Html?
Com/s?