Czego dowiesz się z tego artykułu:
- Kiedy sklep internetowy naprawdę potrzebuje hreflang – i kiedy nie
- Jak dobrać kody de-DE, de-AT i de-CH do specyfiki rynku DACH
- Którą metodę wdrożenia wybrać zależnie od wielkości katalogu produktów
- Jak wdrożyć hreflang w WooCommerce, Shoper i PrestaShop
- Dlaczego hreflang i rel=canonical mogą ze sobą wchodzić w konflikt – i jak tego uniknąć
- Błędy, które niszczą widoczność polskiego sklepu w Google.de
- Jak monitorować hreflang po usunięciu raportu z Google Search Console
- Jak hreflang wpływa na widoczność w AI Overviews i trybie AI
Co to jest hreflang i dlaczego sklep internetowy w Niemczech go potrzebuje?
Hreflang to atrybut HTML, który mówi Google, dla jakiego języka i regionu przeznaczona jest dana podstrona. Bez niego wyszukiwarka samodzielnie (ale też często błędnie) decyduje, którą wersję sklepu wyświetlić użytkownikowi. Dla polskiego e-commerce wchodzącego na rynek DACH to konkretny problem: klient z Niemiec trafia na polską wersję, odbija się, a Ty tracisz sprzedaż.
Mechanizm działania jest prosty. Gdy robot Google trafia na stronę z tagami hreflang, odczytuje informację: „ta podstrona ma swoje odpowiedniki w innych językach i regionach”. Przy kolejnym zapytaniu użytkownika z Niemiec, Google dobiera właściwą wersję – nie tę, którą uzna za stosowną, tylko tę, którą Ty wskazałeś.
Hreflang nie jest czynnikiem rankingowym w sensie dosłownym – nie winduje strony wyżej. Działa inaczej: zwiększa trafność wyświetlanego wyniku, co przekłada się na niższy współczynnik odrzuceń i wyższy CTR. Według danych SEMrush z badania 20 000 wielojęzycznych stron internetowych, około 75% z nich ma hreflangi wdrożone błędnie lub nie ma ich wcale. To oznacza, że poprawna implementacja tego jednego elementu technicznego stawia Twój sklep w lepszej pozycji niż trzy na cztery konkurencyjne witryny.
Kiedy sklep naprawdę potrzebuje hreflang?
Nie każdy sklep go wymaga. Jeśli sprzedajesz wyłącznie po polsku, do polskich klientów, hreflang nie jest Ci potrzebny. Sytuacja zmienia się w momencie, gdy pojawia się więcej niż jeden język lub więcej niż jeden rynek.
| Sytuacja sklepu | Hreflang konieczny? | Dlaczego |
| Sklep PL + wersja DE dla Niemiec | ✅ TAK | Google musi wiedzieć, że /de/ to nie duplikat /pl/, tylko osobna wersja dla innego rynku |
| Sklep DE + osobna wersja dla Austrii | ✅ TAK | Ten sam język, inne kody regionu – bez hreflang Google nie odróżni de-DE od de-AT |
| Sklep DE + wersja dla Szwajcarii (inna cena, inna waluta) | ✅ TAK | Identyczna treść, inne realia biznesowe – hreflang sygnalizuje intencję regionalną |
| Jeden sklep, jedna wersja językowa DE, jeden rynek | ❌ NIE | Brak alternatywnych wersji – nie ma czego łączyć |
| Sklep PL z automatycznym tłumaczeniem na DE (ten sam URL) | ⚠️ NIE (ale to i tak błąd SEO) | Hreflang wymaga osobnych URL dla każdej wersji – samo tłumaczenie “w locie” nie wystarczy |
Ważna rzecz, którą widzę u klientów regularnie: sklep ma wersję niemiecką, właściciel „ustawił hreflang na głównej” i uważa temat za zamknięty. Hreflang ustawiony tylko na stronie głównej nie obejmuje kart produktów, kategorii ani podstron treściowych. Google łączy ze sobą konkretne pary URL – nie całe domeny. Każda podstrona musi mieć własny zestaw tagów.
Jeszcze jedna rzecz, którą warto zrozumieć na starcie: hreflang to sygnał, nie dyrektywa. Google go rozpatruje, ale może też zignorować – szczególnie gdy implementacja jest niekompletna lub sprzeczna z tagiem canonical. O tym dokładnie w dalszej części poradnika.
de-DE, de-AT, de-CH – który kod wybrać dla swojego sklepu?
Większość polskich sklepów wchodzących na rynek DACH popełnia ten sam błąd: ustawia jeden kod de dla całego obszaru niemieckojęzycznego i uznaje sprawę za załatwioną. To nie wystarczy – i w wielu przypadkach aktywnie szkodzi.
Niemcy, Austria i Szwajcaria to trzy osobne rynki. Ten sam język, ale inne waluty, inne stawki VAT, inne przyzwyczajenia zakupowe i inne przepisy. Google to rozumie. Twój hreflang też powinien to odzwierciedlać.
Cztery kody, które musisz znać
| Kod hreflang | Rynek | Waluta | Kiedy stosować |
| de-DE | Niemcy | EUR | Sklep z dedykowaną wersją dla rynku niemieckiego – osobne ceny, lokalna dostawa, treści pisane pod DE |
| de-AT | Austria | EUR | Osobna wersja dla Austrii – inne stawki VAT (20% zamiast 19%), lokalni przewoźnicy, austriackie słownictwo |
| de-CH | Szwajcaria | CHF | Wersja dla Szwajcarii – inna waluta (frank szwajcarski), inne regulacje celne, często inne ceny |
| de | Wszyscy użytkownicy niemieckojęzyczni | – | Fallback dla użytkowników DE mówiących, gdy nie masz osobnych wersji regionalnych – lub jako uzupełnienie zestawu |
Kod de bez regionu działa jak siatka bezpieczeństwa. Google wyświetli tę wersję użytkownikowi niemieckojęzycznemu, dla którego nie znalazł bardziej precyzyjnego dopasowania – na przykład komuś z Belgii lub Luksemburga mówiącemu po niemiecku. Jeśli masz tylko jedną wersję DE i nie planujesz osobnych wersji regionalnych, sam de wystarczy. Jeśli masz de-DE, de-AT i de-CH, dodaj do zestawu również de – jako uzupełnienie, nie zamiennik.
Kiedy naprawdę warto tworzyć osobne wersje?
| Kraj | Argument ZA osobną wersją | Argument PRZECIW |
| Niemcy (de-DE) | Największy rynek DACH, 84 mln mieszkańców, najwyższy potencjał sprzedażowy, lokalna dostawa przez DHL/ DPD/ Hermes | Jeśli dopiero startujesz – zacznij od de, rozbuduj później |
| Austria (de-AT) | Inna stawka VAT (20%), inne lokalne metody płatności, klienci preferują austriackich przewoźników | Rynek ~9 mln osób – opłaca się przy sprzedaży powyżej pewnego progu |
| Szwajcaria (de-CH) | Frank szwajcarski, brak unii celnej z UE, inne ceny, wysoka siła nabywcza klientów | Wymaga osobnej obsługi logistycznej i prawnej – spory próg wejścia |
Z mojego doświadczenia: polskie sklepy najczęściej startują od wersji de-DE i słusznie. Austria i Szwajcaria wchodzą do gry, gdy sklep ma już stabilną sprzedaż w Niemczech i widzi rosnący ruch z tych krajów w Google Analytics. Nie buduj trzech wersji na raz, jeśli nie masz zasobów, żeby utrzymać każdą z nich na odpowiednim poziomie. Pusta lub niedopracowana wersja de-AT zaszkodzi bardziej niż jej brak.
Jak wygląda kompletny zestaw tagów dla DACH?
Jeśli masz wszystkie trzy wersje regionalne plus wersję polską, na każdej podstronie powinien znaleźć się taki zestaw:
<!– Na stronie niemieckiej (de-DE) –>
<link rel=”alternate” hreflang=”de-DE” href=”https://sklep.de/de/” />
<link rel=”alternate” hreflang=”de-AT” href=”https://sklep.de/at/” />
<link rel=”alternate” hreflang=”de-CH” href=”https://sklep.de/ch/” />
<link rel=”alternate” hreflang=”de” href=”https://sklep.de/de/” />
<link rel=”alternate” hreflang=”pl” href=”https://sklep.pl/” />
<link rel=”alternate” hreflang=”x-default” href=”https://sklep.de/de/” />
Każda z pozostałych wersji musi zawierać identyczny zestaw – ze wskazaniem na siebie. To jest właśnie zasada wzajemności (reciprocal linking), bez której Google ignoruje całą implementację. Szczegółowo o strukturze wdrożenia – w następnej sekcji.
Jak wdrożyć hreflang w sklepie internetowym?
Hreflang można wdrożyć na trzy sposoby. Wybór metody nie jest obojętny – zły dobór przy dużym sklepie potrafi przysporzyć poważnych problemów z wydajnością i crawl budgetem. Zacznijmy od tego, czym różnią się te podejścia, a potem przejdźmy do konkretnej rekomendacji dla e-commerce.
Metoda 1: Tagi w sekcji <head> HTML
Najprostsza i najszybsza w implementacji. Dodajesz zestaw tagów <link rel=”alternate” hreflang=”…”> bezpośrednio w sekcji <head> każdej podstrony. Każda strona nosi ze sobą pełną informację o swoich odpowiednikach językowych.
<!– Przykład dla karty produktu w sklepie DE/PL –>
<link rel=”alternate” hreflang=”de-DE” href=”https://sklep.de/produkt/buty-do-biegania/” />
<link rel=”alternate” hreflang=”pl” href=”https://sklep.pl/produkt/buty-do-biegania/” />
<link rel=”alternate” hreflang=”x-default” href=”https://sklep.de/produkt/buty-do-biegania/” />
Metoda działa dobrze przy mniejszych sklepach – do kilku tysięcy podstron. Przy większych pojawia się problem: każda karta produktu musi zawierać pełny zestaw tagów. Przy 3 wersjach językowych i 10 000 produktów generujesz 30 000 dodatkowych wierszy kodu HTML. To obciąża czas ładowania i zwiększa liczbę zapytań do bazy danych przy każdym renderowaniu strony.
Metoda 2: Sitemap XML
Zamiast rozsiewać tagi po każdej podstronie, zbierasz wszystkie informacje o wersjach językowych w jednym pliku XML. Google odczytuje go podczas crawlowania i przypisuje relacje między URL-ami.
<url>
<loc>https://sklep.de/produkt/buty-do-biegania/</loc>
<xhtml:link rel=”alternate” hreflang=”de-DE”
href=”https://sklep.de/produkt/buty-do-biegania/” />
<xhtml:link rel=”alternate” hreflang=”pl”
href=”https://sklep.pl/produkt/buty-do-biegania/” />
<xhtml:link rel=”alternate” hreflang=”x-default”
href=”https://sklep.de/produkt/buty-do-biegania/” />
</url>
To rozwiązanie preferowane dla dużych sklepów. Jeden plik, centralne zarządzanie, zero wpływu na czas ładowania podstron. Minusem jest trudniejsze debugowanie – błędu nie zobaczysz w kodzie źródłowym strony, musisz analizować plik XML lub korzystać z zewnętrznych narzędzi.
Metoda 3: Nagłówki HTTP
Tagi hreflang umieszczasz w nagłówkach odpowiedzi serwera zamiast w kodzie HTML. Metoda ta ma jedno konkretne zastosowanie: pliki inne niż HTML – przede wszystkim PDF-y. Jeśli oferujesz wielojęzyczne katalogi produktów w formacie PDF, to jedyne wyjście. Dla standardowych stron sklepu internetowego ta metoda jest zbyt skomplikowana w zarządzaniu, żeby uzasadniała swoje użycie.
Która metoda dla jakiego sklepu?
| Metoda | Najlepsza dla | Zalety | Wady |
| Tagi HTML <head> | Sklepy do ~5 000 podstron, proste wdrożenia | Łatwa implementacja, prosta w debugowaniu, widoczna w kodzie źródłowym | Obciąża HTML przy dużych sklepach, wymaga aktualizacji na każdej podstronie |
| Sitemap XML | Sklepy powyżej 5 000 podstron, platformy z generowaniem dynamicznym | Centralne zarządzanie, zero wpływu na wydajność stron, łatwa aktualizacja | Trudniejsze debugowanie, błędy mniej widoczne |
| Nagłówki HTTP | Pliki PDF, zasoby nie-HTML | Jedyna opcja dla treści bez sekcji <head> | Skomplikowana konfiguracja serwera, niepraktyczna dla stron HTML |
Moja rekomendacja dla polskich sklepów wchodzących na DACH jest prosta: jeśli masz poniżej 5 000 podstron – zacznij od tagów HTML, bo łatwiej debugować błędy na starcie. Jeśli sklep ma rozbudowany katalog produktów – wdrożenie przez sitemap XML jest lepszym wyborem długoterminowo. Obie metody możesz też łączyć, choć wymaga to dyscypliny, żeby uniknąć sprzeczności między nimi.
Trzy zasady, bez których żadna metoda nie zadziała
Niezależnie od wybranego podejścia, obowiązują te same reguły fundamentalne. Złamanie którejkolwiek sprawia, że Google ignoruje całą implementację.
Zasada 1: Wzajemność (reciprocal linking) Jeśli strona A wskazuje na stronę B, strona B musi wskazywać na stronę A. Bez wyjątków. Google traktuje to jako potwierdzenie, że obie strony „zgadzają się” co do swojej relacji. Brak tagu zwrotnego to najczęstszy błąd w całym SERPie – i najłatwiejszy do przeoczenia przy dużych sklepach.
Zasada 2: Self-referencing Każda strona musi zawierać tag hreflang wskazujący na samą siebie. Nie na stronę główną wersji językowej – na konkretny URL, na którym tag jest umieszczony.
Zasada 3: Bezwzględne URL-e W tagach hreflang zawsze podajesz pełny adres z protokołem: https://sklep.de/produkt/ – nie /produkt/. Względne adresy URL są przez Google ignorowane.
Czym jest x-default i kiedy go ustawiać?
Tag x-default wskazuje wersję strony dla użytkowników, których język lub region nie pasuje do żadnego innego hreflanga w zestawie. Nie jest obowiązkowy, ale Google go zaleca.
Praktyczne zastosowanie w e-commerce: jeśli masz sklep w wersji de-DE i pl, ustaw x-default na wersję angielską (jeśli istnieje) lub na stronę wyboru języka. Jeśli nie masz żadnej wersji „globalnej” – wskaż wersję, która obsługuje największy ruch.
<!– x-default dla sklepu bez wersji angielskiej –>
<link rel=”alternate” hreflang=”x-default” href=”https://sklep.de/de/” />
Częsty błąd: ustawianie x-default na stronę główną domeny bez żadnej logiki. Użytkownik z Japonii trafia wtedy na stronę po niemiecku i natychmiast ją opuszcza. x-default powinien prowadzić do miejsca, które sensownie obsługuje „resztę świata” – najlepiej do strony wyboru języka lub wersji w najbardziej neutralnym języku.
Hreflang w WooCommerce, Shoper i PrestaShop – jak wdrożyć na popularnych platformach?
Teoria teorią, ale większość polskich sklepów internetowych stoi na konkretnej platformie – i to ona decyduje, jak wdrożenie hreflang wygląda w praktyce. WooCommerce, Shoper i PrestaShop obsługują hreflang w zupełnie różny sposób. Poniżej znajdziesz konkretne kroki dla każdej z nich – bez owijania w bawełnę.
WooCommerce
WooCommerce sam w sobie nie obsługuje hreflangów. Potrzebujesz wtyczki do zarządzania wielojęzycznością. Na rynku są trzy rozwiązania, które faktycznie działają w połączeniu z SEO.
WPML to najpopularniejsza opcja dla sklepów z rozbudowanym katalogiem. Wtyczka tworzy osobne wersje językowe każdej podstrony i automatycznie generuje kompletne zestawy tagów hreflang – w sekcji <head> lub w sitemap XML, zależnie od konfiguracji. Integruje się z Yoast SEO i Rank Math, co pozwala zarządzać metadanymi każdej wersji osobno. Koszt: od 99 USD rocznie za wersję Multilingual Blog, od 159 USD za wersję z pełnym wsparciem WooCommerce.
Polylang to tańsza alternatywa, wystarczająca dla prostszych sklepów. Darmowa wersja obsługuje tłumaczenia postów i stron, ale dla pełnej integracji z WooCommerce (produkty, kategorie, atrybuty) potrzebujesz wersji Pro (około 99 EUR rocznie). Hreflangi generuje automatycznie po skonfigurowaniu wersji językowych.
TranslatePress działa inaczej – tłumaczy treści bezpośrednio w interfejsie front-end, bez tworzenia osobnych wpisów w bazie danych. Hreflangi generuje poprawnie, ale podejście do struktury URL jest inne niż w WPML. Sprawdza się przy mniejszych sklepach, gdzie priorytetem jest szybkość wdrożenia.
| Wtyczka | Hreflang automatyczny | Integracja z WooCommerce | Cena roczna (orientacyjna) | Najlepsza dla |
| WPML | ✅ TAK (HTML + sitemap) | ✅ Pełna | od 159 USD | Duże sklepy, rozbudowane katalogi |
| Polylang Pro | ✅ TAK (HTML) | ✅ Z wtyczką WooCommerce | ~99 EUR | Średnie sklepy, prostsze struktury |
| TranslatePress | ✅ TAK (HTML) | ✅ Częściowa | od 99 EUR | Małe sklepy, szybkie wdrożenie |
Jeden błąd, który widzę przy wdrożeniach WPML regularnie: sklep ma poprawnie skonfigurowane hreflangi dla produktów, ale zapomniano o stronach kategorii i tagach. Google indeksuje kategorie równie intensywnie jak produkty – a często to właśnie one generują największy ruch organiczny. Sprawdź po wdrożeniu, czy każdy typ treści (produkt, kategoria, tag, strona CMS) ma swój odpowiednik językowy i poprawne tagi.
Shoper
Shoper to polska platforma SaaS, z której korzysta kilkadziesiąt tysięcy polskich sklepów. Obsługa wielojęzyczności jest wbudowana w platformę – nie potrzebujesz zewnętrznych wtyczek.
Żeby uruchomić hreflangi w Shoper, musisz:
- Przejść do panelu administracyjnego → Ustawienia → Języki i dodać wersję językową dla rynku DE
- Uzupełnić tłumaczenia treści dla każdej wersji językowej (nazwy produktów, opisy, kategorie)
- Skonfigurować osobne URL-e dla każdej wersji – Shoper obsługuje strukturę podkatalogów (/de/) lub subdomen
- Sprawdzić w ustawieniach SEO, czy platforma generuje tagi hreflang automatycznie – w aktualnych wersjach Shoper robi to po poprawnej konfiguracji języków
Ważne ograniczenie Shoper: platforma generuje hreflangi dla wersji językowych w obrębie jednego sklepu. Jeśli prowadzisz osobne sklepy na różnych domenach (np. sklep.pl i sklep.de jako dwa oddzielne byty w Shoper), hreflangi między nimi musisz wdrożyć ręcznie – przez edycję szablonu lub sitemap XML.
Przy Shoperze warto też pamiętać o crawl budgecie. Duży sklep z kilkoma wersjami językowymi i dynamicznymi filtrami kategorii może generować ogromną liczbę URL-i do zaindeksowania. Zanim uruchomisz hreflangi dla wszystkich podstron, upewnij się, że plik robots.txt blokuje filtrowane wersje kategorii (?sort=, ?page=) – inaczej Google będzie tracił crawl budget na strony bez wartości SEO.
PrestaShop
PrestaShop ma wbudowany moduł wielojęzyczności, który działa lepiej niż WooCommerce out-of-the-box, ale gorzej niż Shoper w kontekście automatyzacji hreflang.
Natywna obsługa wielojęzyczności w PrestaShop tworzy wersje językowe i obsługuje strukturę URL z prefiksem języka (/de/, /pl/). Problem polega na tym, że domyślnie PrestaShop nie generuje automatycznie kompletnych zestawów tagów hreflang we wszystkich wymaganych miejscach – szczególnie dla starszych wersji (1.6, 1.7).
Dla PrestaShop 8.x i nowszych sytuacja jest lepsza – platforma generuje hreflangi w sekcji <head> dla większości typów stron. Mimo to zalecam weryfikację po wdrożeniu przy użyciu Screaming Frog.
Dla starszych wersji PrestaShop masz dwie opcje:
Opcja A: Moduł „SEO Expert” lub „Advanced SEO Friendly URLs” – płatne moduły z PrestaShop Addons Marketplace, które generują hreflangi i pozwalają zarządzać nimi centralnie. Koszt: 50-150 EUR jednorazowo.
Opcja B: Wdrożenie hreflang przez sitemap XML z użyciem zewnętrznego generatora. Eksportujesz listę URL-i z PrestaShop, generujesz sitemap z hreflangami przy użyciu narzędzia Screaming Frog lub skryptu Python, wgrywasz plik na serwer i zgłaszasz go w Google Search Console.
| Platforma | Natywna obsługa hreflang | Rekomendowane rozwiązanie | Trudność wdrożenia |
| WooCommerce | ❌ Brak | WPML lub Polylang Pro | Średnia |
| Shoper | ✅ Wbudowana (z konfiguracją) | Natywna + weryfikacja GSC | Niska |
| PrestaShop 8.x | ✅ Częściowa | Natywna + weryfikacja SF | Średnia |
| PrestaShop 1.7 i starsze | ⚠️ Niepełna | Moduł SEO lub sitemap XML | Wysoka |
Hreflang a crawl budget – co musisz wiedzieć przy dużym sklepie
Każda wersja językowa sklepu to dodatkowe URL-e do zaindeksowania. Przy sklepie z 10 000 produktów i trzema wersjami językowymi (de-DE, de-AT, pl) masz potencjalnie 30 000 podstron produktowych – plus kategorie, tagi i strony CMS. Google nie indeksuje wszystkiego naraz. Ma przydzielony budżet crawlowania dla Twojej domeny i wydaje go tam, gdzie widzi największą wartość.
Trzy zasady zarządzania crawl budget’em przy wielojęzycznym sklepie:
Po pierwsze: Blokuj w robots.txt wersje URL bez wartości SEO – filtrowane widoki kategorii, parametry sortowania, duplikaty paginacji. Każdy zablokowany „śmieciowy” URL to więcej budżetu na indeksowanie właściwych podstron z hreflangiem.
Po drugie: Wdrożenie hreflang przez sitemap XML zamiast tagów HTML zmniejsza liczbę zapytań do serwera przy renderowaniu każdej podstrony. Przy dużym sklepie różnica w czasie ładowania jest zauważalna.
Po trzecie: Monitoruj w Google Search Console zakładkę „Strony” → „Nie zaindeksowane”. Jeśli widzisz tam dużą liczbę podstron z wersji językowych, to sygnał, że Google ma problem z ich crawlowaniem – albo z powodu błędów hreflang, albo wyczerpania crawl budgetu.
Hreflang + rel=canonical w sklepie online – jak uniknąć konfliktu?
To najbardziej niedoceniany problem techniczny w całym temacie hreflang. Większość poradników omawia oba tagi osobno. W praktyce e-commerce działają razem – i gdy są ze sobą sprzeczne, Google ignoruje hreflangi w całości. Nie ostrzega. Po prostu wybiera wersję, którą uzna za właściwą, i indeksuje ją zamiast tej, którą Ty wskazałeś.
Zacznijmy od podstawowej zasady, którą Google komunikuje wprost w swojej dokumentacji: każda wersja językowa powinna mieć canonical wskazujący na samą siebie. Nie na wersję główną. Nie na stronę główną. Na konkretny URL tej strony.
<!– Poprawne – strona DE wskazuje canonical na siebie –>
<link rel=”canonical” href=”https://sklep.de/produkt/buty-do-biegania/” />
<link rel=”alternate” hreflang=”de-DE” href=”https://sklep.de/produkt/buty-do-biegania/” />
<link rel=”alternate” hreflang=”pl” href=”https://sklep.pl/produkt/buty-do-biegania/” />
<!– BŁĄD – strona DE wskazuje canonical na wersję PL –>
<link rel=”canonical” href=”https://sklep.pl/produkt/buty-do-biegania/” />
<link rel=”alternate” hreflang=”de-DE” href=”https://sklep.de/produkt/buty-do-biegania/” />
Drugi przykład to klasyczna pułapka. Właściciel sklepu boi się duplikacji treści między wersją PL i DE, więc ustawia canonical z DE na PL – „żeby Google wiedział, która jest główna”. Efekt jest odwrotny do zamierzonego: Google traktuje wersję DE jako nieskanoniczną, ignoruje jej hreflangi i przestaje ją indeksować. Wersja DE znika z Google.de.
Cztery scenariusze, które musisz znać
| Scenariusz | Canonical | Hreflang | Efekt |
| Canonical self-referencing + kompletny hreflang | Każda strona → na siebie | Wszystkie wersje wzajemnie powiązane | ✅ Poprawne – Google indeksuje każdą wersję osobno |
| Canonical z DE → na PL | Strona DE → na PL | Ustawiony poprawnie | ❌ Google ignoruje hreflang DE, indeksuje tylko PL |
| Canonical self-referencing + niekompletny hreflang | Każda strona → na siebie | Brak tagu zwrotnego w jednej wersji | ⚠️ Hreflang może być zignorowany dla tej pary |
| Brak canonical + hreflang | Nie ustawiony | Poprawny | ⚠️ Ryzyko – Google sam wybierze canonical, może nie pokryć się z hreflangiem |
Problem, który niszczy setki sklepów: warianty produktów
To jest sekcja, której nie znajdziesz w żadnym polskim artykule o hreflang. A problem dotyczy prawdopodobnie Twojego sklepu.
Typowa sytuacja: masz produkt dostępny w 5 kolorach i 4 rozmiarach – czyli 20 wariantów. Każdy wariant ma własny URL. Wszystkie mają niemal identyczny opis produktu. Masz wersję PL i wersję DE. To oznacza 40 podstron o bardzo podobnej treści, które wzajemnie ze sobą konkurują.
Bez odpowiedniej konfiguracji canonical i hreflang dzieje się kilka złych rzeczy naraz: Google widzi duplikację treści w obrębie jednej wersji językowej, nie wie, którą wersję wariantu indeksować, i dodatkowo myli wersje językowe między sobą.
Rozwiązanie składa się z dwóch warstw:
Warstwa 1 – canonical dla wariantów w obrębie jednego języka: Wskaż jeden URL jako kanoniczny dla całej grupy wariantów. Zazwyczaj to strona produktu bez parametrów lub wersja z domyślnym wariantem.
<!– Na stronie wariantu: buty-do-biegania?kolor=czerwony&rozmiar=42 –>
<link rel=”canonical” href=”https://sklep.de/produkt/buty-do-biegania/” />
Warstwa 2 – hreflang tylko na stronach kanonicznych: Tagi hreflang umieszczaj wyłącznie na stronach kanonicznych – nie na wariantach. Hreflang na nieskanonicznym URL jest przez Google ignorowany z definicji.
<!– Na stronie kanonicznej produktu DE –>
<link rel=”canonical” href=”https://sklep.de/produkt/buty-do-biegania/” />
<link rel=”alternate” hreflang=”de-DE” href=”https://sklep.de/produkt/buty-do-biegania/” />
<link rel=”alternate” hreflang=”pl” href=”https://sklep.pl/produkt/buty-do-biegania/” />
<link rel=”alternate” hreflang=”x-default” href=”https://sklep.de/produkt/buty-do-biegania/” />
<!– Na stronie wariantu DE – canonical do wersji głównej, BEZ hreflang –>
<link rel=”canonical” href=”https://sklep.de/produkt/buty-do-biegania/” />
Paginacja kategorii – kolejna pułapka
Kategorie z paginacją to drugi najczęstszy problem przy canonical + hreflang w e-commerce. Masz kategorię /de/buty/ z 10 stronami paginacji (?page=2, ?page=3…). Pytanie: na której stronie umieszczasz hreflang?
Odpowiedź: tylko na stronie 1 każdej wersji językowej – pod warunkiem, że strony 2-10 mają canonical wskazujący na stronę 1. Jeśli każda strona paginacji ma canonical self-referencing, hreflang musisz umieścić na każdej z nich – z odpowiednimi parami URL-ami dla każdej strony paginacji w drugiej wersji językowej.
W praktyce przy dużych sklepach bezpieczniejsze i prostsze w zarządzaniu jest pierwsze podejście: canonical wszystkich stron paginacji → strona 1, hreflang tylko na stronie 1.
Szybka checklista canonical + hreflang dla sklepu
| Element | Poprawna konfiguracja |
| Strona produktu (wersja kanoniczna) | Canonical self-referencing + pełny zestaw hreflang |
| Strona wariantu produktu | Canonical → strona kanoniczna produktu, BEZ hreflang |
| Strona kategorii (strona 1) | Canonical self-referencing + hreflang dla wszystkich wersji językowych |
| Strona kategorii (strona 2-N, canonical → str. 1) | Canonical → strona 1, BEZ hreflang |
| Strona kategorii (strona 2-N, canonical self-ref.) | Canonical self-referencing + hreflang z odpowiednimi parami paginacji |
| Strona główna każdej wersji językowej | Canonical self-referencing + pełny zestaw hreflang + x-default |
Zanim przejdziesz do wdrożenia, sprawdź w swoim sklepie dwie rzeczy: czy któraś wtyczka SEO lub platforma nie ustawia automatycznie canonicali między wersjami językowymi, i czy strony wariantów produktów mają canonical wskazujący na właściwą stronę kanoniczną. To dwa miejsca, gdzie błędy pojawiają się najczęściej – i gdzie są najtrudniejsze do wykrycia bez narzędzi.
Błędy hreflang, które obniżają widoczność polskiego sklepu w Google.de
Według badania SEMrush na próbie 20 000 wielojęzycznych stron internetowych, około 75% z nich ma hreflangi wdrożone błędnie lub nie ma ich wcale. W e-commerce ten odsetek jest prawdopodobnie wyższy – sklepy mają tysiące podstron, dynamiczne generowanie URL-i i wielowarstwowe zależności między canonical a hreflangiem. Błędy łatwo się mnożą i trudno je wykryć bez narzędzi.
Poniżej 7 błędów, które widzę najczęściej przy audytach polskich sklepów wchodzących na rynek DACH. Przy każdym: co się dzieje, dlaczego to problem i jak to naprawić.
Błąd 1: Brak tagu zwrotnego (no return tag)
Najczęstszy błąd w całym SERPie i jednocześnie najłatwiejszy do przeoczenia przy dużym sklepie. Strona DE wskazuje hreflangiem na stronę PL, ale strona PL nie zawiera tagu wskazującego z powrotem na DE.
Google wymaga wzajemności jako formy weryfikacji – jeśli obie strony nie potwierdzają swojej relacji, cały zestaw tagów jest ignorowany. Nie dostaniesz żadnego ostrzeżenia w Google Search Console. Sklep po prostu nie wyświetla się właściwym użytkownikom.
Przy dużych sklepach ten błąd pojawia się najczęściej po dodaniu nowych produktów lub kategorii – deweloper dodaje hreflangi do nowej wersji DE, ale zapomina zaktualizować odpowiedniki w wersji PL.
Błąd 2: Błędny kod języka lub regionu
Kody ISO są sztywne. Google nie interpretuje przybliżeń. Kilka wariantów, które regularnie widzę w kodach sklepów:
| Błędny kod | Poprawny kod | Błąd |
| de-de | de-DE | Małe litery w kodzie regionu |
| en_GB | en-GB | Podkreślnik zamiast myślnika |
| ger | de | Trzyliterowy kod zamiast ISO 639-1 |
| DE | de-DE | Sam kod kraju bez języka |
| pl_PL | pl-PL | Podkreślnik (format Facebooka, nie ISO) |
Błędny kod sprawia, że Google całkowicie ignoruje dany tag – bez ostrzeżenia, bez informacji zwrotnej. Szczególnie podstępny jest podkreślnik zamiast myślnika: wygląda poprawnie, działa w wielu systemach CMS, ale w hreflang jest niepoprawny.
Błąd 3: Hreflang ustawiony tylko na stronie głównej
Klasyczny błąd właścicieli sklepów, którzy samodzielnie wdrażają hreflang po przeczytaniu krótkiego poradnika. Dodają tagi na stronie głównej, sprawdzają w narzędziu – działa. I na tym poprzestają.
Hreflang musi być na każdej podstronie, która ma swój odpowiednik językowy. Strona główna to jedna z tysięcy podstron sklepu. Karty produktów, kategorie, strony CMS, blog – każda musi mieć własny kompletny zestaw tagów. Google łączy konkretne pary URL, nie całe domeny.
Błąd 4: Hreflang prowadzący do strony 404 lub przekierowania
Jeśli URL wskazany w tagu hreflang zwraca błąd 404 lub jest przekierowany (301/302), Google ignoruje cały tag dla tej pary. Nie indeksuje wersji alternatywnej, nie wyświetla jej użytkownikom.
Ten błąd pojawia się najczęściej po usunięciu produktu z jednej wersji językowej bez aktualizacji hreflangów w drugiej, po zmianie struktury URL w sklepie bez przekierowania starych adresów, po migracji na nową platformę, gdy część URL-i zmienia format. Przy sklepach z dynamicznym katalogiem – sezonowym asortymentem, produktami wycofanymi ze sprzedaży – regularne sprawdzanie poprawności hreflangów jest koniecznością, nie opcją.
Błąd 5: Konflikt canonical → inna wersja językowa
Ustawienie canonicala z wersji DE na wersję PL (lub odwrotnie) powoduje, że Google traktuje jedną z wersji jako nieskanoniczną i przestaje ją indeksować. Hreflangi stają się wtedy bezużyteczne – działają tylko na stronach kanonicznych. Każda wersja językowa musi mieć canonical wskazujący na samą siebie.
Błąd 6: Hreflang na stronach z noindex
Strona oznaczona jako noindex nie jest indeksowana przez Google. Ustawienie na niej hreflanga nic nie zmienia – Google i tak jej nie weźmie pod uwagę. Co więcej: jeśli strona A ma hreflang wskazujący na stronę B oznaczoną noindex, tag dla całej pary może zostać zignorowany.
Najczęstszy scenariusz w sklepach: strony paginacji kategorii z noindex, na których mimo to zostały ustawione hreflangi. Albo strony testowe lub stagingowe przypadkowo dostępne publicznie z noindex – ale z hreflangiem wskazującym na produkcyjne URL-e.
Błąd 7: Automatyczne tłumaczenie bez osobnych URL-i
Coraz popularniejszy błąd wraz ze wzrostem dostępności narzędzi AI do tłumaczenia treści. Sklep tłumaczy stronę dynamicznie – ten sam URL, inna treść zależnie od języka przeglądarki użytkownika lub parametru URL (?lang=de). Właściciel dodaje hreflang, ale wskazuje ten sam URL dla obu wersji językowych.
Hreflang wymaga osobnych URL-i dla każdej wersji językowej. Dwa hreflangi wskazujące na ten sam adres są przez Google ignorowane. Dynamiczne tłumaczenie w locie bez osobnej struktury URL nie jest kompatybilne z hreflangiem – i nie rozwiązuje problemu duplikacji treści między wersjami językowymi.
Podsumowanie błędów – tabela błąd / skutek / naprawa
| Błąd | Skutek dla sklepu | Naprawa |
| Brak tagu zwrotnego | Cały zestaw hreflang ignorowany | Dodaj hreflangi na WSZYSTKICH wersjach powiązanych stron |
| Błędny kod języka/regionu | Tag całkowicie ignorowany przez Google | Sprawdź kody ISO 639-1 i ISO 3166-1 Alpha-2, usuń podkreślniki |
| Hreflang tylko na stronie głównej | Produkty i kategorie bez właściwego targetowania | Wdrożenie hreflang na każdej podstronie z odpowiednikiem językowym |
| Hreflang → 404 lub redirect | Tag ignorowany, wersja alternatywna niewidoczna | Audyt URL-i w tagach (Screaming Frog), aktualizacja po zmianach w katalogu |
| Canonical → inna wersja językowa | Wersja nieskanoniczna znika z indeksu | Canonical self-referencing na każdej wersji językowej |
| Hreflang na stronie noindex | Tag ignorowany, para URL niewidoczna | Usuń hreflangi ze stron noindex lub zmień dyrektywę na index |
| Tłumaczenie dynamiczne (ten sam URL) | Hreflang niekompatybilny, duplikacja treści | Osobne URL-e dla każdej wersji językowej jako warunek konieczny |
Jeden wniosek praktyczny, który wyciągam z audytów: większość tych błędów nie wychodzi od razu po wdrożeniu. Ujawniają się tygodnie lub miesiące później – po aktualizacji platformy, po dodaniu nowych produktów, po zmianie struktury URL. Dlatego hreflang to nie jest zadanie do odhaczenia raz na zawsze. To element, który wymaga regularnego monitoringu – o czym dokładnie w następnej sekcji.
Jak sprawdzić poprawność hreflang po usunięciu raportu z Google Search Console?
Google już kilka lat temu usunął raport „Targetowanie międzynarodowe” z Google Search Console. Przez lata był to podstawowe narzędzie do monitorowania błędów hreflang – pokazywał liczbę błędów, typy problemów i dotknięte URL-e. Zniknął bez bezpośredniego zamiennika.
Dla wielu właścicieli sklepów to oznacza jedno: wdrożyli hreflang, nie mają już gdzie sprawdzić, czy działa. I przez miesiące nie wiedzą, że coś jest nie tak – dopóki nie zauważą spadku ruchu z Niemiec w Google Analytics.
Dobra wiadomość: narzędzia zastępcze istnieją i w kilku przypadkach dają więcej informacji niż stary raport GSC. Poniżej kompletny zestaw – z opisem, co każde narzędzie pokazuje i kiedy po nie sięgać.
Narzędzie 1: Screaming Frog SEO Spider
Screaming Frog to najdokładniejsze narzędzie do audytu hreflang dla sklepów e-commerce. Crawluje Twoją stronę tak jak Google i analizuje każdy tag hreflang na każdej podstronie.
Co wykrywa: brak tagów zwrotnych (no return tag), hreflangi prowadzące do stron 404 lub przekierowań, błędne kody języka i regionu, brak self-referencing, niezgodności między hreflangiem a tagiem canonical, hreflangi na stronach noindex.
Jak uruchomić audyt hreflang w Screaming Frog:
- Otwórz Screaming Frog → Configuration → Spider → Crawl → upewnij się, że opcja „Follow Internal Links” jest włączona
- Wpisz URL sklepu i uruchom crawl
- Po zakończeniu przejdź do zakładki Hreflang w górnym menu
- Sprawdź podzakładki: hreflang Language Codes (błędne kody), hreflang Return Links (brak tagów zwrotnych), hreflang Conflicts (konflikty z canonical)
- Eksportuj wyniki do CSV i filtruj według typu błędu
Bezpłatna wersja Screaming Frog crawluje do 500 URL-i. Przy sklepie z tysiącami produktów potrzebujesz wersji płatnej (£259 rocznie).
Narzędzie 2: Google Search Console – Inspect URL
Stary raport GSC zniknął, ale funkcja „Sprawdź URL” pozostała i daje informacje na poziomie pojedynczej podstrony.
Jak sprawdzić hreflang dla konkretnego URL:
- Wejdź do Google Search Console → wpisz URL w pasku „Sprawdź dowolny URL”
- Kliknij „Wyświetl stronę zbadaną przez Google”
- W sekcji Więcej informacji znajdź zakładkę z danymi o stronie – Google pokazuje, jak widzi tagi na tej konkretnej podstronie w momencie ostatniego crawlowania
- Sprawdź, czy hreflangi są obecne i czy wskazują na właściwe URL-e
Inspect URL nie daje widoku na cały sklep – musisz sprawdzać podstrony pojedynczo. Przydaje się do szybkiej weryfikacji po wdrożeniu lub do diagnozowania konkretnej podstrony, na której podejrzewasz problem.
Narzędzie 3: Merkle Hreflang Tag Testing Tool
Darmowe narzędzie online od Merkle pozwala sprawdzić hreflangi dla pojedynczego URL-a bez konieczności crawlowania całego sklepu. Wystarczy wkleić adres strony – narzędzie pobiera jej kod i analizuje wszystkie tagi hreflang, sprawdzając wzajemność linków między wersjami językowymi.
Adres: technicalseo.com/tools/hreflang/
Co pokazuje: listę wszystkich tagów hreflang na podanej stronie, status każdej strony wskazanej w tagach (200, 404, redirect), czy tagi zwrotne istnieją i są poprawne, ostrzeżenia przy błędnych kodach ISO.
Narzędzie 4: Ahrefs Site Audit
Jeśli korzystasz z Ahrefs, moduł Site Audit ma dedykowany raport dla hreflangów. Crawluje cały sklep i grupuje błędy według typów. Gdzie znaleźć raport: Site Audit → All Issues → filtruj według „hreflang”.
Ahrefs wykrywa te same typy błędów co Screaming Frog, ale dodatkowo pokazuje, jak zmieniała się liczba błędów w kolejnych crawlach – co pozwala śledzić, czy wdrożone poprawki faktycznie działają.
Narzędzie 5: Semrush Site Audit
Semrush Site Audit wykrywa błędy hreflang i prezentuje je w raporcie „International SEO”. Dodatkowa wartość: Semrush porównuje hreflangi z danymi z indeksu Google i sygnalizuje rozbieżności między tym, co jest w kodzie, a tym, co Google faktycznie zaindeksował.
Kiedy sięgać po które narzędzie?
| Sytuacja | Rekomendowane narzędzie | Dlaczego |
| Pełny audyt hreflang po wdrożeniu | Screaming Frog | Najdokładniejszy, crawluje wszystkie podstrony |
| Szybka weryfikacja pojedynczej strony | Merkle Hreflang Tool | Darmowe, natychmiastowe, bez instalacji |
| Sprawdzenie jak Google widzi konkretną stronę | GSC Inspect URL | Pokazuje dane z perspektywy Googlebota |
| Regularny monitoring całego sklepu | Ahrefs lub Semrush Site Audit | Historia błędów, śledzenie zmian w czasie |
| Sklep po migracji lub zmianie struktury URL | Screaming Frog + GSC Inspect URL | Kombinacja daje najpełniejszy obraz |
| Podejrzenie błędu po aktualizacji platformy | Merkle + Screaming Frog | Szybka diagnoza, potem głębszy audyt |
Jak zbudować proces monitoringu hreflang?
Jednorazowy audyt po wdrożeniu nie wystarczy. Hreflang w sklepie e-commerce zmienia się przy każdej aktualizacji katalogu, każdej zmianie struktury URL i każdej aktualizacji platformy lub wtyczek. Błędy wracają – i zazwyczaj wracają cicho.
Co miesiąc: uruchom crawl w Screaming Frog lub Ahrefs Site Audit i sprawdź liczbę błędów hreflang. Jeśli liczba rośnie – diagnozuj przed kolejnym crawlem.
Po każdej większej aktualizacji katalogu: sprawdź w Merkle kilka nowych kart produktów i kategorii, które właśnie dodałeś. Upewnij się, że platforma wygenerowała poprawne tagi dla nowych URL-i.
Po każdej aktualizacji platformy lub wtyczek: uruchom pełny crawl Screaming Frog. Aktualizacje WooCommerce, WPML czy szablonu potrafią nadpisać konfigurację hreflang – widziałem to wielokrotnie. To jedna z tych rzeczy, która wychodzi dopiero po tygodniu, gdy ruch z Niemiec zaczyna spadać bez wyraźnej przyczyny.
Co kwartał: sprawdź w GSC Inspect URL kilka kluczowych podstron – strony główne wersji językowych, 3-5 najważniejszych kategorii, 5-10 bestselerów. Upewnij się, że Google widzi te tagi tak samo jak Ty.
Hreflang a AI Overviews – czy poprawne tagi wpływają na widoczność w AI Search?
Krótka odpowiedź: hreflang nie jest bezpośrednim czynnikiem decydującym o tym, czy Twój sklep pojawi się w AI Overview. Ale pośrednio – i to w kilku istotnych miejscach – ma znaczenie.
Systemy AI Search, takie jak Google AI Mode, Perplexity czy ChatGPT Search, działają według podobnego mechanizmu: rozbijają zapytanie użytkownika na szereg sub-zapytań (Query Fan-Out), pobierają fragmenty treści z wielu źródeł i syntetyzują odpowiedź. Kluczowe pytanie dla właściciela sklepu brzmi: z której wersji językowej pobierają dane?
I tu hreflang wchodzi do gry.
Jak AI Search dobiera wersję językową treści?
Google AI Mode – podobnie jak klasyczne wyniki organiczne – kieruje się językiem zapytania i lokalizacją użytkownika. Jeśli ktoś wpisuje zapytanie po niemiecku z Niemiec, system szuka treści oznaczonych jako przeznaczone dla tego rynku. Hreflang jest jednym z sygnałów, które pomagają Google zidentyfikować właściwą wersję językową jako źródło dla AI Overview.
Sklep bez hreflangu lub z błędnie wdrożonymi tagami ryzykuje, że Google AI Mode pobierze treść z niewłaściwej wersji językowej – albo w ogóle pominie sklep jako źródło, bo nie może jednoznacznie przypisać go do rynku niemieckiego. W klasycznym SEO skutek to niższa pozycja w organicu. W AI Search skutek jest bardziej radykalny: albo jesteś cytowany, albo Cię nie ma.
Trzy połączenia między hreflang a AI Search
Połączenie 1 – Chunk Independence i wersja językowa
Systemy RAG (Retrieval-Augmented Generation), na których opierają się AI Overviews, pobierają fragmenty treści (tzw. chunk’i) i oceniają ich przydatność do odpowiedzi na zapytanie. Fragment treści po niemiecku, na stronie oznaczonej jako de-DE, z poprawnym hreflangiem i canonical self-referencing, jest dla algorytmu jednoznacznym sygnałem: to treść dla rynku niemieckiego. Fragment bez hreflanga – niejednoznacznym.
Im więcej sygnałów technicznych potwierdza przynależność treści do konkretnego rynku językowego, tym wyższe prawdopodobieństwo, że AI system wybierze właśnie ten chunk jako źródło cytowania.
Połączenie 2 – Indeksacja jako warunek konieczny
AI Overview cytuje wyłącznie treści, które są zaindeksowane. Błędny hreflang w połączeniu z konfliktem canonical potrafi wypchnąć całą wersję językową sklepu z indeksu Google – co automatycznie wyklucza ją z puli źródeł AI Search. Zanim zaczniesz optymalizować treści pod AI Overviews, upewnij się, że wersja DE Twojego sklepu jest w indeksie. Sprawdź to w GSC Inspect URL dla kilku kluczowych podstron.
Połączenie 3 – Autorytet tematyczny wersji językowej
Google buduje obraz autorytetu tematycznego witryny osobno dla każdej wersji językowej. Sklep z poprawnie wdrożonym hreflangiem, unikatową treścią w każdej wersji językowej i spójną strukturą techniczną buduje autorytet w wersji DE niezależnie od wersji PL. To przekłada się na wyższe prawdopodobieństwo cytowania przez AI Overview dla zapytań z rynku niemieckiego.
Sklep, który ma jedną wersję DE opartą na automatycznym tłumaczeniu, bez hreflangu, z canonicalem wskazującym na wersję PL – buduje autorytet wyłącznie w wersji PL. Dla Google AI Mode wersja DE praktycznie nie istnieje.
Co zrobić, żeby wersja DE Twojego sklepu była widoczna w AI Search?
| Działanie | Połączenie z AI Search | Priorytet |
| Poprawny hreflang de-DE (lub de-AT/de-CH) | Jednoznaczna identyfikacja wersji językowej jako źródła dla rynku DE | Krytyczny |
| Canonical self-referencing na każdej podstronie DE | Wersja DE w indeksie = dostępna dla AI Overview | Krytyczny |
| Unikatowa treść w wersji DE (nie tłumaczenie automatyczne) | Wyższa jakość chunka = wyższe prawdopodobieństwo cytowania | Wysoki |
| Answer-first w treści kategorii i opisach produktów | Struktura odpowiadająca Query Fan-Out AI systemów | Wysoki |
| Schema markup Product/FAQPage na podstronach DE | Dodatkowe sygnały strukturalne dla parsera AI | Wysoki |
| Regularne linkowanie wewnętrzne w wersji DE | Budowanie autorytetu tematycznego wersji językowej | Średni |
| Monitorowanie widoczności w GSC dla wersji DE osobno | Wczesne wykrywanie problemów z indeksacją | Średni |
Jak monitorować widoczność AI dla wersji DE?
Google Search Console od 2024 roku pokazuje dane o kliknięciach i wyświetleniach z AI Overviews jako osobny typ wyniku wyszukiwania. Żeby sprawdzić, czy Twoja wersja DE pojawia się w AI Search:
- Wejdź do GSC → Wyniki wyszukiwania
- Kliknij Typ wyszukiwania → wybierz Sieć
- Kliknij Nowy → Kraj → dodaj filtr dla Niemiec (DE)
- W sekcji Wygląd w wynikach wyszukiwania sprawdź, czy pojawia się typ „Omówienie AI”
Jeśli widzisz wyświetlenia z Niemiec w AI Overviews – Twoja wersja DE jest cytowana. Jeśli nie – sprawdź w pierwszej kolejności poprawność hreflangów i indeksację wersji DE, zanim zaczniesz szukać problemów po stronie treści.
Sklepy, które zadbały o techniczną poprawność wersji DE – hreflang, canonical, indeksacja, unikatowa treść – mają znacznie wyższy udział w cytowaniach AI Overview dla zapytań z Niemiec niż sklepy, które przetłumaczyły treści i uznały sprawę za zamkniętą. AI Search nie różni się od klasycznego SEO w tym sensie, że techniczna solidność fundamentów nadal decyduje o tym, kto jest widoczny, a kto nie.
Hreflang w niemieckim sklepie internetowym – FAQ
Czy hreflang wpływa na pozycję w Google?
Hreflang nie jest bezpośrednim czynnikiem rankingowym – nie podnosi pozycji strony w wynikach wyszukiwania. Jego rola polega na tym, że Google wyświetla właściwą wersję językową właściwym użytkownikom. Pośrednio przekłada się to na niższy współczynnik odrzuceń i wyższy CTR, co może wpłynąć na rankingi.
Co się stanie, jeśli nie wdrożę hreflang w sklepie z wersją niemiecką?
Google samodzielnie zdecyduje, którą wersję wyświetlić – i często wybierze błędnie. Klient z Niemiec może trafiać na polską wersję sklepu, co zwiększa współczynnik odrzuceń i zmniejsza konwersje. Dodatkowo Google może traktować obie wersje jako duplikaty treści, co negatywnie wpływa na indeksację.
Jaka jest różnica między de, de-DE i de-AT?
de oznacza język niemiecki bez określonego regionu – Google wyświetli tę wersję wszystkim użytkownikom niemieckojęzycznym, dla których nie ma lepszego dopasowania. de-DE to wersja dla Niemiec, de-AT dla Austrii. Jeśli masz osobne wersje dla różnych krajów DACH, stosuj kody regionalne. Jeśli masz jedną wersję dla całego obszaru niemieckojęzycznego – wystarczy sam de.
Czy hreflang wystarczy ustawić tylko na stronie głównej?
Nie. Hreflang musi być na każdej podstronie, która ma swój odpowiednik w innej wersji językowej. Google łączy konkretne pary URL – nie całe domeny. Strona główna bez tagów na podstronach produktów i kategorii to implementacja, która praktycznie nie działa.
Jak hreflang działa w połączeniu z rel=canonical?
Każda wersja językowa powinna mieć canonical wskazujący na samą siebie (self-referencing). Ustawienie canonicala z wersji DE na wersję PL powoduje, że Google traktuje wersję DE jako nieskanoniczną i ignoruje jej hreflangi. To jeden z najczęstszych i najbardziej destrukcyjnych błędów w e-commerce.
Jak sprawdzić hreflang po usunięciu raportu z Google Search Console?
Raport „Targetowanie międzynarodowe” został usunięty z GSC. Zamiast niego używaj: Screaming Frog do pełnego audytu całego sklepu, Merkle Hreflang Tag Testing Tool do weryfikacji pojedynczych URL-i, GSC Inspect URL do sprawdzenia jak Google widzi konkretną stronę, Ahrefs lub Semrush Site Audit do regularnego monitoringu z historią zmian.
Czy hreflang trzeba dodawać do każdej karty produktu?
Tak – jeśli każda karta produktu ma swój odpowiednik w innej wersji językowej. Wyjątek stanowią strony wariantów produktów (kolor, rozmiar), które mają canonical wskazujący na stronę kanoniczną produktu. Na nich hreflang umieszcza się tylko na stronach kanonicznych, nie na wariantach.
Jak wdrożyć hreflang w sklepie na WooCommerce?
WooCommerce nie obsługuje hreflangów natywnie. Potrzebujesz wtyczki: WPML (od 159 USD rocznie) dla dużych sklepów z rozbudowanym katalogiem, Polylang Pro (~99 EUR rocznie) dla średnich sklepów, lub TranslatePress (od 99 EUR rocznie) dla małych sklepów z prostą strukturą. Po instalacji każda z nich generuje hreflangi automatycznie po skonfigurowaniu wersji językowych.
Czym jest x-default i kiedy go stosować?
x-default to tag hreflang wskazujący wersję strony dla użytkowników, których język lub region nie pasuje do żadnej innej wersji językowej w zestawie. Nie jest obowiązkowy, ale Google go zaleca. W praktyce e-commerce: ustaw x-default na stronę wyboru języka lub na wersję obsługującą największy ruch. Unikaj wskazywania x-default na stronę po niemiecku – użytkownicy z innych krajów będą ją natychmiast opuszczać.
Czy hreflang pomaga w AI Overviews i AI Search?
Pośrednio tak. Hreflang pomaga Google jednoznacznie zidentyfikować, która wersja językowa sklepu jest przeznaczona dla rynku niemieckiego. Systemy AI Search (Google AI Mode, Perplexity, ChatGPT Search) pobierają treści z zaindeksowanych stron – jeśli wersja DE jest poza indeksem z powodu błędów hreflang lub konfliktu z canonical, AI Overview jej nie zacytuje. Poprawna implementacja hreflang to warunek konieczny widoczności w AI Search dla rynku DACH.
