Hreflang: jak oznaczyć wersje językowe strony, żeby Google ich nie mylił

Do czego służy hreflang i czego nie należy od niego oczekiwać

Hreflang służy do powiązania ze sobą podstron, które mają tę samą treść przygotowaną dla odbiorców mówiących różnymi językami lub mieszkających w różnych krajach. Google, znając takie powiązanie, może w wynikach wyszukiwania wyświetlić ten adres, który najlepiej pasuje do języka i regionu osoby szukającej. Tak cel tego oznaczenia przedstawia dokumentacja Przekazywanie Google informacji o zlokalizowanych wersjach strony. Zaznacza ona, że Google może odnaleźć wersje językowe także samodzielnie, jednak wyraźne ich wskazanie jest zwykle najlepszym rozwiązaniem.

Hreflang a pozycje w wynikach

W dokumentacji Google poświęconej wersjom językowym nie ma wzmianki o tym, że hreflang podnosi pozycje. Opisany jest wyłącznie jako narzędzie doboru właściwej wersji dla użytkownika. Z naszej praktyki wynika, że najtrafniej jest myśleć o nim jak o zamianie adresu: jeżeli w wynikach niemieckich widoczna jest polska wersja podstrony, to po poprawnym wdrożeniu oznaczeń w tym samym miejscu może pojawić się jej niemiecki odpowiednik. Jest to obserwacja, a nie obietnica zapisana w dokumentacji. Sama widoczność w danym kraju nadal zależy od treści, linków i stanu technicznego witryny, czyli od tego, czym zajmuje się pozycjonowanie zagraniczne.

Hreflang nie informuje Google, w jakim języku jest strona

Częstym nieporozumieniem jest przekonanie, że wystarczy przypisać podstronie kod „de”, aby wyszukiwarka uznała ją za niemiecką. Dokumentacja mówi wprost, że Google nie używa hreflang ani atrybutu lang do wykrywania języka strony. W drugim dokumencie, Zarządzanie witrynami multiregionalnymi i wielojęzycznymi, czytamy, że język rozpoznawany jest na podstawie widocznej treści. Podstrona oznaczona jako niemiecka, na której większość tekstu pozostała po polsku, nie stanie się przez to niemiecka.

Zasady omawiane dalej pochodzą z dokumentacji Centrum wyszukiwarki Google oraz ze stron pomocy Search Console. Tam, gdzie opieramy się na własnym doświadczeniu, wyraźnie to zaznaczamy.

Kiedy oznaczenia hreflang są potrzebne, a kiedy można je pominąć

Oznaczenia są potrzebne wtedy, gdy ta sama podstrona istnieje pod kilkoma adresami przeznaczonymi dla różnych języków lub krajów. Dokumentacja Google wymienia trzy typowe sytuacje. Pierwsza to serwis, w którym główna treść pozostaje w jednym języku, a przetłumaczony jest tylko szablon, czyli nawigacja i stopka. Druga to treść w jednym języku z niewielkimi różnicami regionalnymi, na przykład angielska oferta osobno dla Stanów Zjednoczonych, Wielkiej Brytanii i Irlandii. Trzecia to witryna w całości przetłumaczona na kilka języków. Firma działająca wyłącznie w Polsce i mająca stronę tylko po polsku nie ma czego ze sobą wiązać, więc oznaczeń nie potrzebuje.

Warunek wstępny: osobny adres dla każdej wersji

Zanim powstanie pierwszy znacznik, każda wersja językowa musi mieć własny adres URL. Google zaleca osobne adresy zamiast zmiany języka na podstawie plików cookie lub ustawień przeglądarki. Powód wyjaśnia dokument Jak Google indeksuje strony o treści zależnej od języka: domyślne adresy IP Googlebota wyglądają na amerykańskie, a robot nie wysyła nagłówka Accept-Language, w którym przeglądarka zwykle podaje preferowany język. Jeżeli więc pod jednym adresem serwis pokazuje raz tekst polski, raz niemiecki, część wersji może w ogóle nie zostać zeskanowana ani zindeksowana.

Wersje mogą znajdować się w katalogach jednej domeny, w subdomenach albo w osobnych domenach krajowych. Dokumentacja opisuje zalety i wady każdego układu, a odradza jedynie rozróżnianie wersji parametrem w adresie. Hreflang działa we wszystkich tych układach, ponieważ alternatywne adresy nie muszą należeć do tej samej domeny. O nazewnictwie katalogów i podstron piszemy we wpisie o tym, jak budować strukturę adresów URL.

Jak zapisać kod języka i kraju w hreflang

Wartość atrybutu hreflang składa się z kodu języka, po którym opcjonalnie, po dywizie, następuje kod kraju. Język zapisuje się dwuliterowym kodem ze standardu ISO 639-1, a kraj dwuliterowym kodem ze standardu ISO 3166-1 alfa-2. Kody spoza tych standardów nie są obsługiwane, a dokumentacja jako przykład nieobsługiwanej wartości podaje „es-419”.

Można podać sam język, na przykład „de”, i wtedy wersja jest przeznaczona dla wszystkich osób niemieckojęzycznych niezależnie od kraju. Można też podać język z krajem, na przykład „de-AT” dla niemieckojęzycznych odbiorców z Austrii. Nie można natomiast podać samego kraju. Google ilustruje to przykładem Belgii: poprawne są wartości „de-BE”, „nl-BE” i „fr-BE”, a samo „be” jest błędem, ponieważ w standardzie języków oznacza język białoruski.

Wielkość liter nie ma znaczenia dla wyszukiwarki, ale przyjęło się zapisywać kod języka małymi literami, a kod kraju wielkimi. Warto trzymać się tej konwencji, bo ułatwia czytanie kodu i wychwytywanie pomyłek.

Kody, które wyglądają poprawnie, a nie działają

Najwięcej pomyłek dotyczy kodów kraju. Dokumentacja wymienia kody zarezerwowane, takie jak „EU”, „UN” i „UK”, i zaznacza, że Google je ignoruje. Poprawny zapis dla Wielkiej Brytanii, używany w przykładach Google, to „en-GB”. Unia Europejska nie jest krajem, więc jednej wersji nie da się skierować „na całą Europę” jednym kodem. W takiej sytuacji rozsądniej jest podać sam język. Druga grupa pomyłek to mylenie kodu języka z kodem kraju, czego przykładem jest opisany wyżej przypadek Belgii. Oba kody bywają identyczne, jak dla języka polskiego i Polski, ale nie jest to regułą, dlatego każdą wartość warto potwierdzić w wykazie standardu.

Wersja ogólna obok wariantów krajowych

Jeżeli firma ma kilka wersji w tym samym języku dla różnych krajów, Google radzi przygotować również wersję ogólną, oznaczoną samym kodem języka. Trafią na nią osoby, które mówią w danym języku, ale mieszkają w kraju nieobjętym żadnym wariantem. W pierwszym przykładzie z dokumentacji obok wersji „en-GB” i „en-US” występuje właśnie ogólna wersja „en”. Hipotetyczny sklep z osobnymi ofertami dla Niemiec i Austrii powinien więc zadbać także o wersję „de”, aby niemieckojęzyczny klient ze Szwajcarii również został skierowany do treści po niemiecku.

Trzy sposoby wdrożenia hreflang i jak wybrać właściwy

Google obsługuje trzy sposoby przekazania oznaczeń: znaczniki link w kodzie HTML, nagłówek HTTP oraz mapę witryny XML. Z punktu widzenia wyszukiwarki są one równoważne. Dokumentacja dopuszcza użycie ich jednocześnie, ale zaznacza, że nie daje to żadnej korzyści w wyszukiwarce, a utrzymanie trzech wdrożeń jest trudniejsze niż jednego. W praktyce doradzamy wybór jednej metody i konsekwentne trzymanie się jej w całym serwisie, ponieważ dwa źródła oznaczeń łatwo zaczynają sobie przeczyć.

Znaczniki w sekcji head

Pierwszy sposób polega na umieszczeniu w sekcji head każdej wersji zestawu elementów link z atrybutami rel="alternate", hreflang i href. Zestaw jest identyczny na wszystkich wersjach i zawiera także wpis prowadzący do strony, na której się znajduje. Google wskazuje tę metodę jako dobrą wtedy, gdy witryna nie ma mapy albo właściciel nie ma wpływu na nagłówki serwera. Dwa zastrzeżenia z dokumentacji: znaczniki muszą stać w poprawnie zbudowanej sekcji head, a elementu z hreflang nie łączy się z innymi atrybutami, na przykład media.

<link rel="alternate" hreflang="pl" href="https://www.example.com/pl/oferta/" />
<link rel="alternate" hreflang="en" href="https://www.example.com/en/offer/" />
<link rel="alternate" hreflang="de" href="https://www.example.com/de/angebot/" />

Nagłówek HTTP

Drugi sposób to nagłówek Link wysyłany przez serwer razem z plikiem. Zawiera on adresy wszystkich wersji, każdy z dopiskiem rel="alternate" i wartością hreflang, rozdzielone przecinkami. Dokumentacja wskazuje tę metodę jako przydatną dla plików innych niż HTML i podaje przykład dokumentu PDF. Producent maszyn, który udostępnia kartę katalogową w trzech językach, może w ten sposób powiązać trzy pliki. Nagłówek obejmuje również żądany plik i jest taki sam dla każdej wersji.

Link: <https://www.example.com/pl/katalog.pdf>; rel="alternate"; hreflang="pl",
      <https://www.example.com/en/catalogue.pdf>; rel="alternate"; hreflang="en",
      <https://www.example.com/de/katalog.pdf>; rel="alternate"; hreflang="de"

Mapa witryny XML

Trzeci sposób przenosi oznaczenia do mapy witryny. Mapa musi deklarować przestrzeń nazw xhtml, a każdy adres otrzymuje własny element url z elementem loc oraz elementami xhtml:link dla wszystkich wersji, łącznie z nim samym. Kolejność tych elementów nie ma znaczenia, choć stały porządek ułatwia kontrolę. Elementy xhtml:link nie wliczają się do limitu adresów w mapie, który według dokumentacji Przygotowywanie i przesyłanie mapy witryny wynosi 50 000 adresów lub 50 MB w jednym pliku. Z naszego doświadczenia rozwiązanie to jest wygodne w dużych serwisach i sklepach, bo nie powiększa kodu każdej podstrony. Podstawy opisujemy we wpisie o tym, jak przygotować mapę witryny XML.

Jeśli chcą Państwo zamówić pozycjonowanie strony, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Wzajemne odwołania i wartość x-default

Oznaczenia hreflang działają tylko wtedy, gdy są obustronne: jeżeli strona polska wskazuje na niemiecką, to niemiecka musi wskazywać na polską. Dokumentacja Google stawia sprawę jasno. Gdy dwie strony nie odwołują się do siebie nawzajem, oznaczenia zostaną zignorowane. Google wyjaśnia, że wymóg ten chroni przed sytuacją, w której ktoś na obcej witrynie samowolnie ogłasza swoją stronę alternatywną wersją cudzej.

Pełny zestaw na każdej wersji

Z zasady wzajemności wynikają dwie reguły praktyczne. Każda wersja językowa wymienia samą siebie oraz wszystkie pozostałe, a zestaw odwołań jest wszędzie taki sam. Przy trzech językach każda z trzech podstron zawiera więc trzy wpisy, a nie dwa. Adresy muszą być pełne, razem z protokołem. Zapis względny w rodzaju „/de/angebot/” ani zapis bez protokołu nie są dopuszczalne.

Do czego służy x-default

Wartość x-default oznacza stronę zastępczą, wyświetlaną wtedy, gdy żaden język ani region z zestawu nie pasuje do ustawień przeglądarki osoby szukającej. Nie wymaga kodu języka. Google wskazuje, że najlepiej sprawdza się na stronach, na których użytkownik sam wybiera język lub kraj, oraz na stronach głównych, które przekierowują automatycznie zależnie od odwiedzającego. W przykładzie z dokumentacji wpis x-default prowadzi właśnie do strony wyboru kraju.

Przykład: firma z wersją polską, angielską i niemiecką

Dla trzech wersji językowych jednej podstrony potrzebne są trzy wpisy z kodami „pl”, „en” i „de” oraz czwarty z wartością x-default, powtórzone bez zmian na każdej z trzech podstron. Przyjmijmy hipotetycznego producenta mebli biurowych spod Poznania, który sprzedaje w Polsce, w Niemczech i w pozostałych krajach Europy. Serwis ma trzy katalogi w jednej domenie, a podstrona z ofertą istnieje pod trzema adresami z przetłumaczoną końcówką. Dokumentacja Google potwierdza, że przetłumaczone adresy są dopuszczalne.

<link rel="alternate" hreflang="pl" href="https://www.example.com/pl/oferta/" />
<link rel="alternate" hreflang="en" href="https://www.example.com/en/offer/" />
<link rel="alternate" hreflang="de" href="https://www.example.com/de/angebot/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />

Warto zwrócić uwagę na trzy szczegóły. Wersja polska zawiera wpis prowadzący do niej samej, tak samo jak dwie pozostałe. Wszystkie adresy są pełne i zaczynają się od protokołu. Wpis x-default prowadzi do strony głównej domeny, na której odwiedzający wybiera język, podobnie jak w pierwszym przykładzie z dokumentacji Google. Użyliśmy samych kodów języka, bez krajów, bo firma ma po jednej wersji na język. Gdyby później powstała osobna oferta dla Austrii, doszedłby wpis „de-AT”, a wersja „de” pozostałaby wersją ogólną dla pozostałych niemieckojęzycznych odbiorców.

Ten sam przykład w mapie witryny

Te same informacje można zapisać w mapie witryny, bez zmian w szablonie strony. Każdy z trzech adresów ma wtedy własny element url, a w każdym powtarza się komplet elementów xhtml:link. Poniżej pokazujemy wpis dla wersji polskiej. Wpisy dla wersji angielskiej i niemieckiej różnią się wyłącznie zawartością elementu loc. Deklarację przestrzeni nazw xhtml w elemencie otwierającym mapę należy przepisać z przykładu w dokumentacji Google.

<url>
  <loc>https://www.example.com/pl/oferta/</loc>
  <xhtml:link rel="alternate" hreflang="pl" href="https://www.example.com/pl/oferta/" />
  <xhtml:link rel="alternate" hreflang="en" href="https://www.example.com/en/offer/" />
  <xhtml:link rel="alternate" hreflang="de" href="https://www.example.com/de/angebot/" />
</url>

Co z podstronami, które nie mają odpowiednika

Nie każda podstrona musi istnieć we wszystkich językach. Jeżeli wpis na blogu powstał tylko po polsku, otrzymuje oznaczenia wyłącznie dla tych wersji, które faktycznie istnieją, albo nie otrzymuje ich wcale. Z praktyki odradzamy kierowanie brakujących odpowiedników na stronę główną danej wersji językowej, ponieważ nie jest ona tłumaczeniem wpisu i nie odwołuje się do niego z powrotem.

Hreflang a adres kanoniczny, przekierowania i wybór języka

Hreflang i adres kanoniczny pełnią różne funkcje i muszą być ze sobą zgodne: adres kanoniczny każdej wersji językowej powinien wskazywać na tę samą wersję językową, a nie na oryginał w innym języku. Dokumentacja Jak określić kanoniczny URL za pomocą rel="canonical" i innych metod zaleca, aby przy stosowaniu hreflang określać stronę kanoniczną w tym samym języku, a gdy takiej nie ma, w najlepszym języku zastępczym.

Typowa pomyłka polega na tym, że wersje angielska i niemiecka mają adres kanoniczny ustawiony na polski oryginał. Właściciel witryny mówi wtedy wyszukiwarce dwie sprzeczne rzeczy: że niemiecka podstrona jest osobną wersją dla niemieckojęzycznych odbiorców i jednocześnie że jest kopią polskiej. Poprawnie każda wersja wskazuje jako kanoniczną samą siebie, a oznaczenia hreflang spinają je w grupę. Zasady samego znacznika omawiamy we wpisie o tym, jak wdrożyć adres kanoniczny. Ta sama dokumentacja wymienia wśród praktyk, których należy unikać, podawanie w oznaczeniach hreflang i w mapie witryny adresów w wersji HTTP zamiast HTTPS.

Automatyczne przekierowania według kraju

Google odradza automatyczne przenoszenie odwiedzających do innej wersji językowej, ponieważ może to uniemożliwić zarówno użytkownikom, jak i robotom dotarcie do wszystkich wersji. Odradza także dopasowywanie treści na podstawie adresu IP, które określa jako zawodne. Zalecanym rozwiązaniem są widoczne odnośniki do pozostałych wersji, na przykład przełącznik języka w nagłówku. Polak mieszkający w Berlinie powinien móc jednym kliknięciem przejść do polskiej oferty, nawet jeśli wyszukiwarka pokazała mu niemiecką.

Jak sprawdzić, czy oznaczenia działają

Poprawność wdrożenia sprawdza się w trzech miejscach: w kodzie źródłowym każdej wersji, w narzędziu do sprawdzania adresów URL w Search Console oraz w raporcie skuteczności z podziałem na kraje. Dokumentacja Google dotycząca wersji językowych nie opisuje osobnego raportu poświęconego hreflang, a jako pomoc w testach wymienia jedynie narzędzia zewnętrzne, zaznaczając, że Google ich nie obsługuje ani nie weryfikuje.

Kontrola kodu źródłowego

Najprostsze sprawdzenie polega na otwarciu każdej wersji podstrony w przeglądarce i wyświetleniu jej źródła. W sekcji head powinny znajdować się wszystkie wpisy z atrybutem hreflang. Zestaw porównuje się między wersjami: ma być identyczny, zawierać wpis prowadzący do bieżącej strony, a każdy adres ma zaczynać się od protokołu. Następnie każdy adres z zestawu warto otworzyć i upewnić się, że ładuje właściwą podstronę we właściwym języku. Przy wdrożeniu przez mapę witryny tę samą kontrolę wykonuje się w pliku mapy.

Narzędzie do sprawdzania adresów URL

W Search Console adres podstrony wpisuje się w pole wyszukiwania u góry ekranu. Po chwili pojawia się wynik z sekcją „Indeksowanie stron”. Według strony pomocy Narzędzie do sprawdzania adresów URL znajdują się tam między innymi pola „Adres kanoniczny określony przez użytkownika” i „Adres kanoniczny wybrany przez Google”. Dla wersji językowych to najważniejsza para informacji. Jeżeli przy niemieckiej podstronie Google jako adres kanoniczny wybrał polski oryginał, oznacza to, że uznał obie strony za kopie. Powodem bywa nieprzetłumaczona treść główna albo błędnie ustawiony znacznik kanoniczny.

To samo narzędzie pozwala obejrzeć kod HTML, który Google faktycznie pobrał. Służy do tego opcja wyświetlenia zindeksowanej strony, a po uruchomieniu testu wersji opublikowanej także opcja wyświetlenia przetestowanej strony. W pobranym kodzie można odszukać wpisy hreflang i potwierdzić, że robot je otrzymuje. Obsługę całego narzędzia opisujemy we wpisie o sprawdzaniu adresu URL w Search Console.

Raport skuteczności z podziałem na kraje

Ostatecznym sprawdzianem jest to, które adresy Google pokazuje w poszczególnych krajach. W raporcie „Skuteczność” nad tabelą znajdują się karty wymiarów, które strona pomocy Raport skuteczności (wyniki wyszukiwania): omówienie i podstawowa konfiguracja wymienia jako Zapytania, Strony, Kraje, Urządzenia, Wygląd w wyszukiwarce i Daty. Karta „Kraje” pokazuje, skąd pochodzą wyświetlenia i kliknięcia, a karta „Strony”, które adresy je zbierają. Po zawężeniu danych do Niemiec na karcie „Strony” powinny przeważać adresy z katalogu niemieckiego. Jeżeli dominują tam adresy polskie, warto wrócić do kontroli oznaczeń i stanu indeksowania wersji niemieckiej. Z naszych obserwacji wynika, że na efekt trzeba poczekać, aż robot ponownie odwiedzi wszystkie powiązane wersje. Więcej o tym raporcie piszemy we wpisie o tym, jak czytać raport Skuteczność.

Typowe pomyłki przy hreflang i sytuacje, w których potrzebna jest pomoc

Większość nieudanych wdrożeń wynika z trzech przyczyn nazwanych w dokumentacji Google: braku odwołań zwrotnych, nieprawidłowych kodów języka oraz nieprawidłowych kodów regionu. Do tego dochodzą błędy, które widujemy w praktyce: adresy względne, adresy w wersji HTTP w serwisie działającym już na HTTPS, odwołania do podstron usuniętych lub przekierowanych, znacznik kanoniczny wszystkich wersji ustawiony na jeden język oraz wiązanie podstron, które nie są swoimi tłumaczeniami.

Osobną kategorią są oczekiwania. Hreflang nie naprawi niedbałego tłumaczenia i nie zastąpi treści dopasowanych do rynku. Google podaje, że przy ustalaniu docelowych odbiorców bierze pod uwagę także inne sygnały, w tym domenę krajową, lokalne adresy i numery telefonów, język i walutę oraz linki z lokalnych witryn.

• Każda wersja językowa ma własny, stały adres URL i przetłumaczoną treść główną.
• Kody języka są zgodne ze standardem ISO 639-1, a kody kraju ze standardem ISO 3166-1 alfa-2.
• Żaden wpis nie zawiera samego kodu kraju ani kodów zarezerwowanych, takich jak UK lub EU.
• Zestaw oznaczeń jest identyczny na wszystkich wersjach i obejmuje stronę bieżącą.
• Wszystkie adresy są pełne, w wersji HTTPS, i prowadzą do działających podstron.
• Adres kanoniczny każdej wersji wskazuje na tę samą wersję językową.
• Oznaczenia wdrożono jedną metodą w całym serwisie.
• Na stronie jest widoczny przełącznik języka, a serwis nie przenosi odwiedzających automatycznie.

Kiedy warto zlecić wdrożenie

Niewielką stronę firmową w dwóch lub trzech językach da się oznaczyć samodzielnie, a zadanie sprowadza się wtedy głównie do kontroli opisanej wyżej. Pomoc specjalisty jest potrzebna w bardziej złożonych sytuacjach: w sklepie z tysiącami produktów, z których część nie jest dostępna na wszystkich rynkach, przy kilku wariantach krajowych jednego języka, przy wersjach rozłożonych na osobne domeny oraz przy łączeniu lub przenoszeniu serwisów.

Kontrola wersji językowych jest stałym elementem prac, które obejmuje SEO techniczne, a przegląd istniejącego wdrożenia najlepiej zacząć od tego, co wykazuje audyt SEO. Jeżeli wersje językowe mają dopiero powstać, układ adresów i sposób oznaczania warto ustalić jeszcze na etapie projektu, co uwzględniamy przy tworzeniu stron dla firm działających na kilku rynkach.

Jeśli chcą Państwo zamówić pozycjonowanie strony, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl