Hreflang to atrybut HTML, który mówi wyszukiwarkom, którą wersję językową i regionalną strony pokazać użytkownikowi. Decyduje o tym język przeglądarki i lokalizacja odbiorcy. Atrybut zapobiega konkurowaniu ze sobą podobnych podstron w różnych językach i pilnuje, żeby użytkownik trafił na treść, którą rozumie. Jeżeli prowadzisz serwis wielojęzyczny albo obsługujesz kilka rynków, hreflang jest jednym z niewielu narzędzi, którymi realnie sterujesz tym, co Google pokaże na którym rynku.
Czym jest atrybut hreflang i dlaczego ma znaczenie w SEO międzynarodowym?
Hreflang to element techniczny w kodzie strony, który wskazuje język i grupę geograficzną odbiorców danej podstrony. Wyszukiwarki wykorzystują tę informację, żeby pokazać właściwą wersję treści osobie szukającej w innym języku lub z innego kraju.
Można o tym myśleć jak o wskazówce dla robota wyszukiwarki. Kiedy ktoś w Hiszpanii szuka Twojej treści, hreflang podpowiada Google, że powinien pokazać wersję hiszpańską, nie angielską. Bez tego wyszukiwarka wybiera sama, a jej wybór nie musi się pokrywać z Twoim.
Atrybut rozwiązuje dwa problemy jednocześnie.
Pierwszy dotyczy odbiorcy. Użytkownik ma trafić na treść, którą przeczyta i wykorzysta. Kliknięcie w wynik wyszukiwania i wylądowanie na stronie w nieznanym języku kończy się powrotem do wyników. Drugi problem jest techniczny. Bez hreflang wyszukiwarka może potraktować Twoje wersje angielską, hiszpańską i francuską jako duplikaty treści (duplicate content), które rywalizują o tę samą pozycję.
Dla serwisów obsługujących kilka rynków ma to bezpośredni wymiar biznesowy. Odbiorca z Wielkiej Brytanii ma zobaczyć ceny w funtach i lokalne warunki regulacyjne. Odbiorca z Niemiec potrzebuje cen w euro i niemieckiej dokumentacji. Hreflang pilnuje, żeby każdy dostał wersję, która ma dla niego sens. Platformy iGaming działające na kilku rynkach to podręcznikowy przykład — zobacz SEO w iGaming: jak zwiększyć ruch organiczny.
Warto od razu ustawić oczekiwania. Hreflang jest sygnałem, nie poleceniem. Google traktuje go jako silną wskazówkę, ale zestawia z innymi sygnałami: strukturą adresów, treścią strony, historią indeksowania. Poprawne wdrożenie zwiększa prawdopodobieństwo właściwego dopasowania, nie daje gwarancji.
Kiedy hreflang jest naprawdę potrzebny na stronie?
Hreflang jest potrzebny wtedy, gdy ten sam serwis udostępnia treść w kilku językach albo kieruje tę samą treść językową do różnych regionów. Przykładem drugiego przypadku są osobne podstrony dla angielskiego brytyjskiego i amerykańskiego albo hiszpańskiego dla Hiszpanii i Meksyku.
Sytuacje, które wymagają hreflang:
- Kilka wersji językowych tej samej treści – podstrony polska, niemiecka i angielska omawiające ten sam temat
- Warianty regionalne w jednym języku –
en-GBdla Wielkiej Brytanii,en-USdla Stanów,de-ATdla Austrii - Serwisy przetłumaczone częściowo, w których część treści istnieje w kilku językach, a część tylko w jednym
- Osobne domeny lub subdomeny dla poszczególnych rynków, na przykład
example.pl,example.de,example.com. To, jak takie osobne domeny są faktycznie hostowane, to osobna decyzja architektoniczna — zobacz czy kilka stron WordPress może korzystać z jednej bazy danych.
Hreflang nie jest potrzebny, jeżeli serwis istnieje w jednym języku i obsługuje jeden rynek. Polska strona kierowana wyłącznie do polskich odbiorców nic nie zyska. Nie pomoże też tam, gdzie tłumaczenie odbywa się automatycznie po stronie przeglądarki i nie powstają osobne adresy URL. Bez odrębnych adresów nie ma czego oznaczać.
Jak działa hreflang w WordPressie?
Znaczniki hreflang działają jako adnotacje, które opisują relacje między wersjami tej samej podstrony. WordPress nie generuje ich samodzielnie, więc trzeba je dodać wtyczką, własnym kodem albo rozwiązaniem przygotowanym przez zespół developerski.
Atrybut można umieścić w trzech miejscach:
- W sekcji
<head>dokumentu HTML, przy użyciu elementów<link>– metoda najczęściej stosowana - W nagłówkach HTTP – dla plików nie-HTML, na przykład PDF
- W mapie witryny XML – alternatywa dla znaczników na stronie
Relacja między hreflang a funkcjami językowymi samego WordPressa bywa źródłem nieporozumień. WordPress ma wbudowaną lokalizację, która tłumaczy panel administracyjny i pozwala prowadzić treści wielojęzyczne. To jednak nie tworzy znaczników hreflang. Ustawienie języka mówi WordPressowi, w jakim języku jest treść. Hreflang mówi wyszukiwarce, jak ta treść odnosi się do pozostałych wersji. To dwie osobne warstwy.
W praktyce najczęściej korzysta się z wtyczek wielojęzycznych, takich jak WPML lub Polylang, które zarządzają tłumaczeniami i generują znaczniki. Część wtyczek SEO, na przykład Yoast SEO Premium, obsługuje hreflang samodzielnie, co ma sens przy wariantach regionalnych w jednym języku. W bardziej złożonych architekturach sprawdza się rozwiązanie własne, które daje pełną kontrolę nad tym, kiedy i jakie znaczniki się pojawiają.
Jak wygląda poprawna składnia hreflang?
Poprawna składnia ma postać hreflang="język-REGION". Język zapisujemy kodem ISO 639-1, opcjonalny region kodem ISO 3166-1 Alpha 2. Kod języka zawsze małymi literami, kod kraju zawsze wielkimi, rozdzielone łącznikiem.
Najczęstsze warianty:
- Tylko język:
hreflang="pl"obejmuje wszystkich odbiorców polskojęzycznych, niezależnie od kraju - Język i region:
hreflang="en-GB"obejmuje odbiorców angielskojęzycznych w Wielkiej Brytanii - Ten sam język, różne regiony:
hreflang="es-ES"dla Hiszpanii,hreflang="es-MX"dla Meksyku - Wersja domyślna:
hreflang="x-default"wskazuje stronę pokazywaną wtedy, gdy żadna inna wersja nie pasuje
Pełne wdrożenie w kodzie HTML wygląda tak:
<link rel="alternate" hreflang="pl" href="https://example.com/pl/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/" />
<link rel="alternate" hreflang="de-DE" href="https://example.com/de/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />Typowe błędy składniowe to nieprawidłowe kody języka (eng zamiast en), brak znacznika autoreferencyjnego, czyli wskazującego na samą siebie, oraz odwrócona kolejność kodu języka i kraju. Każdy adres wskazany w znacznikach musi istnieć i zwracać kod odpowiedzi 200, nie przekierowanie i nie błąd.
Atrybut x-default zasługuje na osobną uwagę. Działa jak wersja domyślna dla odbiorców, których język i lokalizacja nie pasują do żadnego zadeklarowanego wariantu. W serwisach o zasięgu globalnym wskazuje zwykle wersję angielską albo stronę z wyborem języka.
Najczęstsze błędy w hreflang i jak ich uniknąć
Brak znaczników zwrotnych jest najczęstszym błędem we wdrożeniach hreflang. Jeżeli polska podstrona wskazuje niemiecką, niemiecka musi wskazywać polską. Relacja jest obustronna i obowiązkowa, a przy większej liczbie języków łatwo o pominięcie.
Pozostałe częste błędy:
- Nieprawidłowe kody języka – format
pl_PLzamiastpl-PL, kody spoza standardu ISO - Sprzeczność z adresem kanonicznym – hreflang wskazuje jeden adres, a znacznik canonical inny
- Niepełne relacje wzajemne – strona A wskazuje stronę B, ale strona B nie wskazuje strony A
- Brak autoreferencji – każda wersja musi zawierać znacznik wskazujący na siebie
- Nieprawidłowy format adresów – adresy relatywne zamiast pełnych, mieszanie HTTP i HTTPS
- Wskazywanie adresów wykluczonych z indeksowania – znacznik prowadzi do strony z
noindexalbo zablokowanej wrobots.txt
Osobna kategoria to błędy pojawiające się dopiero z czasem. Znaczniki wdrożone poprawnie na start rozjeżdżają się przy zmianie struktury adresów, usunięciu jednej wersji językowej albo migracji domeny. To argument za walidacją wpisaną w proces wdrożeniowy, nie za jednorazowym audytem.
Jak sprawdzić, czy hreflang działa poprawnie?
Weryfikacja obejmuje dwie warstwy: poprawność techniczną znaczników i to, jak interpretuje je wyszukiwarka. Zacznij od kodu źródłowego strony. Sprawdź, czy znaczniki są w sekcji <head>, mają poprawną składnię i tworzą pełny zestaw relacji wzajemnych.
Tu jedna ważna zmiana, o której nadal piszą starsze poradniki. Google Search Console miał raport „Kierowanie międzynarodowe”, który zbiorczo raportował błędy hreflang. Raport został wycofany 22 września 2022 roku. Google nadal obsługuje i wykorzystuje hreflang, ale nie udostępnia już w Search Console zbiorczej walidacji. Zniknęła również możliwość ręcznego wskazania kraju docelowego dla całego serwisu.
Aktualna ścieżka weryfikacji wygląda więc tak:
- Search Console, narzędzie Sprawdzenie adresu URL – pokazuje, jak Google widzi konkretną podstronę, w tym wybrany adres kanoniczny
- Search Console, raport Strony – ujawnia sytuacje, w których Google wybrał inny adres kanoniczny niż zadeklarowany, co często oznacza konflikt sygnałów
- Screaming Frog SEO Spider – skanuje cały serwis i raportuje brakujące znaczniki zwrotne oraz błędy formatu
- Ahrefs Site Audit i Sitebulb – raportują błędy hreflang w kontekście całego serwisu, Sitebulb pokazuje też mapę relacji między wersjami
- Walidator hreflang na TechnicalSEO.com (dawniej narzędzie Merkle) – szybka kontrola pojedynczych adresów i map witryny
Przydaje się też weryfikacja ręczna. Sprawdź wyniki wyszukiwania z parametrami języka i kraju, żeby zobaczyć, która wersja się pokazuje. Potwierdź, że przejście z wyników w danym kraju prowadzi na właściwą wersję językową.
Czas reakcji Google bywa różny. Pojedyncze zmiany bywają przetworzone w kilka dni. Przebudowa struktury wielojęzycznej w dużym serwisie zajmuje tygodnie, czasem miesiące. Google musi ponownie przeskanować wszystkie powiązane podstrony i potwierdzić relacje wzajemne, zanim uwzględni nowe deklaracje.
Hreflang w dużych serwisach: gdzie zaczynają się prawdziwe problemy
Przy kilku podstronach hreflang jest zadaniem na jedno popołudnie. Skala zmienia charakter problemu, bo liczba relacji rośnie kwadratowo. Pięć wersji językowych i dwieście podstron to już cztery tysiące relacji do utrzymania. Ręczna kontrola przestaje mieć sens.
Wzorce, które widzimy najczęściej w audytach:
Grupy multi-brand. Kilka marek, kilka rynków, wspólna infrastruktura. Znaczniki hreflang bywają wdrożone per marka, przez różne zespoły, w różnych momentach. Efekt: warianty regionalne jednej marki linkują do wersji innej marki albo relacje kończą się na granicy instalacji.
E-commerce B2B na kilku rynkach. Katalog produktowy zmienia się codziennie. Nowe warianty pojawiają się szybciej, niż zespół pilnuje znaczników. Wersje przetłumaczone częściowo generują luki, w których hreflang wskazuje adresy jeszcze nieistniejące albo zwracające przekierowanie.
Portale wydawnicze i platformy edukacyjne. Duży wolumen treści, archiwa liczone w tysiącach adresów, treści dostępne tylko w części języków. Bez centralnego zarządzania relacjami stary content zostaje z nieaktualnymi znacznikami po każdej zmianie struktury.
Wspólny mianownik jest jeden. Hreflang traktowany jako ustawienie wtyczki działa do momentu pierwszej większej zmiany w serwisie. Traktowany jako element architektury informacji działa dalej, bo znaczniki generują się z jednego źródła danych o wersjach językowych, a walidacja jest częścią procesu wdrożeniowego. Robiliśmy tę zmianę w serwisach wielojęzycznych wielokrotnie i zawsze zaczyna się ona od uporządkowania struktury adresów, nie od konfiguracji wtyczki.
Podsumowanie
Hreflang wymaga precyzji, ale zwrot z tej pracy jest wymierny. Poprawnie wdrożony pozwala wyszukiwarce pokazywać właściwą treść właściwym odbiorcom, chroni wersje językowe przed konkurowaniem ze sobą i skraca drogę użytkownika do informacji, której szuka.
Kolejność działań, którą rekomendujemy:
- Ustal, czy Twój serwis w ogóle wymaga hreflang, i które warianty mają być zadeklarowane
- Uporządkuj strukturę adresów, zanim zaczniesz generować znaczniki
- Wybierz jedną metodę wdrożenia i jedno źródło prawdy o wersjach językowych
- Wpisz walidację w proces wdrożeniowy, nie w kalendarz audytów
- Monitoruj konflikty między hreflang a adresami kanonicznymi po każdej zmianie struktury
FAQ
Czy hreflang wpływa na pozycje w wyszukiwarce?
Nie bezpośrednio. Hreflang nie jest czynnikiem rankingowym. Wpływa na to, którą wersję strony wyszukiwarka pokaże danemu odbiorcy, a to przekłada się na współczynnik kliknięć i zachowanie użytkownika po wejściu. Chroni też wersje językowe przed traktowaniem ich jako duplikatów.
Czy hreflang zastępuje znacznik canonical?
Nie. Oba znaczniki działają równolegle i muszą być spójne. Każda wersja językowa powinna mieć adres kanoniczny wskazujący na siebie, a hreflang opisuje jej relacje z pozostałymi wersjami. Sprzeczność między nimi to jeden z najczęstszych powodów, dla których Google ignoruje deklaracje.
Czy wystarczy hreflang w mapie witryny?
Wystarczy, jeżeli mapa jest kompletna i aktualna. To rozwiązanie sensowne w bardzo dużych serwisach, gdzie dodawanie znaczników do każdej podstrony obciąża szablony. Wymaga jednak dyscypliny w generowaniu mapy. Nie mieszaj metod, bo sprzeczne deklaracje w HTML i w mapie witryny wprowadzają szum.
Czy potrzebuję osobnych znaczników dla en-GB i en-US?
Tylko wtedy, gdy treści faktycznie się różnią, na przykład cenami, warunkami dostawy albo informacjami regulacyjnymi. Jeżeli obie wersje są identyczne, wystarczy hreflang="en". Warianty regionalne bez różnic w treści dodają złożoności bez korzyści.
Co się dzieje, gdy brakuje znacznika zwrotnego?
Google zwykle ignoruje całą deklarację. Znacznik jednostronny nie działa, bo wyszukiwarka nie ma potwierdzenia, że obie strony należą do tej samej grupy językowej. To dlatego relacje wzajemne są warunkiem, nie dobrą praktyką.
Czy WPML i Polylang wystarczają?
W standardowych wdrożeniach tak, obie wtyczki generują poprawne znaczniki wraz z autoreferencją i relacjami wzajemnymi. Problemy zaczynają się przy niestandardowych typach treści, kilku instalacjach WordPressa, migracjach domen i przy strukturze, w której część treści istnieje tylko w wybranych językach. Wtedy potrzebna jest kontrola nad logiką generowania znaczników.
Twój serwis wielojęzyczny gubi ruch na niewłaściwych wersjach językowych? Zaczniemy od audytu struktury i sygnałów międzynarodowych. → Zamów audyt
