Hreflang w wyszukiwarkach AI: dlaczego tagi dla DACH są prawie ignorowane

Hreflang uchodzi za standardowe narzędzie dla wielojęzycznych i wieloregionalnych witryn. W regionie DACH (Niemcy, Austria, Szwajcaria) ma zapewniać, że austriaccy użytkownicy zobaczą wersję de-AT, niemieccy wersję de-DE, a szwajcarscy wersję de-CH. Ta logika działa w klasycznej wyszukiwarce Google, ale napotyka nową granicę: platformy AI, takie jak ChatGPT, Perplexity, Copilot i Claude, w dużej mierze nie uwzględniają adnotacji hreflang. Ten artykuł wyjaśnia, jak poprawnie skonfigurować hreflang dla DACH, dlaczego crawlery AI ignorują te sygnały i jak mimo to sprawić, by Twoje treści de-AT były widoczne w odpowiedziach AI i w klasycznym wyszukiwaniu.

Dlaczego hreflang ma znaczenie dla DACH i gdzie przebiega nowa granica

Region DACH to szczególny przypadek: trzy kraje, jeden język, ale różne rynki, ceny, systemy prawne i częściowo odmienne pojęcia. Właśnie tu wkracza hreflang. Informuje wyszukiwarki, który adres URL jest przeznaczony dla jakiej kombinacji języka i regionu, dzięki czemu Google wyświetla w Austrii stronę de-AT, a w Niemczech stronę de-DE.

Rynek austriacki jest niemal w pełni cyfrowy. Na początku 2025 roku z internetu korzystało 8,69 miliona osób w Austrii, przy wskaźniku penetracji 95,3% (Austria). Kto kieruje ofertę na ten rynek z własną lokalizacją de-AT, ma uzasadniony interes w tym, by wyświetlana była właściwa wersja, w Google, a coraz częściej także w systemach AI.

Właśnie tam zmieniają się reguły gry. Hreflang przestaje działać jak twarde ograniczenie, gdy treści trafiają do użytkowników za pośrednictwem AI. Popularność takiego wyszukiwania z AI da się zmierzyć: w Niemczech 50% internautów przynajmniej okazjonalnie korzysta z czatów AI zamiast klasycznych wyszukiwarek (Niemcy), a 42% tych osób otrzymało już od AI fałszywe lub zmyślone informacje (Niemcy). Niewłaściwe wersje językowe są częścią tego problemu: jeśli system podaje treści de-DE w odpowiedzi na zapytanie z Austrii, ceny, stawki VAT czy pojęcia prawne często się nie zgadzają.

Podstawy hreflang dla DACH: poprawna adnotacja i obowiązek wzajemności

Poprawne wdrożenie hreflang dla regionu DACH opiera się na jasnych zasadach. Kody języka i regionu łączą ISO 639-1 (język) z ISO 3166-1 Alpha-2 (region).

• Poprawne kody języka i regionu: de-DE dla Niemiec, de-AT dla Austrii, de-CH dla Szwajcarii. Samo de bez regionu jest skierowane do wszystkich niemieckojęzycznych użytkowników niezależnie od kraju i może mieć sens jako dodatkowa, ogólna wersja.
• x-default jako wariant zapasowy: Wartość x-default oznacza stronę wyświetlaną wtedy, gdy żadna inna wersja nie pasuje, na przykład dla niemieckojęzycznych użytkowników spoza DACH albo dla strony wyboru języka. x-default to element, którego brakuje najczęściej.
• Samoodwołanie: Każda strona musi odwoływać się przez hreflang także do samej siebie. Strona de-AT wymienia więc de-DE i de-CH, a do tego samą siebie jako de-AT.
• Wzajemne odwołania (obowiązek odwołania zwrotnego): Hreflang działa dwukierunkowo. Jeśli strona de-DE wskazuje na stronę de-AT, strona de-AT musi wskazywać z powrotem na stronę de-DE. Jeśli brakuje odwołania zwrotnego, Google ignoruje adnotację.

Minimum dla DACH obejmuje więc de-DE, de-AT, de-CH i x-default, każdy z kompletnymi, wzajemnymi i samoodwołującymi się tagami. Mimo tych jasnych zasad hreflang jest podatny na błędy. Międzynarodowa analiza 374 756 domen wykazała, że 67% z nich ma co najmniej jeden problem z wdrożeniem hreflang (międzynarodowe). Najczęstsze błędy: w 56,3% przypadków brakuje x-default, w 18% brakuje samoodwołujących się tagów, a w 16,9% tagi hreflang wskazują na przekierowane lub niedziałające strony (międzynarodowe).

Dlaczego crawlery AI w dużej mierze ignorują hreflang

Kluczowa różnica między Google a platformami AI tkwi w przetwarzaniu. Google renderuje strony, wykonuje JavaScript i na podstawie hreflang, lokalizacji oraz ustawień językowych wybiera wersję językowo-regionalną. Crawlery AI tego nie robią.

Analiza ruchu crawlerów w sieci Vercel pokazuje, że żaden z dużych crawlerów AI nie renderuje JavaScriptu (międzynarodowe). GPTBot, OAI-SearchBot, ClaudeBot i PerplexityBot pobierają treści, ale ich nie wykonują. Sam GPTBot wygenerował w ciągu miesiąca 569 milionów żądań w tej sieci (międzynarodowe). Niektóre crawlery wprawdzie pobierają pliki JavaScript, w przypadku ChatGPT pliki JS stanowią 11,50% żądań, a w przypadku Claude 23,84% (międzynarodowe), ale brakuje im środowiska renderującego, by je wykonać. Szersze badanie 23 dużych crawlerów AI prowadzi do tego samego wniosku: 69% crawlerów AI nie potrafi wykonywać JavaScriptu (międzynarodowe), w tym wprost GPTBot i ClaudeBot.

Wynikają z tego trzy konsekwencje dla hreflang:

• Brak renderowania JS: Sygnały hreflang, które trafiają do DOM dopiero za sprawą JavaScriptu po stronie klienta, są dla crawlerów AI niewidoczne. Widzą one tylko początkowy HTML.
• Brak wyboru wersji locale: Platformy AI nie interpretują hreflang jako mechanizmu wyboru. Przetwarzają adres URL, który właśnie pobrały, nie szukając aktywnie wersji de-AT dla adresu de-DE.
• Wskazówka zamiast ograniczenia: To, co w Google jest słabą wskazówką, w wyszukiwaniu za pośrednictwem AI praktycznie przestaje działać. Platforma podaje wersję, którą zaindeksowała, niekoniecznie tę właściwą dla regionu.

Ważna jest też pozytywna strona: treści w początkowym HTML, w tym osadzone dane JSON czy komponenty renderowane po stronie serwera, mogą zostać zaindeksowane, ponieważ modele AI interpretują także treści inne niż HTML. Dźwignia nie leży więc w hreflang, tylko w tym, by właściwy sygnał językowy zapisać bezpośrednio w dostarczanym HTML.

content-language dla Bing i Copilota

Rozpowszechnionym błędem jest przekonanie, że hreflang działa tak samo we wszystkich wyszukiwarkach. Według własnych deklaracji Bing traktuje hreflang tylko jako słaby sygnał (międzynarodowe) i rozpoznaje język głównie na podstawie sygnału content-language, linków i pochodzenia odwiedzających. W regionie DACH to nie jest temat poboczny: w Austrii Bing z udziałem w rynku 9,01% zajmuje wyraźnie drugie miejsce za Google z 81,87% (Austria, maj 2026). Ponieważ Microsoft Copilot opiera się na indeksie Bing, sygnał content-language oddziałuje także na ten system AI.

• Poprawny format ll-cc: Również content-language korzysta ze schematu język-region, na przykład de-AT. Kilka wartości podaje się po przecinku.
• Spójność na wszystkich poziomach: Content-Language w nagłówku HTTP, atrybut lang elementu html i uzupełniające metadane powinny mieć tę samą wartość, aby Bing nie otrzymywał sprzecznych sygnałów językowych.
• Nie zapominaj o atrybucie lang: Atrybut lang="de-AT" w tagu html to najprostszy i najbardziej niezawodny sygnał językowy on-page. Znajduje się w początkowym HTML, więc jest widoczny dla crawlerów, które nie renderują JS.

W praktyce oznacza to, że kto udostępnia wersje dla DACH, powinien równolegle utrzymywać hreflang dla Google oraz content-language i poprawny atrybut lang dla Bing, Copilota i crawlerów AI.

Hreflang jako wskazówka, a nie dyrektywa

Nawet w Google hreflang nie jest poleceniem. Google wprost określa tagi hreflang jako wskazówki, a nie dyrektywy (międzynarodowe). John Müller z Google wyjaśnia, że hreflang nie gwarantuje indeksowania i że przy niemal identycznych wersjach Google często wybiera jedną z nich jako kanoniczną.

Dla DACH ma to szczególne znaczenie. Wersje de-DE, de-AT i de-CH są pod względem językowym często niemal identyczne. Jeśli dwie wersje mają tę samą treść, Google przy wersjach w tym samym języku zwykle wybiera jedną jako kanoniczną, bo jego systemy upraszczają sprawę (międzynarodowe). W efekcie strona de-AT może wypaść z indeksu, mimo że adnotacja hreflang jest technicznie poprawna.

Pomaga tu rzeczywiste zróżnicowanie. Im bardziej wersja de-AT różni się treścią, tym większa szansa, że Google potraktuje ją jako samodzielną stronę:

• Samodzielne treści: Austriackie ceny w euro z właściwą stawką VAT, lokalne osoby kontaktowe, austriackie pojęcia prawne i referencje z rynku austriackiego.
• Lokalne pojęcia i pisownia: Tam, gdzie niemiecki w Austrii się różni, tekst powinien to odzwierciedlać. Wzmacnia to jednocześnie trafność i odróżnienie od innych wersji.
• Osobny adres URL dla każdej wersji: Wyraźnie oddzielony adres URL dla każdej wersji to warunek, by dana wersja w ogóle mogła zostać zaindeksowana i przywołana w systemach AI.

Porównanie metod implementacji i ich widoczność w AI

Hreflang można wdrożyć na trzy sposoby. Dla crawlerów AI kluczowe jest to, czy sygnał znajduje się w początkowym HTML.

• Elementy link HTML w sekcji head: Adnotacje hreflang są umieszczone jako tagi link w sekcji head. Jeśli są renderowane po stronie serwera, znajdują się w początkowym HTML i są widoczne dla wszystkich crawlerów. Dla DACH ta metoda jest najbardziej przejrzysta.
• Nagłówek HTTP: Hreflang można przekazywać w nagłówku HTTP Link, przede wszystkim dla dokumentów innych niż HTML, takich jak pliki PDF. Nagłówek jest widoczny niezależnie od crawlera, ale w praktyce trudniej go utrzymać.
• Mapa witryny XML: Hreflang można w całości odwzorować w mapie witryny XML. Dzięki temu kod HTML pozostaje odchudzony, ale w wyszukiwaniu za pośrednictwem AI ma to wadę: sygnał nie znajduje się na samej stronie. Crawler AI, który pobiera adres URL bezpośrednio, bez analizy mapy witryny, nie widzi adnotacji.

W klasycznej wyszukiwarce Google wszystkie trzy metody są równoważne. Możesz je łączyć, ale według Google nie daje to żadnej przewagi w wyszukiwaniu i utrudnia utrzymanie, bo każdą zmianę trzeba bez sprzeczności wprowadzić w kilku miejscach. Lepiej konsekwentnie stosować jedną metodę. Dla widoczności w AI najpewniejszy jest wariant w sekcji head renderowany po stronie serwera, ponieważ łączy sygnał językowy bezpośrednio z dostarczanym dokumentem. Decydujące pozostają jednak atrybut lang i wyraźne sygnały językowe on-page, bo działają nawet bez interpretacji hreflang.

Hreflang w Next.js i architekturach headless

W nowoczesnych konfiguracjach Next.js i headless to strategia renderowania decyduje o tym, czy sygnały językowe w ogóle docierają do crawlerów AI.

• Server-Side Rendering zamiast Client-Side: Sygnały locale muszą znajdować się w początkowym HTML, a nie powstawać dopiero po hydratacji za sprawą JavaScriptu po stronie klienta. Ponieważ crawlery AI nie renderują JS, każdy sygnał ustawiony dopiero po stronie klienta przepada.
• alternates.languages w metadanych: Next.js pozwala generować hreflang po stronie serwera przez obiekt Metadata z alternates.languages. Dzięki temu adnotacje niezawodnie trafiają do sekcji head początkowego HTML.
• Ustawianie atrybutu lang po stronie serwera: Atrybut lang="de-AT" w elemencie html powinien być ustawiany przez serwer dla każdej wersji locale. To najstabilniejszy sygnał językowy dla crawlerów bez renderowania.
• Czysta struktura sekcji head: Ważne metadane muszą znajdować się na górze sekcji head. Międzynarodowe badanie wykazało, że 10,1% stron na desktopie ma nieprawidłowe elementy w sekcji head (międzynarodowe). Jeśli hreflang, canonical lub meta robots znajdują się poniżej nieprawidłowego elementu, zostają przeniesione do sekcji body i przestają działać.

Konsekwencje dla GEO i AEO w przypadku treści de-AT

Jeśli platformy AI nie traktują hreflang jako mechanizmu wyboru, zadanie przesuwa się ze sterowania wersjami locale na samą widoczność. Celem jest, by treści de-AT były w ChatGPT, Perplexity i Copilot rozpoznawalne jako treści austriackie, bez tego, by hreflang działał jak filtr.

• Renderowanie po stronie serwera jako obowiązek: Crawlery AI przetwarzają tylko to, co znajduje się w początkowym HTML. Treści de-AT muszą być w całości dostarczane z serwera.
• Wyraźne sygnały językowe on-page: Zamiast polegać na hreflang, lepiej umieścić odniesienie do Austrii w samym tekście: Austria, lokalizacje w Austrii, ceny w euro z austriacką stawką VAT, austriackie pojęcia prawne i branżowe. Dzięki temu lokalizacja jest bezpośrednio czytelna dla modeli językowych.
• Własne, stabilne adresy URL: Każda wersja potrzebuje jednoznacznego, stale dostępnego adresu URL, aby można ją było cytować i linkować.
• Uporządkowane treści poparte źródłami: Jasne definicje, listy i stwierdzenia poparte źródłami zwiększają szansę, że treść zostanie przywołana jako źródło w odpowiedziach generatywnych.

Podejście z podkatalogami, czyli example.com/at/, zwykle sprawdza się tu lepiej niż osobne domeny ccTLD, bo konsoliduje autorytet domeny i jednocześnie zapewnia jasny, indeksowalny adres URL dla każdego regionu. Lokalizacja zostaje zachowana, a widoczność nie rozkłada się na kilka słabych domen.

Hreflang a canonical, przekierowania i mapy witryn

Hreflang nigdy nie działa w oderwaniu od reszty. Konflikty z tagami canonical, przekierowaniami i mapami witryn należą do najczęstszych źródeł błędów.

• Canonical i hreflang nie mogą sobie przeczyć: Każda wersja powinna wskazywać jako kanoniczną samą siebie. Canonical wskazujący ze strony de-AT na stronę de-DE znosi logikę hreflang i prowadzi do konsolidacji.
• Bez odwołań do przekierowań: Hreflang musi wskazywać na docelowy adres URL dostępny ze statusem 200, a nie na adres przekierowany kodem 301. Odwołania do przekierowań lub niedziałających stron to udokumentowany główny błąd.
• Spójność z mapą witryny XML: Adresy URL w mapie witryny, w tagu canonical i w adnotacjach hreflang muszą być identyczne, łącznie z protokołem, ukośnikiem i wielkością liter.

Skala tych problemów jest znaczna. Międzynarodowe badanie 18 786 witryn z kodem hreflang wykazało sprzeczne dyrektywy hreflang w 31,02% przypadków i brak x-default w 47,95% (międzynarodowe). Takie konflikty sprawiają, że Google ignoruje sygnały i decyduje samodzielnie.

Monitoring, walidacja i pomiar

Hreflang wymaga stałej kontroli, właśnie dlatego, że błędy często pozostają niewidoczne. Połączenie narzędzi i analizy logów pozwala wychwycić najważniejsze problemy.

• Google Search Console: Nie ma tam już raportu błędów hreflang: Google wycofało raport „Kierowanie międzynarodowe”. Raport „Indeksowanie stron” pokazuje, które adresy URL zostały odrzucone jako duplikaty, a narzędzie do sprawdzania adresów URL podaje dla każdej wersji DACH stan indeksowania i adres kanoniczny wybrany przez Google. Same błędy hreflang znajdziesz za pomocą crawlera.
• Crawlery takie jak Screaming Frog: Techniczny crawl wykrywa brakujące samoodwołania, brak x-default, niewzajemne odwołania i tagi hreflang wskazujące na przekierowania lub strony niekanoniczne.
• Analiza logów pod kątem wizyt botów AI: Logi serwera pokazują, czy i jak GPTBot, ClaudeBot i PerplexityBot pobierają poszczególne wersje. Pozwala to sprawdzić, czy początkowy HTML jest dostarczany z właściwymi sygnałami językowymi.
• Sprawdzenie renderowania treści: Pobranie samego HTML bez wykonywania JavaScriptu pokazuje, czy atrybut lang, hreflang w sekcji head i lokalne odniesienia rzeczywiście znajdują się w początkowym dokumencie.

Dla porównania skali: według międzynarodowego badania Web Almanac 2022 9,6% stron na desktopie używało tagów hreflang, a wartość de należała do czterech najczęstszych wartości językowych (międzynarodowe). Hreflang jest więc szeroko stosowany, ale jak pokazują wskaźniki błędów, rzadko bezbłędnie.

Dalsze materiały i podsumowanie

Hreflang nadal ma sens w klasycznej wyszukiwarce Google w regionie DACH, o ile jest poprawnie wdrożony: de-DE, de-AT, de-CH i x-default z kompletnymi, wzajemnymi i samoodwołującymi się tagami. Kluczowe jest zrozumienie, że hreflang już w Google jest tylko wskazówką, a w wyszukiwaniu za pośrednictwem AI praktycznie przestaje działać, bo crawlery AI nie wybierają wersji językowo-regionalnej i w ogóle nie widzą sygnałów ustawianych po stronie klienta.

Wniosek dla firm działających na rynku austriackim jest jasny: sygnały językowe należą do HTML renderowanego po stronie serwera, odniesienie do Austrii do widocznego tekstu, a każda wersja potrzebuje własnego, stabilnego adresu URL. Uzupełniająco warto dbać o content-language i atrybut lang z myślą o Bing i Copilocie. Sensowne kolejne kroki to sprawdzenie renderowania początkowego HTML, audyt hreflang za pomocą crawlera i analiza logów pod kątem wizyt botów AI, aby sprawdzić, czy właściwa wersja w ogóle dociera do systemów AI.