Każdy językowy URL powinien wskazywać na siebie oraz na wszystkie równoważne alternatywy za pomocą prawidłowych kodów; musi mieć własny canonical, zwrotne odnośniki hreflang oraz poprawny, indeksowalny status.
Hreflang pomaga wyszukiwarce przypisać równoważne wersje językowe lub regionalne strony do właściwych odbiorców. Nie jest to polecenie tłumaczenia ani zamiennik dobrej lokalizacji. Każda wersja musi być samodzielnie dostępna, indeksowalna i pod względem treści realizować to samo zadanie, choć tekst, waluta czy dane kontaktowe mogą się różnić w zależności od regionu.
Najczęstsze błędy wynikają z niekompletnych klastrów, nieprawidłowych kodów, brakujących linków zwrotnych i konfliktu z canonical. Implementacja może znajdować się w HTML, nagłówku HTTP lub mapie witryny XML. Wybierz jedno utrzymywalne źródło prawdy i generuj znaczniki z danych, a nie przez ręczne kopiowanie dziesiątek adresów.
Najpierw zaprojektuj adresy URL językowe i regionalne
Proszę zdecydować, czy używają Państwo oddzielnych domen, subdomen czy podkatalogów, i konsekwentnie przestrzegać tej zasady. Każda wersja ma stabilny URL bez obowiązkowego pliku cookie czy automatycznego przekierowania według IP. Użytkownik musi móc zmienić język, a udostępniony link powinien otwierać wybraną wersję.
Odróżniaj język od regionu. Wersja słowacka może używać kodu języka, natomiast angielska dla konkretnego rynku może dodać obsługiwany region. Nie wymyślaj marketingowych skrótów i nie używaj kodu państwa jako języka. Jeśli ten sam język obsługuje kilka rynków bez istotnych różnic, rozważ jedną wspólną wersję.
Pełny klaster i linki zwrotne
Strona w każdym klastrze hreflang wskazuje samą siebie oraz wszystkie równorzędne alternatywy. Odwołania muszą być wzajemne. Jeśli wersja słowacka odsyła do angielskiej, angielska musi odsyłać z powrotem do słowackiej i zawierać tę samą listę. Brak lub błąd w jednym adresie może osłabić wiarygodność całego klastra.
Łączcie strony w pary według ich celu, a nie tylko podobnej nazwy. Słowacka strona szczegółów usługi nie powinna wskazywać na ogólną angielską stronę główną, jeśli równoważne tłumaczenie nie istnieje. W takim przypadku lepiej nie podawać alternatywy. x-default może oznaczać neutralną stronę wyboru lub wersję domyślną, ale nie zastępuje standardowych oznaczeń językowych.
- prawidłowe kody języków i opcjonalne kody regionów
- samoodnośnik oraz wszystkie równorzędne alternatywy
- wzajemne odnośniki w każdej wersji
- brak mapowania podstrony szczegółowej na niepowiązaną stronę główną
Canonical i indeksowalność każdej wersji
Każda zlokalizowana strona ma zazwyczaj canonical wskazujący na siebie. Jeśli wszystkie wersje językowe zostaną skanonizowane do jednej, powstaje konflikt: hreflang twierdzi, że są to alternatywy, a canonical, że preferowana jest tylko jedna treść. Alternatywy muszą zwracać kod 200, nie mogą mieć noindex ani być blokowane i muszą mieć dostępne zasoby potrzebne do renderowania.
Przekierowanie na podstawie języka przeglądarki należy stosować ostrożnie i pozostawić możliwość pozostania pod wybranym adresem URL. Robot i użytkownik z innego kraju muszą móc wczytać każdą wersję bezpośrednio. Po usunięciu lokalizacji należy zaktualizować klaster hreflang, zanim stary adres zostanie przekierowany lub usunięty.
HTML, nagłówki lub XML sitemap
Element HTML link jest przejrzysty dla zwykłych stron, nagłówki HTTP sprawdzają się w przypadku plików innych niż HTML, a mapa witryny XML pozwala łatwiej zarządzać dużą liczbą alternatyw. Nie wdrażajcie wszystkich trzech metod bez powodu; zwiększacie liczbę miejsc, w których mogą pojawić się rozbieżności. Wybierzcie sposób, który Wasz CMS potrafi generować spójnie.
W mapie witryny podaj każdy kanoniczny, indeksowalny adres URL oraz jego pełne alternatywy zgodnie z prawidłową składnią. Generator powinien opierać się na tabeli powiązań lub wspólnym identyfikatorze treści. Ręczne przypisywanie na podstawie podobnego sluga zawodzi przy zlokalizowanych nazwach i stronach dostępnych tylko w niektórych językach.
Audyt przed migracją i po niej
Przed zmianą URL należy wyeksportować istniejące klastry i utworzyć mapę starych i nowych adresów dla każdego języka. Na stagingu należy zweryfikować kody, linki zwrotne, canonical i kody statusu. Przekierowania muszą prowadzić do odpowiadającej treści w danym języku, a nie wszystkie do jednej globalnej strony.
Po wdrożeniu sprawdzaj za pomocą crawla niekompletne klastry, linki do przekierowań, błędy i konflikty kanoniczne. Monitoruj strony docelowe według kraju i języka, pamiętając, że personalizacja wyników się zmienia. Hreflang nie gwarantuje pozycji ani natychmiastowego wyświetlania właściwej wersji; pomaga wyszukiwarce zrozumieć utrzymywane powiązania.
- prawidłowy kod języka i opcjonalny kod regionu
- autoodnośnik i linki zwrotne w każdym klastrze
- równorzędne strony sparowane według celu
- self-canonical na każdej indeksowalnej alternatywie
- brak alternatyw wskazujących na błąd lub przekierowanie
- spójna implementacja w jednym wybranym kanale
- x-default tylko dla naprawdę neutralnego wyboru
- ponowny crawl po każdej większej migracji językowej
- monitorowanie danych wejściowych według języka, kraju i docelowego URL
- kontrola po zmianie systemu lokalizacji
Najczęstsze pytania
Czy hreflang jest potrzebny na każdej wielojęzycznej stronie?
Jest przydatny, gdy istnieją równoważne adresy URL w różnych wersjach językowych lub regionalnych. Jeśli mają Państwo tylko jedną stronę z przełączanym tekstem bez osobnych adresów, najpierw należy poprawić architekturę URL.
Czy wersja angielska ma canonical wskazujący na słowacką?
Zazwyczaj nie. Każda indeksowalna wersja językowa ma canonical wskazujący na siebie, a relację między nimi wyraża hreflang.
Co zrobić, jeśli strona nie ma tłumaczenia?
Nie podawaj niepowiązanej alternatywy. Pozostaw dostępne języki w pełnym, wzajemnym klastrze i zaoferuj użytkownikowi zrozumiałą nawigację językową.