Про тонкощі роботи з HREFLANG або чому він в деяких випадках не працює

Презентація Софі Гібсон з BrightonSEO про тонкощі роботи з HREFLANG або чому він в деяких випадках не працює (slideshare.net/SophieGibson3/why-the-fck-doesnt-href-lang-work)

Кілька тез з її виступу:

  • Hreflang можна впровадити трьома способами: HTML теги, HTTP заголовки, XML Sitemap.
  • Для роботи hreflang достатньо двох умов: валідні атрибути і зворотні теги на всіх альтернативних версіях сторінок.
  • У реальності все складніше. Основні складності: розмір сайту, CMS, наявність ресурсів.
  • Зовнішні проблеми: суміш різних версій сторінок в потрібній локації, контент не індексується, гугл класифікує альтернативні сторінки як канонічні для інших сторінок.

Кейс: інтернет-магазин в UK і двох інших країнах, використовує hreflang в HEAD.

В UK видачі ранжуються не UK версії. У GSC все норм, теги впроваджені правильно, чому вони поводяться не так? Перевірили сторінку W3C валідатором. Знайшли NOSCRIPT в тезі HEAD. Зокрема, це був Піксель від FB. Перемістили NOSCRIPT в BODY. Не UK версії як і раніше в UK видачі.

Перевірили сторінку в Sitebulb. Одна з помилок: скрипти третіх осіб в HEAD заважають завантаженню сторінки або призводять до помилок. Скриптів було близько 20. Перемістили теги hreflang над скриптами. Не UK версії сторінок як і раніше в UK видачі. Чому цей hreflang не працює?

Якщо ти відвідуєш .com версію сайту, то тебе редиректить в папку. Забули, що гугл приходить з американських айпі і його редирект в / us/. Користувач міг поміняти регіон, але чи міг пошуковик? Гугл не бачив посилання на регіональні версії сторінок, тому що меню використовувалися яваскрипт-посилання. Пофіксили ці посилання, замінивши на звичайні. Все налагодилося.

Підсумок: проблема з hreflang може каскадуватися. Використовуйте краще sitemap замість head для hreflang.

Оцініть статтю
Додати коментар