Hreflang i międzynarodowe SEO — wielojęzyczna widoczność w Google i w modelach AI

W międzynarodowym SEO najwięcej szkód robi jedno nieporozumienie: że hreflang podnosi pozycje. Nie podnosi. Hreflang to dyrektywa routingu — mówi Google, którą wersję językową pokazać któremu użytkownikowi, a nie która strona ma rankować wyżej. Mimo to jego błędy są najczęstszą wpadką wielojęzycznych witryn: audyty regularnie znajdują niekompletne albo niewzajemne adnotacje na większości dużych serwisów, a skutek jest zawsze ten sam — Google pokazuje Polakowi angielską wersję, konwersja spada, a Ty szukasz przyczyny w treści, nie w nagłówku.

Hreflang to nie czynnik rankingowy, lecz routing języków — a jego błędy to najczęstsza wpadka wielojęzycznego SEO, którą audyty znajdują na większości dużych witryn. W erze AI dochodzi druga stawka: ChatGPT i Perplexity na to samo pytanie po polsku i po angielsku cytują inne źródła. Kompletny warsztat: trzy architektury adresów, pięć zasad hreflang bez błędów, tłumaczenie slugów i wielojęzyczne GEO.

W erze AI dochodzi druga stawka, o której klasyczne poradniki milczą: modele językowe traktują język zapytania jako sygnał źródła. To samo pytanie zadane ChatGPT po polsku i po angielsku zwraca inne cytowania — bo model sięga po treści w języku pytania. Wielojęzyczna architektura przestała więc być tylko sprawą Google; decyduje też o tym, czy Cię w ogóle widać w polskiej i angielskiej odpowiedzi AI.

Ten wpis to kompletny warsztat: czym hreflang jest naprawdę, jak wybrać architekturę adresów, pięć zasad wdrożenia bez błędów, tłumaczenie slugów (na naszym własnym wzorcu PL/EN) i wielojęzyczne GEO.

Czym hreflang jest — i czym nie jest

Zacznijmy od rozdzielenia dwóch rzeczy, które w głowach się zlepiają.

Hreflang nie jest czynnikiem rankingowym. Nie sprawia, że strona rankuje wyżej, nie przekazuje „mocy", nie zastępuje linkowania ani treści. Google w dokumentacji opisuje go jako sygnał, a nie wiążącą dyrektywę — może go zignorować, jeśli reszta sygnałów mówi co innego.

Hreflang jest mapą wersji językowych. Dla strony dostępnej w kilku językach lub regionach mówi wyszukiwarce: „to są warianty tej samej treści, pokaż użytkownikowi właściwy". Efekt nie jest w rankingu, lecz w tym, że właściwa wersja trafia do właściwego użytkownika — co ratuje CTR i konwersję, a nie pozycję.

Dwa najczęstsze objawy braku lub błędu hreflang:

• Zła wersja w wynikach. Polak widzi angielski URL, klika rzadziej, a jeśli kliknie — odbija się. Google to widzi i z czasem obniża widoczność całej sekcji.
• Kanibalizacja między językami. Bez mapowania Google traktuje wersje jak konkurujące strony o ten sam temat i sam wybiera „zwycięzcę" — często nie tę, którą chcesz.

Trzy architektury adresów — ccTLD, subdomena, subfolder

Zanim dotkniesz hreflang, musisz zdecydować, gdzie w ogóle mieszkają wersje językowe. To decyzja na lata — zmiana architektury to pełna migracja z ryzykiem utraty pozycji.

Dla zdecydowanej większości firm — zwłaszcza tych, które celują w widoczność w AI — subfolder wygrywa. Powód jest ten sam co przy budżecie crawlowania: jedna domena kumuluje cały autorytet i cały sygnał encji, zamiast rozpraszać go na osobne hosty. ccTLD ma sens, gdy naprawdę działasz lokalnie w danym kraju (magazyn, obsługa, waluta) i stać Cię na utrzymanie kilku domen jak osobnych serwisów. To jest dokładnie nasz wybór na tej stronie: jedna domena, wersje w /pl/ i /en/.

Pięć zasad hreflang bez błędów

Hreflang psuje się na detalach. Te pięć zasad eliminuje większość problemów, które audyty wyłapują na dużych witrynach.

1. 1.Wzajemność. Jeśli strona PL wskazuje na EN, to EN musi wskazać z powrotem na PL. Jednostronna adnotacja jest przez Google ignorowana — to najczęstszy błąd w audytach.
2. 2.Self-referencing. Każda wersja musi wskazywać także samą siebie. Strona PL wśród swoich adnotacji hreflang wymienia również PL.
3. 3.x-default. Dodaj wpis hreflang="x-default" wskazujący wersję domyślną (zwykle angielską albo stronę wyboru języka) dla użytkowników spoza zdefiniowanych języków.
4. 4.Adresy bezwzględne i po 301. URL-e w hreflang muszą być pełne (z https://) i prowadzić do finalnego adresu, nie do przekierowania. Wskazanie na URL, który robi 301, łamie mapowanie.
5. 5.Zgodność z canonical. hreflang i canonical nie mogą sobie przeczyć: strona PL ma canonical na samą siebie, nie na EN. Sprzeczność to klasyczny powód, dla którego Google ignoruje całą grupę.

Poprawny zestaw dla dwóch języków wygląda tak — te same trzy linki w sekcji head każdej z wersji:

<link rel="alternate" hreflang="pl" href="https://twojadomena.pl/pl/oferta" /><link rel="alternate" hreflang="en" href="https://twojadomena.pl/en/offer" /><link rel="alternate" hreflang="x-default" href="https://twojadomena.pl/en/offer" />

Kody języków trzymaj zgodne ze standardem BCP 47 (ISO 639-1 dla języka, opcjonalnie ISO 3166-1 dla regionu): „pl", „en", a jeśli rozróżniasz regiony — „en-GB", „en-US", „pt-BR". Nie wymyślaj własnych kodów; „en-UK" jest niepoprawne (poprawnie: „en-GB").

Tłumaczenie slugów — nasz wzorzec PL/EN

Częste pytanie: tłumaczyć slug (część adresu po domenie), czy zostawić jeden dla wszystkich języków? Tłumaczyć. Slug w języku użytkownika to sygnał trafności dla wyszukiwarki i wyższy CTR — Polak chętniej klika /pl/hreflang-miedzynarodowe-seo-geo niż /pl/international-seo.

Problem w tym, że przetłumaczone slugi trzeba ze sobą powiązać, żeby hreflang i przełącznik języka wiedziały, co jest czym. Nasz wzorzec na tej stronie: każdy wpis ma jeden numeryczny identyfikator, a slugi są tłumaczone per język i parowane właśnie po nim. Angielski odpowiednik tego wpisu to hreflang-international-seo-geo — inny slug, ten sam identyfikator. Przełącznik języka rozwiązuje parę po identyfikatorze, a nie po dopasowaniu tekstu adresu, dzięki czemu tłumaczenie slugów niczego nie psuje.

To samo dotyczy encji marki: spójna architektura języków wzmacnia graf wiedzy i encję, bo Google i modele AI widzą jedną markę w wielu językach, a nie kilka niepowiązanych bytów.

Wielojęzyczne GEO — dlaczego AI cytuje inne źródła per język

Tu zaczyna się część, której nie ma w klasycznych poradnikach hreflang. Modele językowe traktują język zapytania jako filtr źródeł. Zapytaj ChatGPT o „najlepsze narzędzia do czegoś" po polsku, a potem po angielsku — dostaniesz dwie różne listy cytowań, bo model preferuje treści w języku pytania.

Konsekwencje dla strategii:

• Sama wersja EN nie da Ci widoczności w polskich odpowiedziach AI. Jeśli cała ekspercka treść jest po angielsku, w polskim ChatGPT jesteś niewidoczny — model cytuje polskie źródła konkurencji.
• Tłumaczenie to nie maszynowa kalka. Modele i Google nagradzają treść, która brzmi natywnie i jest osadzona w lokalnym kontekście — przykłady, waluta, realia rynku. Automatyczne tłumaczenie bez redakcji to sygnał niskiej jakości.
• Struktura pod cytowania działa w każdym języku. Zasady z wpisu o optymalizacji pod AI Overviews — odpowiedź wprost, nagłówki-pytania, dane z atrybucją — stosuj w każdej wersji językowej osobno.

Innymi słowy: hreflang załatwia stronę techniczną (właściwa wersja do właściwego użytkownika), ale o cytowaniach w AI decyduje to, czy w danym języku w ogóle masz mocną, natywną treść.

Jak zweryfikować wdrożenie

Zanim uznasz temat za zamknięty, sprawdź cztery rzeczy:

• Search Console → raport międzynarodowego targetowania i błędów hreflang — pokazuje brakujące zwrotne adnotacje i błędne kody języków.
• Ręczny test w źródle strony — otwórz podgląd HTML bez renderowania JS i sprawdź, czy linki hreflang są w sekcji head. Jeśli wstrzykujesz je JavaScriptem, część crawlerów ich nie zobaczy — to ten sam problem, co w JavaScript SEO.
• Crawler (Screaming Frog / Sitebulb) — raport hreflang wychwytuje niewzajemne i niekanoniczne wskazania na skalę całej witryny.
• Test AI per język — zadaj to samo pytanie modelom po polsku i po angielsku i sprawdź, czy cytują Twoje właściwe wersje. To pomiar warstwy, której nie widać w GA4 — jak go poukładać, opisuję w analityce ruchu z AI.

Plan wdrożenia krok po kroku

1. 1.Wybierz architekturę (subfolder dla większości) i trzymaj się jej na całej witrynie.
2. 2.Ustal listę języków i regionów oraz poprawne kody BCP 47 — bez własnych wynalazków.
3. 3.Wygeneruj hreflang programowo z jednego źródła prawdy (mapa identyfikator → slug per język), a nie ręcznie per strona.
4. 4.Dodaj x-default i self-referencing do każdej grupy.
5. 5.Zsynchronizuj canonical — każda wersja kanoniczna na samą siebie.
6. 6.Przetłumacz slugi i powiąż je po stałym identyfikatorze (nasz wzorzec).
7. 7.Zredaguj treść natywnie per język — nie kalkę maszynową; osobno zoptymalizuj każdą wersję pod cytowania AI.
8. 8.Zweryfikuj w GSC, w źródle bez JS, crawlerem i testem AI per język.
9. 9.Przy każdej migracji aktualizuj hreflang w tym samym wdrożeniu — przestarzałe wskazania do starych adresów łamią mapowanie.

---

Projektuję architekturę wielojęzyczną od wyboru domeny po hreflang generowany z jednego źródła prawdy — w ramach technicznego SEO i optymalizacji pod AI (GEO). Uczę tego w kursie SEO & GEO. Napisz do mnie — zacznę od audytu hreflang i mapy języków pod widoczność w AI.

Warto przeczytać dalej:

• Migracja strony bez utraty pozycji w Google
• Entity SEO i graf wiedzy — pozycjonowanie semantyczne encji
• Google AI Overviews i AI Mode — jak zoptymalizować stronę, żeby AI Cię cytowało
• Jak mierzyć ruch z ChatGPT, Perplexity i AI Mode