Kiedy robisz strone, ktora ma dzialac i w Polsce, i w Niemczech, hreflang to jeden z tych tematow, ktory latwo zlekcewazyc - az do momentu, gdy zauwazysz, ze polska wersja leci w wynikach dla Niemiec, albo odwrotnie. Wedlug badania Ahrefs z 2025 roku na prawie 375 000 domenach, az 67% stron uzywajacych hreflangu ma tam blady. To nie jest rzadki problem - to norma.

W ostatnich latach skonfigurowałem hreflang dla kilkunastu projektow dwujezycznych, glownie PL-DE. Wiekszosc bledow wracala jak bumerang: brakujace tagi zwrotne, zly kod jezykowy albo miks metod wdrozenia. Ponizej rozpisuję, jak to zrobic dobrze od poczatku i jak sprawdzic, czy to, co masz teraz, dziala prawidlowo.

Czym jest hreflang i kiedy go potrzebujesz

Hreflang to atrybut HTML (lub wpis w sitemapie), ktory mowi wyszukiwarkom: "ta strona ma kilka wersji jezykowych, oto wszystkie, z informacja dla kogo sa". Uzywasz go, gdy masz ta sama tresc w roznych jezykach lub gdy celujesz w rozne rynki geograficzne.

Dla strony PL-DE hreflang jest niezbedny w kazdej z tych sytuacji:

  • jedna domena z podkatalogami (/pl/, /de/)
  • subdomeny (pl.domena.com, de.domena.com)
  • osobne domeny krajowe (.pl i .de)

Bez hreflang Google probuje sam domyslic sie, dla kogo dana strona jest przeznaczona. Robi to na podstawie jezyka tresci, domeny ccTLD i sygnałów z Search Console. Czasem trafia, czesto nie. Widzialem przypadki, gdzie strona firmowa z siedziba w Hamburgu, napisana po polsku, ladowala wysoko w google.de dla fraz po polsku - bo Google nie wiedzial, ze istnieje niemiecka wersja pod inna subdomena. Klient tracil ruch z Niemiec, bo Niemcy nie szukaja po polsku.

Hreflang obsluguje Bing i Google. Inne wyszukiwarki (np. Yandex) stosuja wlasne mechanizmy lokalizacji. Dla rynku PL-DE skupiam sie wylacznie na Googlu - Bing ma tam marginalny udzial.

Hreflang obsluguje Bing i Google. Inne wyszukiwarki (np. Yandex) stosuja wlasne mechanizmy lokalizacji.

Jak wyglada poprawna skladnia

Kod jezyka musi byc zgodny z ISO 639-1 - dwie litery, male. Dla wersji polskiej piszesz pl, dla niemieckiej de. Jesli chcesz zawezic do konkretnego kraju (np. Austria), dodajesz region: de-AT. Blad, ktory widze czesto: uzywanie podkreslnika zamiast myslnika (de_DE zamiast de-DE) albo wielkich liter w kodzie (PL zamiast pl).

Google nie zwroci bledu w Search Console za zly format kodu - po prostu cicho zignoruje tag. Wlasnie dlatego ten blad tak czesto zostaje niezauważony przez tygodnie.

Przyklad poprawnych tagow w sekcji <head> dla strony PL-DE:

<link rel="alternate" hreflang="pl" href="https://domena.pl/usluga/" />
<link rel="alternate" hreflang="de" href="https://domena.de/leistung/" />
<link rel="alternate" hreflang="x-default" href="https://domena.pl/usluga/" />

Te same tagi musza pojawic sie na OBU stronach - i na polskiej, i na niemieckiej. To jest ten slynny wzajemny tag zwrotny, bez ktorego Google ignoruje caly klaster.

Uwaga na URL-e: musza byc absolutne, z pelnym protoko em (https://), z dokladnie takim adresem, jaki Google widzi jako kanoniczny dla tej strony. Jesli masz canonical wskazujacy na wersje z www, hreflang tez musi uzywac wersji z www. Roznica miedzy https://domena.pl/ a https://www.domena.pl/ to dla Google dwa rozne URL-e.

Kompletny klaster hreflang - co musi zawierac

  • Tag hreflang wskazujacy na wersje PL (z polska strona)
  • Tag hreflang wskazujacy na wersje DE (z polska strony)
  • Dokladnie te same tagi powtorzone na stronie DE
  • Tag x-default wskazujacy na wersje domyslna
  • Self-referencing: kazdy URL wskazuje rowniez na siebie samego
  • URL-e jako absolutne (z https://, nie wzgledne)

Trzy metody wdrozenia - ktora wybrac

Masz trzy sposoby na dodanie hreflangu: bezposrednio w sekcji <head> HTML, w pliku sitemap XML albo w naglowkach HTTP (ta ostatnia glownie dla PDF i stron bez HTMLa).

Porownanie metod wdrozenia hreflang

KryteriumSekcja headSitemap XML
Latwosc wdrozenia w WPProsta (plugin robi sam)Prosta (plugin robi sam)
Dobre dla duzych serwisowNie - obciaza kod kazdej stronyTak - centralna kontrola
Dobre dla malych stron (<50 URL)TakTak
Bled widoczny od razuTak - w zrodle stronyWymaga sprawdzenia sitemapy
Mozliwosc konfliktuNie mieszaj z sitemapaNie mieszaj z head

Dla wiekszosci projektow WordPress, ktore robie, wybieram sitemap XML - latwiej utrzymac jeden plik niz lapac blady rozrzucone po szablonach. Przy malym serwisie (blog firmowy, strona PL + strona DE) roznica jest minimalna.

Przy metodzie sitemap XML struktura wygląda nastepujaco - dla kazdego URL tworzysz wpis z atrybutami xhtml:link wskazujacymi na wszystkie wersje jezykowe. Rank Math i Yoast generuja ten format automatycznie, wiec przy wiekszosci projektow WordPress nie musisz pisac sitemappy recznie. Sprawdz jednak wynikowy plik pod adresem /sitemap.xml - WPML czasem generuje osobne sitemappy dla kazdego jezyka i trzeba sie upewnic, ze zawieraja wzajemne linki miedzy soba.

Nie uzywaj obu metod jednoczesnie dla tych samych URL-i. Jesli Rank Math generuje hreflang w sekcji head, nie dodawaj ich recznie do sitemapy - powstaja konflikty, ktore Google najczesciej rozwiazuje przez ignorowanie obu.

Najczestsze bledy i jak je rozpoznac

Przejde przez bledy, ktore widze najczesciej - w kolejnosci od najbardziej powszechnych.

1. Brak tagu zwrotnego (reciprocal hreflang)

Strona PL wskazuje na strone DE, ale strona DE nie wskazuje z powrotem na strone PL. Google wymaga pelnego powiazan - jesli jeden z konca klastra milczy, caly klaster jest ignorowany. Ten blad pojawia sie szczegolnie czesto gdy tumaczenie strony robisz recznie, bez pluginu.

U klienta z branzy budowlanej wdrozylismy wersje DE recznie, strona po stronie, bo projekt byl maly - 8 podstron. Klient sam dodawal tlumaczenia przez ACF. Przez 4 miesiace google.de pokazywal polska wersje na frazach niemieckich. Przyczyna: na wersji DE dodal tagi hreflang wskazujace na PL, ale zapomniał dodac te same tagi na wersji PL wskazujace z powrotem na DE. Naprawilismy to w 20 minut po audycie - ale przez 4 miesiace tracil ruch.

2. Brak self-referencing

Kazda strona powinna zawierac tag hreflang wskazujacy rowniez na siebie sama. Czesto pomijany, bo wydaje sie zbedny. Przyklad - na stronie https://domena.de/leistung/ powinien byc tag <link rel="alternate" hreflang="de" href="https://domena.de/leistung/" />, nie tylko tag wskazujacy na wersje polska.

Bez self-referencing Google technicznie moze zaakceptowac klaster, ale oficjalna dokumentacja Google jasno wskazuje, ze kazdy URL w klastrze powinien wskazywac na siebie. Przy audytach narzedzia jak hreflang.ninja oznaczaja brak self-referencing jako blad.

3. Zle kody jezykowe

Popularny blad: uzycie uk zamiast en-GB dla Wielkiej Brytanii, de_DE z podkreslnikiem, albo pl-PL gdy wystarczy samo pl. Kod nieznany Google powoduje, ze tag jest ignorowany bez zadnego komunikatu o bledzie.

Dodatkowa pulapka przy rynku DE: jesli celujesz tylko w Niemcy, samo de wystarczy. Jesli chcesz rozroznic Niemcy od Austrii, uzywasz de-DE i de-AT. Jesli jednak masz jedna wersje DE dla calego obszaru niemieckojezycznego (Niemcy, Austria, Szwajcaria), lepiej zostac przy samym de - jest szerzej rozumiany.

4. Wzgledne URL-e zamiast absolutnych

Hreflang wymaga pelnych adresow URL z protoko em (https://). Wzgledna sciezka /uslugi/ jest nieprawidlowa - musi byc https://domena.pl/uslugi/.

5. Konflikt z canonical

Jesli na stronie DE masz canonical wskazujacy na strone PL (np. przez pomylke w pluginie), Google zignoruje hreflang i potraktuje strone DE jako duplikat PL. To jeden z trudniejszych do wykrycia bledow - pojawia sie glownie przy nieprawidlowej konfiguracji Rank Math lub Yoast na zrodlach wielojezycznych.

Zdarzalo mi sie to przy przenoszeniu projektow z jednego pluginu SEO na inny. Yoast przy dezaktywacji nie czyści swoich ustawien canonical z bazy, a Rank Math przy aktywacji nie nadpisuje automatycznie wszystkich pol. Efekt: na wersji DE zostaje canonical z Yoasta wskazujacy na PL, Rank Math generuje swoj hreflang, ale Google ignoruje go, bo widzi sprzeczny canonical. Sprawdzenie: curl -I na URL strony DE i weryfikacja naglowka Link plus source strony pod katem obu tagów.

67%stron z hreflangiem ma bledy w implementacji (Ahrefs 2025)
100 USD/rokkoszt WPML Business - najtansza wersja z pelnym wsparciem hreflang
3-5 dnitypowy czas audytu i naprawy hreflangu na sredniej stronie PL-DE
2-3 tygodnieczas zanim Google zaindeksuje poprawki hreflang po naprawie

Hreflang w WordPress - jak to ustawic praktycznie

Jesli uzywasz Rank Math (a jest to plugin, ktory sam instaluje na wiekszosci projektow), masz dwie realne opcje dla wielojezycznosci:

WPML + Rank Math: WPML (ok. 100 USD rocznie w wersji Multilingual CMS) generuje tagi hreflang automatycznie. Rank Math przejmuje generowanie hreflangu, gdy modul "Multilingual SEO" jest wlaczony w dashboardzie Rank Math. Klastry sa kompletne - self-referencing, x-default, tagi zwrotne - bez recznie pisanego kodu.

Po stronie konfiguracji WPML: zanim dodasz pierwsza tresc, ustaw struktury URL w sekcji Languages - dla opcji podkatalogow zaznaczasz, ze wersja PL idzie pod /pl/ lub jest domyslna (bez prefiksu), a DE pod /de/. Zmiana tej struktury pozniej, gdy masz juz 50 przetlumaczonych podstron, to praca na kilka godzin plus ryzyko bledow 404 na starych linkach. Lepiej ustawic to dokladnie raz.

Polylang Pro + Rank Math: Tansza alternatywa (ok. 99 EUR za rok). Dziala rownie dobrze technicznie, ma nieco mniej opcji zaawansowanych. Dobry wybor dla mniejszych projektow z budzetem do 500 zl na narzedzia SEO.

Roznica miedzy WPML a Polylang, ktora ma znaczenie przy wiekszych projektach: WPML ma wbudowany modul do zarzadzania tlumaczeniami z zewnetrznymi biurami tlumaczen i API do integracji z DeepL. Przy Polylang to dodatkowe narzedzia. Dla strony firmowej PL-DE z 20 podstronami ta roznica nie ma znaczenia - dla sklepu z 500 produktami juz tak.

Plusy

  • Automatyczna generacja kompletnych klastrow hreflang
  • Integracja z sitemapa XML (Rank Math generuje sitemap multilingual)
  • Brak recznego kodu - mniejsze ryzyko pomylki w URL-ach
  • Raport bledow widoczny w Search Console i w panelu Rank Math

Minusy

  • WPML kosztuje - dla jednorazowego projektu to moze byc zbyt duzy koszt
  • Oba pluginy wymagaja wstepnej konfiguracji struktury URL przed pierwsza trescia
  • Zmiana struktury URL po wdrozeniu (np. z subdomen na podkatalogi) to bolesna migracja

Jeden projekt, ktory dobrze pamietam: klient mial strone PL i chcial dodac wersje DE dla klientow z Hamburga. Polylang byl juz zainstalowany, ale tagi hreflang na wersji DE nie wskazywaly z powrotem na PL - klasyczny brak reciprocal. Strona DE po 3 miesiacach miala praktycznie zero widocznosci w google.de. Po poprawieniu klastrow i ponownym zindeksowaniu, po 3 tygodniach pojawiły sie pierwsze pozycje dla fraz de.

Jak wykryc bledy w Google Search Console

Search Console ma dedykowany raport dla stron wielojezycznych - znajdziesz go w sekcji "Miedzynarodowe kierowanie" (International targeting). Zakladka "Jezyk" pokazuje bledy z tagami hreflang.

Najczestsze komunikaty blędow w GSC:

  • "No return tags" - strona wskazana przez hreflang nie wskazuje z powrotem. Zrodlo problemu: brak reciprocal.
  • "Unknown language" - nieznany kod jezykowy w tagu. Zrodlo: literowka lub bledny format.
  • "Alternate URL must be canonical" - URL w hreflang nie jest kanonicznym adresem tej strony. Zrodlo: konflikt z canonical.

GSC nie pokazuje bledow w czasie rzeczywistym - raport jest aktualizowany z opoznieniem do kilku dni. Jesli wdroz poprawke i natychmiast sprawdzasz GSC, mozesz jeszcze widziec stare bledy. Daj systemowi 48-72 godziny po zmianie, zanim wyciagniesz wnioski z raportu.

Uzupelniajaco polecam bezplatne narzedzie hreflang.ninja - wklejasz URL, skanuje caly klaster i pokazuje wizualnie, ktore powiazania sa uszkodzone. Oszczedza duzo czasu przy recznym audycie. Drugi polecany tool to Screaming Frog SEO Spider - w wersji darmowej mozesz crawlowac do 500 URL-i i w zakladce Hreflang widac wszystkie bledy dla kazdego URL w tabeli.

Sprawdzaj raport "Miedzynarodowe kierowanie" w GSC przynajmniej raz na miesiac przez pierwsze trzy miesiace po wdrozeniu hreflang - bledy czesto pojawiaja sie po aktualizacji pluginow SEO lub zmianach w strukturze URL.

Struktura URL - wybor ma znaczenie przed wdrozeniem

Zanim zaczniesz konfiguracje, wybierz strukture URL dla wersji jezykowych. To decyzja trudna do zmiany pozniej. Masz trzy opcje:

  • Podkatalogi: domena.com/pl/, domena.com/de/ - najczesciej polecam dla nowych projektow
  • Subdomeny: pl.domena.com, de.domena.com - dobre gdy masz juz duzy autorytet domeny
  • Osobne domeny: domena.pl, domena.de - najsilniejszy sygnal lokalny, ale wymaga budowania autorytetu osobno

Dla strony firmowej PL-DE, gdzie budujesz autorytet od zera, wybierze podkatalogi. Dla sklepu, ktory ma juz silna domene PL i rozszerza sie na DE - czesto warto rozwazyc subdomenę lub osobna domene .de.

Argumenty za osobna domena .de sa silne, jesli planujesz dlugoserwisowy projekt na rynku DE. Domena .de to dla Niemcow sygnal lokalnosci - widzialem badania eye-trackingowe, ktore pokazuja, ze niemieccy uzytkownicy szybciej klikaja w wyniki z .de niz z .com/pl. Argument przeciw: budujesz autorytet domeny od zera, wiec przez pierwsze 12-18 miesiecy strona DE moze rankingowac gorzej niz gdybys uzyl podkatalogu silnej domeny .pl.

Szerzej o tym, jak przeprowadzic przeniesienie struktury bez strat SEO, pisałem w artykule o redesignie strony bez utraty pozycji Google.

Czas indeksowania po wdrozeniu hreflang

Po poprawnym wdrozeniu lub naprawieniu hreflang Google potrzebuje czasu, by przetworzyc zmiany. Z moich obserwacji na projektach PL-DE:

  • Pierwsze pojawienie sie w GSC raportu Jezyk: 3-7 dni po wdrozeniu
  • Zniknięcie starych bledow z GSC po naprawie: 7-14 dni
  • Faktyczna zmiana w rankingach dla wersji DE po korrektnym hreflang: 2-6 tygodni

Te czasy zaleza od tego, jak czesto Googlebot odwiedza Twoja strone. Jesli masz maly serwis z nowa domena, mozna przyspieszyc indeksowanie przez GSC - "Zbadaj URL" na kluczowych stronach i "Wysli do indeksowania" zaraz po wdrozeniu hreflang. Nie jest to gwarancja, ale przyspiesza przetwarzanie o kilka dni.

Co jeszcze ma znaczenie przy wielojezycznej stronie

Hreflang to tylko jeden element. Strona PL-DE bedzie sie dobrze rankingowac, gdy zadbasz rowniez o:

  • Treść faktycznie przetlumaczona - nie przez automatyczny translator bez korekty. Google rozroznia maszynowe tlumaczenie od ludzkiego.
  • Oddzielne frazy kluczowe dla kazdego rynku - frazy DE to inny zestaw niz frazy PL po prostu przetlumaczone. Niemcy szukaja inaczej.
  • Lokalne linki przychodzace dla wersji DE - same tagi hreflang nie zbuduja autorytetu w google.de. Potrzebujesz linkow z niemieckich zrodel.
  • Poprawny geo-targeting w Search Console - dla subdomen i podkatalogow mozna recznie wskazac kraj docelowy.

Przy treściach: automatyczne tlumaczenie przez DeepL to dobry punkt startowy, ale nie wystarczy jako finalna wersja. Google od 2024 roku coraz lepiej identyfikuje texty nieprzetlumaczone naturalnie i moze traktowac je jako thin content. Minimum to korekta natywa - Niemca, ktory przejrzy tlumaczenie pod katem naturalnosci jezykowej. Kosztujesz to okolo 0,02-0,05 EUR za slowo u wiekszosci biur tlumaczen.

Jesli chcesz, zebym sprawdzil konfiguracje hreflang na Twojej stronie albo pomogl z wdrozeniem wielojezycznego WordPress, zapraszam na strone pozycjonowania SEO - tam opisuje, co obejmuje audyt techniczny.

Mozesz tez zajrzec do wpisu o opiniach Google i pozycjonowaniu lokalnym, jezeli interesujesz sie rankingiem w wyszukiwaniu lokalnym dla rynku PL lub DE.

Najczęstsze pytania

Czy hreflang jest potrzebny, gdy mam osobna domene .de i osobna .pl?

Tak, nawet przy osobnych domenach (ccTLD) hreflang jest potrzebny - bez niego Google nie wie, ze te strony sa rownowazne wersjami jezykowymi tego samego serwisu. Bez tagów Google moze uznac, ze to dwa rozne projekty, a to blokuje transfer autorytetu miedzy domenami.

Co sie stanie, jesli pominę tag x-default?

Brak x-default nie powoduje kary, ale Google nie bedzie wiedziec, ktora wersje wyswietlic uzytkownikowi z kraju, ktorego nie obsluguje Twoja strona (np. anglojezycznemu). Dodaj x-default wskazujacy na wersje glowna lub strone wyboru jezyka - to dobra praktyka, szczegolnie gdy celujesz tez w rynek anglojezyczny.

Czy moge dodac hreflang przez sitemape zamiast w sekcji head?

Tak i jest to nawet rekomendowane przy duzych serwisach. Plik sitemap.xml z tagami xhtml:link jest latwy do utrzymania centralnie i nie obciaza HTMLa kazdej podstrony. Google oficjalnie wspiera oba sposoby jako rownowazne - wazne, zeby nie mieszac obydwu dla tych samych URL-i.

Jak sprawdzic, czy hreflang jest poprawnie wdrozony?

Najszybciej przez raport 'Miedzynarodowe kierowanie' w Google Search Console - zakladka Jezyk pokazuje bledy z brakujacymi tagami zwrotnymi. Uzupelniajaco mozna uzyc bezplatnego narzedzia hreflang.ninja lub Ahrefs Site Audit, ktore wychwytuja braki self-referencing i nieprawidlowe kody.

Ktory plugin WordPress najlepiej obsluguje hreflang dla strony PL i DE?

Najlepiej sprawdza sie WPML (ok. 100 USD/rok) w polaczeniu z Rank Math - oba pluginy wspolpracuja ze soba i automatycznie generuja kompletne klastry hreflang. Tansza alternatywa to Polylang (wersja Pro ok. 99 EUR/rok) - rowniez generuje hreflang poprawnie, wymaga tylko wstepnego ustawienia struktur URL przed pierwszym wpisem.

Czy hreflang wplywa na pozycje w Google?

Hreflang nie jest bezposrednim czynnikiem rankingowym, ale wplywa na wyswietlanie wlasciwej wersji strony wlasciwemu uzytkownikowi - co przekłada sie na nizszy wskaznik odrzucan i wyzsze konwersje. Posrednio wiec poprawna konfiguracja pomaga SEO. Dodatkowo eliminuje problemy z duplikacja tresci miedzy wersjami jezykowymi.


, , , ,