Hreflang w SEO: jak poprawnie wdrożyć i sprawdzić wersje językowe strony

Hreflang pomaga Google określić, dla jakiego języka lub regionu przeznaczona jest konkretna strona. Adnotacja łączy adresy odpowiadające sobie treścią, na przykład polską stronę usługi z jej angielską wersją. Google traktuje ją jako jeden z sygnałów do wyboru wyniku, a nie gwarancję wyświetlenia wskazanego adresu.

Hreflang nie tłumaczy treści, ale jest mechanizmem kierowania strony na język lub region. Google wymienia hreflang jako metodę geotargetowania na poziomie strony, obok lokalnych adresów URL i map witryny. Język strony Google rozpoznaje również na podstawie widocznej treści, dlatego sam tag nie zastąpi tłumaczenia ani właściwego wariantu regionalnego. Dokumentacja Google Search Central opisuje te sygnały oraz różnice między witrynami wielojęzycznymi i wieloregionalnymi.

Google obsługuje trzy sposoby przekazania relacji: elementy HTML, mapę XML i nagłówki HTTP. Wybierz metodę, którą zespół może utrzymywać bez rozbieżności między źródłami danych. Planowanie całej struktury warto połączyć z poradnikiem zakładania strony internetowej, zwłaszcza gdy witryna dopiero powstaje.

Wdrożenie ma sens, gdy te same typy stron mają osobne, dostępne adresy dla różnych języków lub rynków. Dotyczy to katalogów językowych, subdomen i osobnych domen, a także rozdzielonych wersji regionalnych, na przykład angielskiej dla Wielkiej Brytanii i Stanów Zjednoczonych. Google dopuszcza każdą z tych struktur, jeśli warianty mają stabilne URL-e.

Tabela porównuje typowe struktury adresów dla wersji językowych. Wybór zależy od sposobu zarządzania domenami, treścią i migracjami.

Każda z tych struktur może obsługiwać hreflang, jeśli strony mają osobne adresy i odpowiadają sobie treścią. Przy wyborze domeny uwzględnij też kwestie marki i utrzymania opisane w materiale domena .pl czy .com.

Hreflang nie wnosi użytecznej informacji, gdy witryna ma jedną wersję, treść zmienia się pod tym samym URL-em zależnie od ciasteczka albo strony nie są odpowiednikami. Nie łącz pustej strony z istniejącym tłumaczeniem tylko po to, by wypełnić grupę. Z naszych wdrożeń wynika, że po zmianie struktury adresów częstym problemem są pozostawione relacje do starych URL-i.

Przed wdrożeniem przypisz każdemu URL-owi kod języka, opcjonalny region i adresy istniejących odpowiedników. Mapa wykrywa brakujące tłumaczenia, stare adresy oraz strony, które nie są rzeczywistymi odpowiednikami. Kod języka zapisuj jako `pl` lub `en`, a region dodawaj tylko dla odrębnej wersji rynku, na przykład `en-GB`.

Tabela pokazuje przykładową grupę strony usługi i selektora języka. `x-default` wskazuje adres domyślny dla użytkownika, którego języka witryna nie obsługuje.

Strona bez tłumaczenia powinna wskazywać tylko istniejący wariant, czyli zwykle samą siebie w obrębie dostępnej grupy. Nie przypisuj jej strony głównej, jeśli ta nie jest odpowiednikiem treści. Google zaleca, aby każda wersja wymieniała siebie i dostępne alternatywy; pozostawione pary muszą wskazywać się wzajemnie.

Dla strony polskiej i angielskiej oznacza to, że polski URL wskazuje angielski, a angielski polski. `x-default` może prowadzić do selektora języka albo rzeczywiście domyślnej wersji. Przed publikacją zapisz w mapie również status strony i jej canonical, bo te dane pozwalają wykryć konflikty, których nie widać w samym tagu.

Dodaj hreflang w sekcji ``, mapie XML albo nagłówku HTTP. HTML sprawdza się przy typowych stronach, mapa XML ułatwia centralne zarządzanie dużą liczbą relacji, a nagłówek HTTP może opisywać pliki takie jak PDF. Google uznaje te metody za równoważne, więc wybierz jedną jako główne źródło konfiguracji.

Przykład polskiej, angielskiej i domyślnej wersji strony:

<link rel="alternate" hreflang="pl" href="https://example.com/pl/usluga/">
<link rel="alternate" hreflang="en" href="https://example.com/en/service/">
<link rel="alternate" hreflang="x-default" href="https://example.com/">

Używaj pełnych adresów z protokołem `https://`. Kod języka powinien odpowiadać standardowi ISO 639-1, a opcjonalny kod regionu standardowi ISO 3166-1 Alpha 2. Dla polskiej wersji bez rozdzielenia rynku wybierz `pl`; dla wersji przeznaczonej dla Wielkiej Brytanii wybierz `en-GB`.

Przed publikacją sprawdź następujące warunki:

• Lista zawiera aktualny adres strony.
• Kod opisuje rzeczywisty język i ewentualny region.
• Każdy URL prowadzi do odpowiedniej treści.
• Każda pozostawiona para zawiera wzajemne wskazania.
• Adresy są pełne i używają docelowego protokołu HTTPS.

W mapie XML każda strona ma osobny wpis `` z listą alternatyw w elementach ``. Dla pliku innego niż HTML nagłówek `Link` przekazuje adresy i wartości `hreflang` całej grupy. Jeśli tworzysz nową witrynę i potrzebujesz zaplanować adresy oraz wersje językowe, strony internetowe dla firm mogą uwzględnić tę strukturę już na etapie projektu.

W WordPressie sprawdź konfigurację wtyczki językowej, a następnie potwierdź wygenerowany kod źródłowy. WPML automatycznie dodaje i aktualizuje hreflang dla stron oraz tłumaczeń. Aby przypisać językowi wartość regionalną, przejdź do `WPML → Settings → Languages`, edytuj język i sprawdź pole hreflang.

Polylang generuje atrybuty na podstawie powiązań między wersjami językowymi. Filtr `pll_rel_hreflang_attributes` pozwala programistycznie modyfikować adresy i kody w sekcji ``, na przykład dodać `x-default`. Taką zmianę umieść w kodzie własnej wtyczki lub rozwiązaniu utrzymywanym przez zespół, a nie w pliku motywu, który może zostać nadpisany aktualizacją.

W każdym CMS otwórz opublikowaną stronę, wyświetl źródło i wyszukaj `rel="alternate"` oraz `hreflang`. Sprawdź również mapę XML, ponieważ wpisy mogą generować niezależnie wtyczka językowa, wtyczka SEO lub warstwa CDN. Ustawienie widoczne w panelu nie potwierdza, że kod odpowiedzi zawiera właściwe adresy.

Konfigurację najczęściej osłabia brak wzajemnego odnośnika, niepoprawny kod, niedziałający URL albo konflikt z canonicalem. Widoczny tag nie potwierdza, że wskazana strona działa i może być indeksowana. Kontroluj adres źródłowy, alternatywę oraz sygnały kanonikalizacji jako jeden zestaw.

Tabela łączy typowe objawy z działaniem naprawczym. Status HTTP, canonical i dostęp do indeksowania należy zweryfikować dla każdego wskazanego adresu.

Blokada crawlowania w `robots.txt` nie jest blokadą indeksowania. Google może zaindeksować zablokowany URL na podstawie innych sygnałów, a jednocześnie nie odczyta z niego meta `noindex` ani nagłówka `X-Robots-Tag`. Do blokowania indeksowania użyj dostępnego dla robota `noindex` w meta robots lub nagłówku HTTP. Dokumentacja Google o blokowaniu indeksowania wyjaśnia, dlaczego URL z `noindex` nie może być jednocześnie zablokowany przed crawlowaniem.

Google zaleca canonical wskazujący preferowany adres w tym samym języku co strona. Hreflang opisuje relację między wersjami, a canonical konsoliduje sygnały dla adresów uznanych za duplikaty lub bardzo podobne. Gdy kilka wersji jest odrębnymi stronami regionalnymi, zweryfikuj, czy każda ma własny canonical.

Testuj hreflang razem ze statusem HTTP, canonicalem i indeksowalnością, ponieważ poprawny tag może wskazywać stronę niedostępną dla robota. Próbkę zbuduj z najważniejszych typów stron, takich jak strona główna, kategoria i podstrona usługi w każdym języku. Po sprawdzeniu próbki uruchom pełny skan witryny crawlerem raportującym alternatywy, odpowiedzi serwera i dyrektywy indeksowania.

Dla każdego URL-a wykonaj tę samą procedurę:

1. Sprawdź, czy adres zwraca kod 200 i nie przekierowuje do innego wariantu.
2. Odczytaj `robots.txt`, meta robots i nagłówek `X-Robots-Tag`.
3. Odczytaj canonical i porównaj go z preferowanym adresem tej wersji.
4. Potwierdź, że strona wskazuje samą siebie i istniejące odpowiedniki.
5. Sprawdź, czy każda pozostawiona para ma wskazania zwrotne.
6. Porównaj wyniki z mapą URL-i i oznacz brakujące tłumaczenia.

Po migracji, zmianie struktury URL albo aktualizacji wtyczki uruchom kontrolę ponownie. Sprawdź stare adresy, docelowe przekierowania i zgodność języka strony po przekierowaniu. Migracja WordPressa powinna obejmować hreflang oraz przekierowania w ramach tej samej zmiany.

Utrzymuj hreflang przez okresowy skan techniczny i aktualizację mapy po dodaniu języka, zmianie URL-a albo wycofaniu strony. Google Search Console pomaga sprawdzić indeksowanie adresów i wybrany canonical, ale inspekcja jednego URL-a nie potwierdza poprawności całej grupy. W crawlerze monitoruj brakujące pary, przekierowania, odpowiedzi błędów oraz strony z `noindex`.

Po dodaniu języka opublikuj działające strony, przypisz im rzeczywiste odpowiedniki i zaktualizuj wszystkie używane metody adnotacji. Po wycofaniu wersji usuń jej URL z kodu, mapy XML i nagłówków HTTP. Po zmianie adresu zaktualizuj hreflang, canonical, linki wewnętrzne i przekierowania w jednym wdrożeniu.

Perspektywa KC Mobile: w naszych wdrożeniach błędy hreflang często ujawniają się po zmianie adresów lub wycofaniu tłumaczenia. Zalecamy przechowywać mapę URL-i razem z dokumentacją wdrożenia i ponawiać skan po migracji oraz aktualizacji wtyczki. Kontekst planowania rynków zagranicznych opisujemy w poradniku SEO międzynarodowego.

Jeśli chcesz zlecić przygotowanie struktury witryny i jej wersji językowych, poznaj ofertę stron internetowych dla firm.

• Jak zaplanować strukturę strony internetowej i przygotować mapę witryny
• Jak przygotować stronę internetową pod kampanię reklamową?
• Jak dodać domenę do hostingu i skierować ją na serwer?
• Jakich błędów unikać przy przeprojektowaniu strony internetowej