Co hreflang robi, a czego nie

Hreflang jest sygnałem dla wyszukiwarki, że dwa lub więcej adresów to warianty językowe albo regionalne tej samej treści. Google używa go, żeby w wynikach pokazać użytkownikowi wariant dopasowany do jego języka i lokalizacji.

Trzy rzeczy, których nie robi.

Nie jest to dyrektywa przekierowująca. Nie zabiera użytkownika na inną wersję strony, tylko wpływa na to, który adres pojawi się w wynikach.

Nie jest to rozwiązanie problemu duplikacji w sensie kanonicznym. Wersje językowe nie są duplikatami, więc nie potrzebują wskazywania jednej wersji nadrzędnej. To ważne, bo najczęstsza katastrofa w takich wdrożeniach polega właśnie na tym, że wszystkie wersje mają adres kanoniczny prowadzący do wersji angielskiej. Wtedy hreflang nie ma znaczenia, bo Google i tak indeksuje tylko jedną wersję.

Nie jest to też gwarancja. Google traktuje hreflang jako mocną wskazówkę, ale zastrzega sobie prawo pokazania innej wersji, jeśli uzna to za lepsze dla użytkownika.

Trzy zasady, bez których to nie działa

Jeśli miałbym sprowadzić całe wdrożenie do trzech reguł, byłyby to te.

Wzajemność. Każda wersja musi wskazywać wszystkie pozostałe oraz samą siebie. Jeśli wersja polska wskazuje niemiecką, ale niemiecka nie odwzajemnia się wskazaniem na polską, Google odrzuca całą deklarację jako niespójną. To najczęstsza przyczyna niedziałających wdrożeń i najłatwiejsza do przeoczenia, bo błąd jest w innym pliku niż ten, który się sprawdza.

Adresy pełne i kanoniczne. W deklaracjach podaje się adresy absolutne, z protokołem, i to dokładnie te adresy, które są kanoniczne. Wskazanie na adres, który przekierowuje albo ma canonical prowadzący gdzie indziej, jest błędem.

Zgodność z adresem kanonicznym. Każda wersja ma własny canonical wskazujący na siebie. Nie na wersję główną, nie na wersję angielską — na siebie. To zdanie warto przeczytać dwa razy, bo pomyłka w tym miejscu jest najbardziej kosztowna z możliwych.

Kody języków i regionów

Składnia wartości atrybutu jest źródłem drugiej połowy pomyłek.

Kod składa się z języka i opcjonalnie regionu. Sam język jest poprawny i często wystarczający: wskazanie wersji polskiej bez określania kraju obejmuje wszystkich użytkowników mówiących po polsku. Region dodaje się tylko wtedy, gdy naprawdę masz osobne wersje dla różnych krajów mówiących tym samym językiem — na przykład niemiecką dla Niemiec i osobną dla Austrii z innymi cenami i kosztami dostawy.

Najczęstsze pomyłki w kodach:

• Region bez języka — nie ma takiego wariantu, kod musi zaczynać się od języka.

• Wymyślone kody typu oznaczenie dla Wielkiej Brytanii wzięte z domeny zamiast z normy. Domena i kod kraju to dwie różne rzeczy i w kilku przypadkach się różnią.

• Kod języka użyty jako kod kraju, na przykład przy Czechach albo Szwecji, gdzie oznaczenia języka i państwa nie są identyczne.

• Kierowanie na kontynent albo region gospodarczy — poza jednym wyjątkiem obsługiwane są tylko kraje.

Osobno wart uwagi jest wariant domyślny. Wskazuje wersję, która ma być pokazana użytkownikom, dla których nie zdefiniowano dopasowania — na przykład osobie z Brazylii przy serwisie z wersją polską, niemiecką i angielską. Bez tego Google wybierze sam i nie zawsze tak, jak byś chciał. Warto ją zdefiniować i wskazać wersję najbardziej uniwersalną, zwykle angielską.

Trzy sposoby wdrożenia i kiedy który wybrać

Deklaracje można umieścić w trzech miejscach i wybór ma praktyczne konsekwencje.

W nagłówku dokumentu HTML. Najprostsze w implementacji i najłatwiejsze do sprawdzenia w przeglądarce. Wada: przy wielu wersjach każda strona nabiera wagi, a przy dwudziestu językach to dwudziestu odnośników na każdej podstronie. Dla większości serwisów, które prowadzę, to i tak najlepszy wybór.

W nagłówkach odpowiedzi HTTP. Jedyna opcja dla plików, które nie są dokumentami HTML — na przykład katalogów w PDF. Trudniejsze w diagnozie, bo nie widać tego w kodzie strony.

W mapie witryny XML. Najbardziej wydajne przy dużych serwisach z wieloma wersjami i moim zdaniem najbardziej niedocenione. Nie obciąża stron, a całą konfigurację trzymasz w jednym miejscu, co paradoksalnie ułatwia utrzymanie wzajemności. Wada: mapa musi być generowana automatycznie, bo ręczne utrzymywanie takiej struktury jest nierealne.

Czego nie robię nigdy: nie mieszam metod. Deklaracje w kodzie strony i jednocześnie w mapie witryny to prosta droga do sprzeczności, których nikt później nie rozplecie.

Struktura adresów jako decyzja poprzedzająca hreflang

Zanim dojdzie do znaczników, trzeba zdecydować, gdzie wersje językowe będą mieszkać. Ta decyzja jest trudniejsza do odwrócenia niż cokolwiek innego w tym temacie.

Osobne domeny krajowe dają najmocniejszy sygnał geograficzny i pełne rozdzielenie, ale każda domena buduje autorytet od zera i wymaga osobnej pracy nad linkami. Wybieram to rozwiązanie, gdy firma ma osobne spółki i osobne zespoły w każdym kraju.

Katalogi w jednej domenie to opcja, którą polecam najczęściej. Cała siła domeny pracuje dla wszystkich wersji, utrzymanie jest najprostsze, a przy pomocy hreflang i ustawień kierowania w Search Console można wystarczająco jasno zakomunikować przeznaczenie każdej sekcji.

Subdomeny leżą pośrodku i w praktyce łączą wady obu podejść. Zdarza się, że są wymuszone architekturą systemu — wtedy da się z nimi żyć, ale nie wybrałbym ich z własnej woli.

Osobno przestrzegam przed rozwiązaniem, które wraca regularnie: automatycznym przekierowywaniem po adresie IP. Jeśli robot Google, pobierający strony z określonych lokalizacji, zostanie przekierowany, zobaczy tylko jedną wersję i pozostałych nie zaindeksuje. Sugerowanie wersji owszem, wymuszanie nie.

Weryfikacja po wdrożeniu

Wdrożenie bez sprawdzenia traktuję jako niezakończone, bo tu naprawdę nie widać, że coś nie działa.

Pierwszy krok to crawler przechodzący po wszystkich wersjach i zestawiający deklaracje w tabelę. Szukam trzech rzeczy: brakujących odnośników zwrotnych, adresów wskazanych w deklaracjach, które odpowiadają przekierowaniem lub błędem, oraz stron wskazujących na siebie niepoprawnym kodem.

Drugi to Search Console i raport kierowania międzynarodowego, jeśli jest dostępny dla serwisu. Pokazuje błędy wzajemności i nieznane kody języków — dokładnie te dwie kategorie, które psują najwięcej.

Trzeci, najbardziej praktyczny: sprawdzam, co faktycznie pokazuje się w wynikach dla zapytań w różnych językach. Jeśli w niemieckich wynikach pojawia się wersja angielska, wdrożenie nie działa niezależnie od tego, co mówią narzędzia.

I uwaga na koniec, wynikająca z doświadczenia: hreflang psuje się przy każdej większej zmianie w serwisie. Dodanie nowego języka, zmiana struktury adresów, migracja — za każdym razem wracam do tej samej weryfikacji. Wdrożenie sprzed roku nie jest dowodem na to, że dziś jest poprawne.