International SEO: gdy Google mimo poprawnie wdrożonego HREFLANG daje nieoczekiwane wyniki
Przy wielojęzycznych stronach i w International SEO poprawna implementacja atrybutu hreflang często stanowi wyzwanie. Ten atrybut ma pomagać wyszukiwarkom wybierać właściwą wersję językową i krajową strony dla użytkowników. Jednak nawet przy poprawnym wdrożeniu może dochodzić do nieoczekiwanych rezultatów, gdy dla tego samego obszaru językowego utworzono różne wersje krajowe, jak bywa np. w przypadku Austrii, Niemiec i Szwajcarii albo Anglii, USA, Australii itd. Ten problem HREFLANG ujawnia się wtedy w Search Console.
W Search Console pojawia się wtedy wskazówka, że przy indeksowaniu nie użyto kanonicznego adresu URL podanego przez użytkownika, lecz Google wybrało inny adres jako kanoniczny. Przykład – tutaj URL został zanonimizowany przez narzędzia deweloperskie:
Nawet przyporządkowanie treści przez ccTLD (.de i .at) nie pomaga. Także przy domenach najwyższego poziomu problem może się pojawić. Kontynuując fikcyjny przykład:
Mechanizm stojący za problemem
To nieoczekiwane zachowanie Google może wystąpić, gdy crawler wyszukiwarki indeksuje strony z różnych krajów, które są treściowo bardzo podobne. Przykład: Google najpierw crawluje niemiecką (DE) wersję strony, oblicza tzw. wartość hash i indeksuje stronę z adresem DE jako wersją kanoniczną. Gdy Google następnie crawluje austriacką (AT) wersję strony, ponownie oblicza wartość hash i rozpoznaje, że jest ona identyczna z już zaindeksowaną wersją DE. Zamiast indeksować adres AT osobno, Google dołącza go do już istniejącego dokumentu.
Hashing to technika, której Google używa, aby efektywniej indeksować treści stron i rozpoznawać duplikaty. Wartość hash to unikalna, kryptograficzna wartość (rodzaj odcisku palca), tworzona przez funkcję hashującą na podstawie treści strony. Gdy dwie strony mają tę samą wartość hash, wskazuje to, że ich treść jest identyczna lub bardzo podobna. Za pewne można uznać, że Google stosuje SimHash przy crawlowaniu.
SimHash do porównywania treści i rozpoznawania duplikatów
SimHash to specjalna technika, której Google używa do efektywnej analizy i porównywania treści, zwłaszcza pod kątem rozpoznawania duplicate content. SimHash pozwala szybko sprawdzać duże ilości danych pod kątem podobieństw, bez konieczności pełnego porównywania każdej pojedynczej treści.
SimHash działa, wyodrębniając z tekstu określone cechy (features), np. częste słowa, frazy lub struktury. Te cechy są przekształcane w wektor reprezentujący najważniejsze właściwości tekstu. Po wektoryzacji następuje hashing. Z tego wektora funkcja hashująca generuje krótszą sekwencję bitów (SimHash). Sztuczka polega na tym, że podobne teksty prowadzą do podobnych wartości SimHash, co umożliwia szybką identyfikację podobnych lub prawie identycznych treści.
Google używa SimHash do detekcji duplicate content, czyli do szybkiego i efektywnego rozpoznawania podwójnych lub bardzo podobnych treści na różnych stronach. Gdy dwie strony mają podobną wartość SimHash, Google może potraktować to jako wskaźnik, że treści są bardzo podobne, i ewentualnie przyjąć do indeksu tylko jedną wersję strony.
Zamiast przy każdym crawlowaniu przeprowadzać pełną analizę tekstu, Google może za pomocą SimHash szybko sprawdzić, czy treść strony znacząco różni się od innych treści. To oszczędza zasoby i przyspiesza proces crawlowania i indeksowania.
Ważnym aspektem SimHash jest zdolność rozpoznawania podobnych treści na podstawie odległości Hamminga. Odległość Hamminga mierzy liczbę pozycji bitowych, na których dwie wartości SimHash się różnią. Mała odległość Hamminga między dwiema wartościami SimHash oznacza, że odpowiadające im treści są bardzo podobne. W przeciwieństwie do tradycyjnych metod hashowania, gdzie nawet mała zmiana treści może prowadzić do zupełnie innej wartości hash (odporność na kolizje), SimHash produkuje podobne wartości dla podobnych treści, co czyni go szczególnie użytecznym do rozpoznawania niemal identycznego contentu.
Strony o podobnych wartościach SimHash mogą więc wypadać gorzej w rankingu, bo są traktowane jako duplicate content albo jako mniej oryginalne, ponieważ Google chce pokazywać w wynikach możliwie unikalne i wysokojakościowe treści.
Swoją drogą: SimHash może być wykorzystywany przez operatorów bardzo dużych stron, które dużo pracują z text spinningiem i programmatic SEO w tworzeniu treści, także do automatycznego porównywania treści i mierzenia stopnia duplicate content.
Dlaczego hreflang czasem nie działa
Google używa więc – zapewne obok innych metod – SimHash, aby analizować treść stron i ustalać, czy strony są duplikatami. Gdy dwie strony, jak wersje DE i AT, mają tę samą wartość SimHash, Google traktuje je jako identyczne i wybiera jeden kanoniczny URL, niezależnie od tagów hreflang. Tagi hreflang, tak samo jak atrybuty html lang czy tagi canonical, nie są dla Google wiążące, inaczej niż np. tagi noindex czy dyrektywy w robots.txt. Dlatego Google robi to, co uważa za słuszne w duchu najlepszego doświadczenia użytkownika. Ustalenie, który URL zostanie uznany za kanoniczny, opiera się na różnych czynnikach, jak liczba linków przychodzących, pozytywne sygnały użytkowników i inne kryteria. Ten kanoniczny URL jest pokazywany w Google Search Console (GSC) jako taki i to jemu przypisywany jest cały ruch.
Nie oznacza to jednak koniecznie, że użytkownikom w wynikach wyszukiwania zawsze pokazywany jest ten kanoniczny URL. Google pokazuje raczej dokładnie ten adres, który jest dla użytkownika najbardziej trafny – a to nie zawsze musi być URL kanoniczny. Tak, wiem, brzmi to skomplikowanie, wręcz sprzecznie.
Gdy między stronami istnieją drobne różnice – jak mały moduł na jednej stronie, którego brakuje na drugiej – może to prowadzić do rozróżnienia wystarczająco dużego, aby uznać treść za indywidualny content. Jednak nawet minimalna różnica w wytycznych wyszukiwarek albo zmiana w treści lub designie strony może sprawić, że Google potraktuje strony różnie albo je połączy.
Czasem zachowanie Google jest naprawdę godne uwagi. Znam osobiście przykład sklepu internetowego z meblami, w którym strona jest dostępna zarówno jako .at dla klientów austriackich, jak i jako .de dla klientów niemieckich. Według Search Console Google wybrało adres .at zamiast .de jako kanoniczny URL, mimo że dla niemieckiej strony jako kanoniczny URL strona zdefiniowała adres .de.
Szczególnie dziwny stał się ten przypadek, gdy sklep meblowy wyłączył produkt na stronie .at i strona zwracała 404.
URL nadal jest w indeksie i prowadzi na stronę 404, podczas gdy niemiecka strona nadal zawiera produkt, ale nie jest w indeksie.
Strona .de wciąż pokazuje treść, choć artykuł jest wyprzedany. Mimo to zdumiewające jest, że Google ma w indeksie stronę 404, a niemieckiego odpowiednika z dostępną treścią nie.
Jak problem wpływa na dane GSC
Opisane zachowanie Google, w którym różne wersje krajowe strony są łączone i wybierany jest jeden kanoniczny URL, ma bezpośredni wpływ na wartość informacyjną danych w Google Search Console (GSC). Ten problem prowadzi do tego, że pokazywane w GSC dane o wydajności nie zawsze odzwierciedlają faktyczną prezentację wyników wyszukiwania.
Gdy Google rozpozna różne wersje krajowe strony jako duplikaty i wybierze jedną z nich jako kanoniczny URL, cały ruch, który otrzymują poszczególne wersje, jest w GSC przypisywany adresowi kanonicznemu. Oznacza to, że w GSC mogą być pokazywane dane o ruchu tylko dla wersji DE strony, chociaż użytkownicy w Austrii faktycznie widzieli wersję AT. To zniekształca dane i utrudnia poprawny pomiar sukcesu poszczególnych wersji krajowych.
Także dane o rankingach mogą być zaburzone przez to zachowanie. Jeśli Google uzna np. adres AT za kanoniczny, ale użytkownikom w Niemczech nadal pokazuje wersję DE, dane rankingowe w GSC mogą być równie mylące. Ta rozbieżność powstaje, bo dane GSC opierają się na kanonicznym URL, podczas gdy faktyczne wyniki wyszukiwania mogą pokazywać inny adres.
W GSC wygląda to tak, jakby performowała tylko jedna strona, podczas gdy w rzeczywistości w różnych krajach pokazywanych jest kilka adresów URL. To utrudnia analizę i zrozumienie wydajności na poziomie krajów, zwłaszcza gdy firmy celowo stosują różne treści lub optymalizacje dla różnych rynków.
Przez to zachowanie Google zespoły SEO muszą dostosować swoje podejście analityczne. Zamiast polegać wyłącznie na danych pokazywanych w GSC, można używać narzędzi zewnętrznych, aby sprawdzać, który URL faktycznie jest pokazywany w wynikach wyszukiwania w różnych krajach. Ponadto może być konieczne dokładniejsze spojrzenie na możliwości filtrowania w GSC, np. analiza danych według kraju i katalogu krajowego, aby uzyskać jaśniejszy obraz faktycznej wydajności na poszczególnych rynkach. Pomocą mogą tu być także zapytania regex w Search Console. Wkrótce ukaże się mój osobny artykuł na ten temat.
Strategie rozwiązania
Najlepiej byłoby, gdyby Google traktowało każdy wariant językowo-krajowy jako kanoniczny URL. Jak widzimy, przy identycznych językach nie jest to pewne. Możliwym podejściem byłoby zakwestionowanie konieczności wariantów krajowych i sprawdzenie, czy nie sensowniej jest tworzyć tylko jedną wersję dla rynków identycznych językowo. Może to być szczególnie pomocne, gdy różnice między krajami są minimalne. Jeśli nie ma nawet różnic w walucie, jak np. między Niemcami (euro) a Szwajcarią (frank), tworzenie dla Austrii z euro dodatkowego katalogu /de-AT/, w którym wszystkie treści są zduplikowane, ma niewiele sensu.
Jak mocno Google ogranicza indeksowanie stron, można bardzo prosto zmierzyć zapytaniem InURL w wyszukiwarce Google. Przykład na poniższym zrzucie: w sitemapie strony zapisano 644 strony dla /de-CH/ i kolejnych 1312 dla /de-DE/. W indeksie wyszukiwania jest ich faktycznie znacznie mniej. Ponadto ta strona ma jeszcze katalog /de-AT/. Można przyjąć, że wiele stron nie jest w indeksie, a wiele innych zostało połączonych w jeden kanoniczny URL dla języka niemieckiego.
Także niektóre narzędzia SEO alarmują po crawlowaniu w kwestii duplicate content. Z tego powodu tam, gdzie po stronie krajów nie ma różnic w treści, ofercie, dostawach ani innych specyficznych cech, lepiej postawić na katalogi językowe i połączyć trzy katalogi dla Niemiec, Austrii i Szwajcarii w /de/.
Kolejna – i zapewne najlepsza – strategia poprawnej kanonizacji pożądanych adresów polega na silniejszym różnicowaniu contentu. Nawet gdy język jest ten sam, różnice w metadanych, treści głównej lub prowadzeniu użytkownika mogą pomóc przekonać algorytm Google, że chodzi o samodzielne treści, przypisane do konkretnego regionu. Można np. pracować ze zmiennymi, które witają odwiedzających z danego kraju. Serdecznie witamy z <variable>, miło, że Państwo tu są. Za <variable> podstawiane jest wtedy odpowiednio: Austria dla de-at, Niemcy dla de-de, Szwajcaria dla de-ch i tak dalej. To samo działa z … nasze warunki dostawy dla <variable>. Im bardziej zróżnicowany content, tym bardziej indywidualna wartość hash i tym bardziej prawdopodobne, że Google uzna każdą stronę za osobny kanoniczny URL.
Trzecim podejściem może być też używanie tagów hreflang w sitemapach, bo w niektórych przypadkach prowadzi to do jaśniejszego przyporządkowania przez Google. My sami również wydajemy nasze tagi hreflang w sitemapie i ograniczamy się do czystego wariantu językowego bez kodu kraju.
Najskuteczniejszym środkiem pozostaje moim zdaniem różnicowanie treści tak dalece, jak to możliwe, aby wysyłać Google wyraźne sygnały, że chodzi o różne strony.
