Что происходит, когда канонические теги выходят из-под контроля и как вы можете их обуздать? Обозреватель Патрик Стокс делится своими открытиями и выводами.Являясь техническим SEO, я люблю вникать в какие-то странные проблемы, когда ситуация не работает должным образом.
Канонические теги кажутся достаточно легкими, но эти теги вызывают всевозможные интересные проблемы - и некоторые незначительные исправления могут привести к большим выигрышам. Почти у каждого крупного веб-сайта будут какие-то проблемы с их каноническими тегами, поэтому я вникнул в несколько разных, чтобы увидеть, какие примеры я могу найти.
Канонические метки, брошенные в
В моей недавней статье «Канонические теги просты, правильно?» Я привел пример канонического тега, который выглядит отлично, если вы просматриваете исходный код, но если вы используете «Inspect» в Chrome Dev Tools для просмотра дерева DOM, вы увидите, что раздел сайта Home Depot рано ломается, а канонический тег добавляется в раздел, где Google игнорирует его.
Какое худшее может произойти, если все ваши канонические теги игнорируются? У вас не будет контроля над предпочтительной версией или консолидации сигналов. Многие страницы будут проиндексированы с неправильной версией, или у вас может быть несколько версий одной и той же страницы, индексированных без консолидации сигналов, и ни одна версия этой страницы не будет оцениваться как можно выше.
Вот несколько разных поисков в Google, которые показывают параметры на сайте Home Depot, которые индексируются, хотя у них есть канонический набор для чистого URL:
сайт: homedepot.com inurl: bvrrp
сайт: homedepot.com inurl: MERCH
Интересно отметить, что канонические теги кажутся хорошими на мобильном сайте Home Depot. Вероятно, один из сценариев, которые они призывают к настольной версии сайта, вызывает проблему, но проблема будет решена с помощью предстоящего индекса мобильной связи.
Если бы Home Depot захотелось исправить это раньше, они, вероятно, могли бы уйти с перемещением канонического тега в секции, поэтому это, прежде всего, скрипты или выяснить, что заставляет раздел закрываться раньше (что, скорее всего, тег, который не был закрыт должным образом).
Канонические теги, когда каждая версия ссылается сама
Что происходит, когда у вас несколько версий одной и той же страницы, и каждая версия имеет канонический тег, который говорит, что это правильная версия? Ответ заключается в том, что Google выберет один или оба, но он, вероятно, не будет последовательным.
Именно это происходит на Meetup.com. На встречающихся страницах по крайней мере две версии используются взаимозаменяемо: одна с именем Meetup в смешанном случае, когда она была введена, и одна строка в нижнем регистре. Смешанный случай любого вида работает для URL-адресов на Meetup.com; попробуйте сделать любой из символов нижнего регистра заглавными или наоборот.
Итак, если у нас есть две версии, которые работают, и оба говорят, что они правильные, что происходит?
В этом случае обе страницы индексируются, но показывается только один. Обе версии имеют ссылки, и в настоящее время справедливость разделена. Я добавил & filter = 0 в поиск Google на снимок экрана ниже, чтобы я мог показать, что оба индекса действительно индексированы. Вы также можете проверить, выполнив команду info: для разных URL-адресов, чтобы просмотреть каноническую версию.
Напомним: обе версии страницы индексируются, обе имеют ссылки, и только один может показать. Быстрое исправление от Meetup здесь может объединить много сигналов, которые в настоящее время разделены, и они, вероятно, будут видеть увеличение трафика.
Забыл включить канонический тег или включить неправильную страницу
Быстрый поиск по «шинам sams club» покажет вам как настольные, так и мобильные версии шины samsclub.com. Проблема здесь в том, что на странице m.samsclub.com/tires нет канонического тега вообще, что позволяет обе страницы показывать.
Даже если м. страница с индексированием имела канонический тег на месте, я не думаю, что этот будет работать правильно - сайт рабочего сайта ссылается на другую мобильную страницу в качестве альтернативного (https://m.samsclub.com/cat/tire-search/1056) , а страница 302 перенаправляется на m. страница, показанная в результатах поиска (https://m.samsclub.com/tires).
Наличие несоответствия в альтернативных версиях является распространенной проблемой на их сайте, а m.samsclub.com показывает во многих результатах поиска на рабочем столе, потому что они не указывают соединения так, как им нужно, чтобы консолидировать страницы.
Без установления взаимосвязи между настольными и мобильными версиями страницы они будут рассматриваться как отдельные объекты - оба могут отображаться в результатах поиска, и ни один из них не будет оцениваться как можно выше, если это будет сделано правильно.
Когда я начал писать это, было похоже, что были проблемы с канонизацией с тем, что, казалось, было dev-сервером. Канонические теги использовали субдомен dev-сервера, который был prod-i.samsclub.com. Эти страницы индексировались и иногда выбирались в качестве версии для показа, даже для домашней страницы веб-сайта.
Похоже, что недавно они исправили это, поскольку перенаправили prod-i.samsclub.com на www.samsclub.com, но вы все еще можете видеть многие из этих страниц в индексе с помощью сайта: search, а их кэшированные версии по-прежнему показывают неправильный канонический тег. Если вы собираетесь разоблачить такую среду, я бы настоятельно рекомендовал использовать аутентификацию на стороне сервера, поэтому поисковые системы не смогут обходить ее в первую очередь, чтобы избежать подобных проблем.
Другой потенциальной катастрофой является копирование страницы, а не изменение канонической или случайной настройки раздела или даже всего веб-сайта на каноническую страницу на одну страницу. Хотя некоторые из них будут проигнорированы, другие могут быть уважаемы, и вы можете увидеть снижение трафика на многие страницы.
Канонические теги с параметрами URL
Существует много способов, по которым канонические теги могут ошибаться, когда у вас несколько версий страницы. Во-первых, если у вас несколько версий страницы и нет канонических, то что происходит? Правильно, вы индексируете несколько версий.
Более интересным может быть вопрос, что происходит, когда у вас есть отдельная мобильная версия с параметрами? Когда вы подключаете, скажем, m. мобильный сайт и настольную версию, то вам нужно указать альтернативную версию страницы на рабочем столе и канонически с мобильного сайта на рабочий стол.
Что происходит, когда вы ссылаетесь только на одну версию мобильного сайта, но параметры URL-адреса делают так, что существует более одной версии страницы? Остальные индексируются, так как у них есть эта страница - сайт: samsclub.com притворяется игрой inurl: 1938.
Знаете ли вы, что в Google Search Console есть инструмент для обработки параметров?
Канонические теги игнорируются
Помните, что канонические теги - это намек, а не директива. Они созданы для дублирования версий страниц, и во многих случаях вы можете избежать почти дублированных версий. Если страница, установленная вами как каноническая, слишком отличается от вашей целевой страницы, канонический, скорее всего, будет проигнорирован.
Это происходит с страницей каналов в аккаунтах пользователей YouTube; просто зайдите на сайт: youtube.com inurl: каналы. В некоторых ситуациях другие сигналы могут превзойти канонические теги. Такие вещи, как URL-адреса, представленные в файле Sitemap, и то, как страницы связаны друг с другом, являются другими сигналами, а у Google также есть предпочтения для таких вещей, как версии HTTPS и более короткие URL-адреса.
Канонические теги с другими тегами
Канонические теги могут иметь всевозможные проблемы при использовании с другими тегами. Я бы сказал, не указывайте канонические на странице 2 на страницу 1 в разбитом на страницы, не используйте noindex на страницах с каноническим тегом и будьте очень осторожны с тегами hreflang, так как каждая страница должна быть проиндексированной версией. Есть много других проблем, которые происходят, когда канонические теги взаимодействуют с другими тегами.
Канонические теги и перенаправления
Как правило, это плохая идея для канонической страницы, которая перенаправляется. Это обычно ломает что-то или консолидирует сигналы непоследовательно. Возьмите магазины Amazon, например, где есть много перенаправлений и странная канонизация.
Посмотрите, что происходит, и обратите внимание, что на каждом шаге индексируются страницы и что URL-адреса могут использовать чистое имя или идентификаторы магазина или и то, и другое.
Это последняя версия, в которой перечислены многие списки магазинов 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, или поиск отдельного продукта или просто что-то, что я видел в одном из тегов заголовка, чтобы увидеть если бы были другие версии.
Ни один из этих примеров не заставил себя долго ждать, и я даже не использовал обходчика, но вы обязательно должны использовать искателя при поиске проблем на своем собственном веб-сайте. Я бы ожидал, что на каком-либо крупном веб-сайте будет представлено несколько примеров канонических тегов.
Мнения, выраженные в этой статье, принадлежат авторам гостевых изданий, а не обязательно поисковым системам. Здесь перечислены авторы работ.
Post A Comment:
0 comments so far,add yours