Jak wdrożyć atrybut hreflang

6 września, 2023
CMspace
SEO
0 Comments

Użytkownik z Niemiec klika wynik w Google i trafia na polską wersję strony. Klient z Wielkiej Brytanii widzi ceny dla USA. Hiszpan dostaje wersję angielską, chociaż istnieje gotowa podstrona po hiszpańsku. To nie jest problem tłumaczenia, tylko sygnałów technicznych. Atrybut hreflang nie podnosi magicznie pozycji, ale pomaga Google zrozumieć, która wersja adresu URL jest przeznaczona dla konkretnego języka lub regionu. Jeśli zostanie wdrożony źle, wyszukiwarka może go po prostu zignorować.

Kiedy hreflang ma sens, a kiedy tylko komplikuje SEO

Hreflang warto wdrażać wtedy, gdy jedna treść istnieje w kilku wersjach językowych lub regionalnych. Nie chodzi tylko o klasyczne tłumaczenia. Ten atrybut przydaje się także wtedy, gdy strony są bardzo podobne, ale różnią się walutą, dostawą, ofertą, regulaminem albo sposobem kontaktu.

Najczęstsze sytuacje, w których hreflang jest potrzebny:

sklep ma osobne adresy dla Polski, Niemiec i Czech;
strona ma wersję en-us i en-gb, bo różnią się cenami, pisownią lub warunkami sprzedaży;
serwis ma wersję ogólną po angielsku oraz lokalne wersje dla konkretnych rynków;
firma prowadzi osobne domeny, np. .pl, .de, .fr, ale publikuje odpowiedniki tych samych podstron.

Granica jest prosta: hreflang ma sens tylko wtedy, gdy istnieją konkretne alternatywne adresy URL. Jeśli jedna podstrona dynamicznie zmienia język na podstawie ciasteczek, lokalizacji IP albo ustawień przeglądarki, wdrożenie robi się ryzykowne. Google zaleca osobne adresy dla różnych wersji językowych, bo bot nie zawsze zobaczy warianty generowane dynamicznie. W praktyce oznacza to, że /pl/oferta/, /de/angebot/ i /en/offer/ są łatwiejsze do kontrolowania niż jedna podstrona, która sama przełącza treść.

Nie wdrażałbym hreflang na siłę, gdy:

strona ma tylko jedną wersję językową;
tłumaczone są wyłącznie drobne elementy szablonu, a główna treść zostaje taka sama;
wersje językowe są niepełne, robione automatycznie i nie mają realnej wartości dla użytkownika;
adresy URL nie są jeszcze ustabilizowane po migracji.

Najpierw trzeba uporządkować strukturę adresów URL, indeksację i canonicale. Dopiero potem ma sens dokładanie hreflang. Odwrotna kolejność często kończy się chaosem: w kodzie są znaczniki, ale Google nie traktuje ich poważnie, bo część adresów przekierowuje, część ma noindex, a część wskazuje canonical na inną wersję językową.

Trzy metody wdrożenia hreflang: HTML, nagłówki HTTP i mapa XML

Google obsługuje trzy metody wdrożenia hreflang: znaczniki w sekcji <head>, nagłówki HTTP oraz mapę XML. Z punktu widzenia Google są równoważne. W praktyce nie wybiera się tej „najmocniejszej”, tylko tę, którą da się utrzymać bez błędów.

Najważniejsza zasada: nie mieszaj metod bez potrzeby. Da się używać kilku naraz, ale zwykle nie daje to korzyści, za to zwiększa ryzyko rozjazdów. Jeśli tagi w HTML mówią jedno, a mapa XML drugie, audyt robi się nieprzyjemny, a naprawa trwa dłużej niż samo wdrożenie.

Najczęściej wybór wygląda tak:

HTML w sekcji <head> — dobry wybór dla małych i średnich serwisów, gdzie CMS pozwala łatwo edytować szablon strony.
Mapa XML — najlepsza dla dużych serwisów, sklepów i portali, gdzie komplet wariantów łatwiej generować centralnie.
Nagłówki HTTP — przydatne głównie dla plików innych niż HTML, na przykład PDF-ów.

Przykład wdrożenia w HTML dla strony z trzema wersjami:

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

Ten sam zestaw powinien znaleźć się na każdej wersji strony. Polska wersja wskazuje siebie, wersję angielską, niemiecką i wariant domyślny. Angielska robi dokładnie to samo. Niemiecka również. To nazywa się wzajemne linkowanie hreflang i jest jednym z najczęstszych miejsc, w których wdrożenie się wykłada.

Druga zasada: każdy adres musi być pełny. Nie /pl/oferta/, nie //example.com/pl/oferta/, tylko pełny URL z protokołem:

https://example.com/pl/oferta/

Trzecia zasada: kod języka i regionu musi być poprawny. Sam język zapisuje się jako pl, de, en. Wariant regionalny jako połączenie języka i kraju, na przykład en-gb, en-us, de-at. Nie stosuje się samego kraju, więc gb albo de jako oznaczenie regionu bez języka to błąd koncepcyjny.

Wariant x-default warto dodać wtedy, gdy istnieje strona domyślna: selektor kraju, globalna strona startowa albo wersja, którą chcesz pokazać użytkownikom niedopasowanym do żadnego języka. Nie trzeba go wciskać wszędzie. Jeśli serwis ma tylko dwie precyzyjne wersje językowe i żadnej sensownej strony domyślnej, lepiej nie udawać, że taka strona istnieje.

Przy dużym serwisie wygodniejsza bywa mapa XML. Dla każdej wersji adresu dodaje się komplet alternatyw, również odwołanie do samej siebie. Dla trzech wersji językowych oznacza to trzy wpisy URL, a w każdym trzy takie same odwołania alternatywne. To brzmi nadmiarowo, ale właśnie tej kompletności oczekuje Google.

Najczęstsze błędy, które psują wdrożenie hreflang

Najgorszy błąd to wdrożenie hreflang przed uporządkowaniem indeksacji. Hreflang nie naprawia canonicali, przekierowań ani zablokowanych podstron. Jeśli adres ma noindex, zwraca błąd 404, przekierowuje na inną wersję albo wskazuje canonical na inny język, cały zestaw sygnałów staje się podejrzany.

Priorytet napraw powinien być taki:

sprawdź, czy wszystkie adresy zwracają kod 200;
upewnij się, że nie są zablokowane przez robots.txt ani noindex;
ustaw canonical na wersję w tym samym języku lub najbliższy poprawny odpowiednik;
dopiero potem dodaj hreflang;
na końcu przetestuj wzajemność linkowania.

W praktyce często trafia się taki problem: polska strona /pl/buty/ ma hreflang do niemieckiej /de/schuhe/, ale niemiecka nie wskazuje z powrotem na polską. Dla Google to nie jest pełna relacja. Takie jednostronne oznaczenia mogą zostać zignorowane. To zabezpieczenie przed sytuacją, w której obca strona mogłaby wskazać siebie jako alternatywną wersję Twojej podstrony.

Drugi częsty błąd to wskazywanie adresów niekanonicznych. Przykład: w hreflang pojawia się http://example.com/en/offer/, ale canonical i finalny adres działają pod https://example.com/en/offer/. To drobiazg tylko na papierze. W realnym audycie oznacza konflikt sygnałów. Do hreflang powinny trafiać adresy kanoniczne, indeksowalne i końcowe, a nie wersje z przekierowaniami.

Trzeci błąd to automatyczne przekierowania użytkownika na podstawie IP bez zostawienia wyboru. Jeśli użytkownik z Polski nie może wejść na wersję niemiecką, bo system natychmiast przerzuca go na /pl/, bot też może mieć problem z dotarciem do wariantów. Lepszy model to delikatna sugestia: baner, link do zmiany kraju, widoczny selektor języka. Użytkownik ma wybór, a Google ma dostęp.

Czwarty błąd: tworzenie wersji regionalnych bez realnych różnic. Jeśli en-us, en-gb i en-au mają identyczną treść, identyczne ceny, identyczne warunki dostawy i żadnych lokalnych elementów, trzeba zadać niewygodne pytanie: po co istnieją trzy adresy? Czasem lepsza będzie jedna wersja en, uzupełniona o warianty regionalne dopiero wtedy, gdy różnice są istotne biznesowo.

Przed publikacją wdrożenia sprawdziłbym minimum:

czy każda wersja strony ma komplet alternatyw;
czy każda wersja wskazuje samą siebie;
czy wszystkie adresy są pełne i działają pod HTTPS;
czy canonical nie przeczy hreflang;
czy mapa XML nie zawiera starych adresów po migracji;
czy wersje językowe mają widoczną treść w danym języku, a nie tylko przetłumaczone menu.

Na końcu trzeba zajrzeć do Google Search Console i logów serwera. Samo „tagi są w kodzie” nie wystarcza. Liczy się to, czy Google może wejść na każdy adres, zobaczyć właściwą treść i potwierdzić relacje między wersjami.

FAQ: najczęstsze pytania o wdrożenie hreflang

Czy hreflang poprawia pozycje w Google?
Nie bezpośrednio. Hreflang pomaga Google pokazać właściwą wersję językową lub regionalną. Może ograniczyć problemy z błędnym dopasowaniem wyników, ale nie zastąpi jakości treści, linkowania, technicznej indeksacji ani lokalnej optymalizacji.

Czy trzeba dodawać hreflang na każdej podstronie?
Trzeba dodać go tam, gdzie istnieją rzeczywiste odpowiedniki językowe lub regionalne. Jeśli dana podstrona ma tylko wersję polską, nie twórz sztucznego zestawu. Lepiej wdrożyć mniej adresów, ale poprawnie.

Czy każda wersja musi wskazywać samą siebie?
Tak. Każdy zestaw powinien zawierać self-referencing hreflang, czyli odwołanie do własnego adresu oraz do pozostałych wersji. Brak samoodwołania to częsty sygnał niedokończonego wdrożenia.

Czy można użyć jednocześnie HTML i mapy XML?
Można, ale zwykle nie ma takiej potrzeby. Jeśli oba źródła nie są generowane z tego samego systemu, łatwo o sprzeczności. W większości projektów wybór jednej metody jest bezpieczniejszy.

Co wybrać: pl, pl-pl czy pl_PL?
Dla języka polskiego najczęściej wystarczy pl. Wariant regionalny zapisuje się z myślnikiem, na przykład en-gb, a nie z podkreślnikiem. Sam kod kraju bez języka nie jest poprawnym oznaczeniem hreflang.

Czy x-default jest obowiązkowy?
Nie. x-default jest przydatny, gdy masz stronę domyślną, selektor kraju albo globalną wersję dla użytkowników niedopasowanych do żadnego wariantu. Jeśli nie masz takiej strony, nie dodawaj fikcyjnego adresu tylko po to, żeby „odhaczyć” wdrożenie.

Od czego zacząć wdrożenie hreflang?
Najpierw zrób tabelę adresów: jedna kolumna dla wersji bazowej, kolejne dla języków i regionów. Usuń z niej adresy z przekierowaniami, błędami 404, noindex i nieprawidłowym canonicalem. Dopiero z takiej tabeli generuj tagi lub mapę XML. Najpierw porządek w URL-ach, potem znaczniki.

CMspace

CMspace to wydawca portali i blogów. Oferujemy publikacje w dobrze przygotowanych, zadbanych lokalizacjach w oparciu o wysokiej jakości treści. Dostarczamy linki z artykułów sponsorowanych w wielotematycznych i tematycznych serwisach przy zachowaniu atrakcyjnych cen publikacji. [ Gravatar ]