Hreflang to jeden z niewielu elementów technicznego SEO, który nie znosi kompromisów. Wystarczy, że wersja niemiecka nie wskazuje z powrotem na polską, a Google pomija adnotacje dla całej pary i sam zgaduje, którą stronę pokazać użytkownikowi w Monachium. Na WordPressie problem ma dodatkową warstwę: tagi generuje zwykle wtyczka, więc większość błędów nie bierze się z pomyłki w kodzie, tylko z konfiguracji, której nikt nie sprawdził w źródle strony.
Ten tekst dotyczy konkretnego scenariusza: serwis na WordPressie z wersjami PL, EN i DE. Ogólne zasady (formaty, kody, strategie dla dużych serwisów) opisuje nasz przewodnik po hreflang; tutaj skupiamy się na tym, co trzeba ustawić i sprawdzić w samym WordPressie.
Struktura adresów: katalogi, subdomeny czy osobne domeny
Hreflang działa z każdą strukturą, ale wybór struktury decyduje o tym, jak trudne będzie utrzymanie tagów. Dla serwisu PL/EN/DE mamy trzy realne opcje:
| Struktura | Przykład | Na WordPressie | Kiedy ma sens |
|---|---|---|---|
| Katalogi | example.pl/en/, example.pl/de/ | Jedna instalacja, jedna wtyczka językowa, najprostsza konfiguracja | Większość firm wchodzących na nowe rynki |
| Subdomeny | en.example.pl, de.example.pl | Jedna instalacja z mapowaniem domen albo Multisite | Gdy wersje mają osobne zespoły lub osobny hosting |
| Osobne domeny | example.pl, example.de, example.com | Najczęściej osobne instalacje, hreflang trzeba spinać ręcznie lub dodatkową wtyczką | Gdy marka ma lokalne spółki i lokalny budżet na linki |
Katalogi wygrywają, bo cała grupa językowa żyje w jednej bazie danych, a wtyczka zna powiązania między tłumaczeniami i sama wypisuje komplet tagów. Przy osobnych instalacjach każda z nich musi znać adresy pozostałych, co przy setkach podstron prowadzi do rozjazdów po każdej zmianie sluga. Jeśli przechodzisz z jednej struktury na inną, potrzebna jest pełna mapa przekierowań 301; hreflang wskazujący na stare adresy po przekierowaniu to jeden z częstszych błędów po migracji.
Zasada wzajemności i dlaczego psuje najwięcej wdrożeń
Każda strona w grupie musi wskazywać na wszystkie pozostałe wersje oraz na samą siebie. Jeśli polska strona deklaruje wersję angielską i niemiecką, to angielska i niemiecka muszą zadeklarować polską. Brak odnośnika zwrotnego oznacza, że Google ignoruje adnotację dla tej pary. Poprawny komplet dla jednej podstrony wygląda tak:
<link rel="alternate" hreflang="pl" href="https://example.pl/uslugi/" />
<link rel="alternate" hreflang="en" href="https://example.pl/en/services/" />
<link rel="alternate" hreflang="de" href="https://example.pl/de/leistungen/" />
<link rel="alternate" hreflang="x-default" href="https://example.pl/en/services/" />Identyczny zestaw (z tymi samymi czterema adresami) musi się pojawić na wszystkich trzech wersjach. W WordPressie wzajemność psuje się zwykle na trzy sposoby:
- Tłumaczenie niepowiązane z oryginałem. Redaktor tworzy wpis po niemiecku jako nowy post, zamiast dodać go jako tłumaczenie. Wtyczka nie wie, że to wersja tej samej treści, więc nie wypisuje tagów.
- Zmiana sluga w jednej wersji. Niemiecka strona dostaje nowy adres, a cache (wtyczki lub serwera) dalej serwuje na polskiej i angielskiej stary href.
- Kody regionalne niezgodne z normą. Kod języka musi być zgodny z ISO 639-1, a opcjonalny region z ISO 3166-1 Alpha 2. Wersja
en-UKjest błędna (poprawnieen-GB), a samode-ATbez wersji ogólnejdezostawia bez dopasowania użytkowników z Niemiec i Szwajcarii.
x-default: kiedy jest potrzebny
Wartość x-default mówi wyszukiwarce, którą stronę pokazać, gdy język użytkownika nie pasuje do żadnej z zadeklarowanych wersji. Dla serwisu PL/EN/DE odbiorca z Francji czy Hiszpanii nie ma swojej wersji, więc najrozsądniej wskazać mu angielską. Drugi typowy przypadek to strona wyboru języka lub kraju: jeśli ją masz, to właśnie ona powinna być oznaczona jako x-default.
x-default nie jest obowiązkowy, ale bez niego Google wybiera wersję według własnych sygnałów, a to często kończy się pokazaniem polskiej strony użytkownikowi, który nie zna polskiego. Ustawienie go to kilka kliknięć, więc nie ma powodu, by z niego rezygnować.
Konfiguracja w popularnych wtyczkach wielojęzycznych
Wtyczki SEO, takie jak Rank Math czy Yoast, same nie generują hreflang. Robi to wtyczka wielojęzyczna, a wtyczka SEO odpowiada za canonical, meta i sitemapę, które muszą być z nią zgodne. Najczęściej spotykane rozwiązania:
- WPML. Tagi wypisuje automatycznie dla treści połączonych jako tłumaczenia. W ustawieniach języków wybierasz format adresów (katalogi, domeny lub parametr) i opcje SEO, w tym umieszczanie alternatywnych wersji w sekcji head oraz x-default. Po zmianie formatu adresów warto przeczyścić cache i sprawdzić kilka podstron ręcznie.
- Polylang. Hreflang dodaje automatycznie, a format adresu zależy od tego, czy język jest ustalany z katalogu, subdomeny czy domeny. Opcja ukrywania kodu języka domyślnego w adresie zmienia też to, jak wygląda x-default na stronie głównej, więc po jej przełączeniu zawsze weryfikuj źródło.
- TranslatePress. Działa na jednym poście z tłumaczeniami przechowywanymi osobno, dzięki czemu wzajemność jest zapewniona z definicji. W ustawieniach sprawdź, czy kody w hreflang mają być ogólne (de) czy regionalne (de-DE), i wybierz jedną konwencję dla całego serwisu.
Niezależnie od wtyczki zasada jest jedna: nie dodawaj hreflang ręcznie w motywie ani drugą wtyczką, jeśli pierwsza już je generuje. Zdublowane tagi z różnymi adresami są gorsze niż ich brak, bo wysyłają sprzeczne sygnały.
Hreflang a canonical: jak je pogodzić
Każda wersja językowa musi mieć canonical wskazujący na samą siebie. Najpoważniejszy błąd, jaki widujemy w audytach, to canonical z wersji angielskiej i niemieckiej ustawiony na polski oryginał. Taki sygnał mówi Google, że EN i DE to duplikaty, więc nie trafią do indeksu, a hreflang wskazujący na nie traci sens.
Druga zasada: wszystkie adresy w hreflang muszą być dokładnie tymi kanonicznymi. Jeśli canonical ma ukośnik na końcu, a hreflang go nie ma, to href prowadzi na przekierowanie i para przestaje być spójna. Na WordPressie warto też sprawdzić, czy wtyczka SEO nie nadpisuje canonical na stronach paginacji i archiwach kategorii w wersjach językowych, bo tam rozjazdy zdarzają się najczęściej.
Weryfikacja wdrożenia i raport w Search Console
Raport kierowania międzynarodowego, który pokazywał błędy hreflang, Google wycofał z Search Console w 2022 roku. Weryfikacja wygląda dziś inaczej:
- Źródło strony. Otwórz po jednej podstronie z każdej wersji i sprawdź, czy komplet tagów jest identyczny i zawiera odnośnik do samej siebie.
- Crawler. Screaming Frog lub Sitebulb w trybie raportu hreflang pokażą brakujące odnośniki zwrotne, adresy nie zwracające 200 i niezgodności z canonical w skali całego serwisu.
- Sprawdzanie adresu URL w Search Console. Widok zrenderowanego HTML potwierdza, że Googlebot widzi te same tagi co przeglądarka, a pole kanonicznego adresu wybranego przez Google pokazuje, czy wersja językowa nie została potraktowana jako duplikat.
- Skuteczność według krajów. W raportach Search Console przefiltruj skuteczność po kraju i stronie: jeśli w Niemczech wyświetla się głównie polska wersja, hreflang nie działa, choćby walidator mówił co innego.
Pełną specyfikację, w tym zasady dla sitemapy i nagłówków HTTP, opisuje dokumentacja Google Search Central o zlokalizowanych wersjach stron.
Częściowe tłumaczenia: co zrobić z brakującymi stronami
Rzadko który serwis ma komplet tłumaczeń. Typowo wersja angielska obejmuje 80% treści, a niemiecka tylko ofertę i kontakt. Zasada jest prosta: hreflang deklarujesz tylko dla wersji, które istnieją. Wpis blogowy dostępny po polsku i angielsku ma tagi pl, en i x-default, bez de.
Błędem jest kierowanie brakującej wersji na stronę główną lub kategorię w danym języku. Wtyczki robią to czasem domyślnie, gdy w ustawieniach włączono przekierowanie na stronę główną dla nieprzetłumaczonych treści. Drugi błąd to publikowanie maszynowych tłumaczeń tylko po to, by zamknąć grupę: takie strony często kończą ze statusem wykryto, obecnie nie zaindeksowano, a hreflang wskazujący na nieindeksowaną stronę nie przynosi żadnej korzyści. Lepiej mieć mniej wersji dobrej jakości. Jeśli wchodzisz na rynek DACH, zacznij od podstron, które mają realny popyt; pomocna będzie nasza checklista SEO dla rynku niemieckiego.
FAQ
Czy Rank Math albo Yoast dodają hreflang?
Nie. Obie wtyczki zajmują się canonical, meta i sitemapą, a tagi hreflang generuje wtyczka wielojęzyczna (WPML, Polylang, TranslatePress). Wtyczka SEO musi być z nią zintegrowana, żeby canonical i sitemapa wskazywały na właściwe wersje językowe.
Czy hreflang musi zawierać odnośnik do samej strony?
Tak. Każda wersja deklaruje cały komplet, łącznie ze sobą. Brak samoodniesienia nie zawsze unieważnia grupę, ale jest jedną z najczęstszych przyczyn niespójności wykrywanych przez crawlery.
Używać kodu de czy de-DE?
Jeśli treść jest jedna dla wszystkich niemieckojęzycznych odbiorców, wystarczy de. Kody regionalne (de-DE, de-AT, de-CH) mają sens, gdy wersje różnią się cenami, walutą lub ofertą. Nie mieszaj konwencji w jednym serwisie.
Jak szybko Google uwzględnia zmiany w hreflang?
Dopiero po ponownym pobraniu wszystkich stron z grupy, bo wzajemność weryfikowana jest po obu stronach. Na mniejszych serwisach trwa to od kilku dni do kilku tygodni, dlatego efekty mierz w raporcie skuteczności po krajach, a nie następnego dnia.
Czy hreflang zastępuje przekierowanie według języka przeglądarki?
Nie, i automatycznych przekierowań po języku lepiej unikać. Googlebot pobiera strony głównie z adresów w USA, więc wymuszone przekierowanie może ukryć przed nim wersje PL i DE. Bezpieczniej pokazać baner z propozycją zmiany języka.