Materiał porządkuje temat: hreflang wskazuje bledne wersje jezykowe po migracji strony.
Po migracji strony Google może zacząć pokazywać nieodpowiednią wersję kraju lub języka, mimo że wcześniej konfiguracja działała poprawnie. Typowy objaw to sytuacja, w której użytkownik z Polski widzi w wynikach wersję angielską, klient z Niemiec trafia na wariant globalny, a podstrony lokalne konkurują ze sobą zamiast wspierać widoczność w swoich rynkach.
Problem często wynika z tego, że hreflang wskazuje bledne wersje jezykowe po migracji strony, adresy alternatywne nie zostały zaktualizowane, mapy XML zawierają stare URL-e albo wdrożenie kanonicznych adresów URL koliduje z deklaracjami językowymi. Poniżej znajdziesz praktyczną ścieżkę diagnostyczną dla właścicieli firm, marketerów B2B, e-commerce managerów i osób odpowiedzialnych za stronę.
Jeśli problem pojawił się po zmianie domeny, CMS-a, struktury URL, protokołu, wersji językowych lub wdrożeniu nowego szablonu, nie zaczynaj od ręcznego poprawiania pojedynczych tagów. Najpierw sprawdź pełną logikę indeksacji, canonicali, przekierowań i sitemap. Hreflang działa poprawnie tylko wtedy, gdy cała konfiguracja techniczna jest spójna.
Jak wygląda problem z błędnym hreflang po migracji?
Najbardziej widoczny objaw jest prosty: Google pokazuje nieodpowiednią wersję kraju lub języka w wynikach wyszukiwania. Użytkownik szukający oferty po polsku trafia na stronę angielską, użytkownik z Czech widzi wersję niemiecką, a strona dla rynku brytyjskiego pojawia się zamiast wersji amerykańskiej.
Po stronie biznesowej problem może wyglądać jak spadek konwersji, wzrost współczynnika odrzuceń, mniejsza liczba zapytań z danego kraju lub nagły spadek widoczności lokalnych katalogów. W e-commerce dochodzą błędne ceny, waluty, koszty dostawy i komunikaty prawne, które obniżają zaufanie do sklepu.
Nieprawidłowa wersja w Google
Wynik organiczny prowadzi do innego języka lub kraju niż oczekiwany, mimo że właściwa podstrona istnieje i jest dostępna.
Spadki po migracji
Widoczność lokalnych wersji spada po zmianie adresów URL, domeny, CMS-a, struktury katalogów lub wdrożeniu nowego frontendu.
Kanibalizacja wersji językowych
Kilka wersji tej samej treści konkuruje o podobne zapytania, a Google wybiera wariant niezgodny z intencją użytkownika.
Niejasne dane w raportach
W Google Search Console kraje, zapytania i adresy docelowe zaczynają mieszać się pomiędzy wersjami językowymi.
Dlaczego błędne wersje językowe szkodzą SEO?
Hreflang nie jest dyrektywą indeksowania, tylko sygnałem dla Google, która wersja językowa lub regionalna jest odpowiednia dla konkretnego użytkownika. Jeśli sygnał jest niespójny, wyszukiwarka może zignorować deklaracje i samodzielnie wybrać adres, który uzna za najlepszy.
Po migracji ryzyko jest większe, ponieważ równocześnie zmieniają się adresy URL, mapy XML, przekierowania, canonicale, linkowanie wewnętrzne i szablony. Nawet jeśli sama treść została przeniesiona poprawnie, błędna konfiguracja hreflang może opóźnić stabilizację widoczności.
Hreflang nie zastępuje dobrze zaplanowanej architektury informacji. Jeśli wersje językowe mają niespójne adresy, zduplikowane canonicale, brak odpowiedników 1:1 lub są blokowane przed indeksacją, sam tag hreflang nie rozwiąże problemu.
W szerszej diagnostyce warto połączyć analizę hreflang z audytem obszarów opisanych w kategorii SEO techniczne, ponieważ błędne wersje językowe bardzo często są skutkiem problemów z indeksacją, przekierowaniami lub strukturą URL.
Najczęstsze przyczyny po migracji strony
Migracja rzadko psuje tylko jeden element. Hreflang jest zależny od wielu warstw technicznych, dlatego diagnoza powinna obejmować zarówno kod HTML, jak i sitemapy, nagłówki HTTP, reguły przekierowań oraz canonicale.
Stare adresy URL w hreflang
Po zmianie struktury linków tagi nadal wskazują stare adresy, które przekierowują, zwracają 404 albo prowadzą do niewłaściwych odpowiedników.
Brak wzajemności tagów
Strona polska wskazuje wersję niemiecką, ale niemiecka nie wskazuje z powrotem polskiej. Google traktuje taką konfigurację jako niespójną.
Canonical do innej wersji językowej
Podstrona lokalna ma hreflang do innych wariantów, ale canonical wskazuje wersję globalną lub inną domenę, co osłabia sygnał lokalizacji.
Błędne kody języka i kraju
Wdrożenie używa niepoprawnych oznaczeń, na przykład pl-PL działa, ale en-UK jest błędne, ponieważ dla Wielkiej Brytanii stosuje się en-GB.
Warianty blokowane przed indeksacją
Adresy wskazane w hreflang mają noindex, są zablokowane w robots.txt, wymagają logowania lub zwracają status inny niż 200.
Niespójne sitemapy XML
Mapa strony zawiera stare zestawy alternatyw, pomija część wersji językowych albo dubluje adresy po migracji.
Automatyczne przekierowania po IP
Serwer przekierowuje użytkowników i roboty na podstawie lokalizacji, przez co Googlebot nie widzi stabilnej wersji adresu.
Niepełne mapowanie odpowiedników
Po migracji część podstron nie ma odpowiedników w innych językach, ale system generuje hreflangi do kategorii, strony głównej lub losowego wariantu.
Diagnostyka krok po kroku
Najgorszym podejściem jest sprawdzanie tylko jednej podstrony, która akurat pojawia się w wynikach. Wdrożenie hreflang trzeba ocenić na próbie reprezentatywnej: strona główna, kategorie, produkty lub usługi, artykuły, landing pages oraz adresy o dużym ruchu organicznym.
- Ustal zakres migracjiSprawdź, co dokładnie się zmieniło: domena, protokół, struktura katalogów, CMS, wersje językowe, adresy kanoniczne, sitemapy, routing lub logika przekierowań.
- Zbierz przykłady błędnych wynikówZanotuj zapytania, kraje, języki, adresy wyświetlane w Google i adresy, które powinny być wyświetlane. Pomocne są dane z Google Search Console oraz ręczne testy w trybie bez personalizacji.
- Sprawdź statusy HTTPKażdy adres wskazany w hreflang powinien zwracać kod 200. Unikaj wskazywania URL-i, które przekierowują, mają 404, 410, 500 lub są dostępne tylko warunkowo.
- Porównaj hreflang z canonicalKażda wersja językowa powinna zwykle wskazywać canonical na samą siebie. Jeśli canonical prowadzi do innego języka, Google może zignorować lokalny wariant.
- Zweryfikuj wzajemnośćWszystkie adresy w jednym klastrze językowym muszą wskazywać siebie nawzajem. Brak linku zwrotnego jest jedną z najczęstszych przyczyn ignorowania hreflang.
- Sprawdź zgodność kodów języka i krajuZweryfikuj formaty zgodne ze standardami ISO, na przykład pl, pl-PL, de-DE, en-US, en-GB. Nie mieszaj oznaczeń wymyślonych lub skrótów marketingowych.
- Porównaj HTML, sitemapę i nagłówki HTTPJeśli hreflang jest wdrażany w kilku miejscach, deklaracje muszą być identyczne. Sprzeczne sygnały utrudniają Google wybór właściwej wersji.
- Sprawdź indeksowalnośćUpewnij się, że adresy nie mają noindex, nie są blokowane w robots.txt i nie wymagają akceptacji lokalizacji, ciasteczek lub przekierowania regionalnego.
- Przeanalizuj linkowanie wewnętrzneMenu językowe, linki w stopce i linki kontekstowe powinny prowadzić do aktualnych odpowiedników, a nie do starych adresów lub stron głównych innych wersji.
- Monitoruj po wdrożeniuPo naprawie obserwuj indeksację, wyświetlane adresy, kraje ruchu i zapytania. Google potrzebuje czasu na ponowne przetworzenie klastrów językowych.
Jeżeli nie masz pewności, czy problem dotyczy wyłącznie hreflang, czy całej migracji, dobrym punktem startu jest techniczny audyt SEO. Pozwala sprawdzić zależności pomiędzy indeksacją, przekierowaniami, canonicalami, sitemapami i architekturą strony.
Tabela diagnostyczna
Poniższa tabela pomaga szybko połączyć objaw z prawdopodobną przyczyną i rekomendowanym działaniem. W praktyce kilka problemów może występować jednocześnie, zwłaszcza po dużych migracjach e-commerce lub serwisów B2B na wielu rynkach.
| Objaw | Co sprawdzić | Prawdopodobna przyczyna | Rekomendowane działanie |
|---|---|---|---|
| Google pokazuje wersję angielską zamiast polskiej | Hreflang, canonical, indeksowalność wersji PL | Canonical z PL wskazuje EN albo brak wzajemnego hreflang | Ustaw self-referencing canonical dla PL i pełny klaster hreflang |
| Adresy w hreflang przekierowują | Statusy HTTP adresów alternatywnych | Po migracji zostawiono stare URL-e w tagach | Zamień wszystkie wskazania na finalne adresy ze statusem 200 |
| Wersje krajowe mieszają się w wynikach | Kody języka i kraju | Błędne oznaczenia, na przykład en-UK zamiast en-GB | Popraw kody zgodnie ze standardem i wdroż spójnie w całym serwisie |
| Google ignoruje część deklaracji | Wzajemność linków hreflang | Nie wszystkie wersje wskazują siebie nawzajem | Wygeneruj kompletne klastry alternatyw dla każdej grupy podstron |
| W Search Console pojawiają się stare adresy | Sitemapy XML i przekierowania | Mapa strony nie została zaktualizowana po migracji | Wyczyść stare URL-e, dodaj tylko indeksowalne adresy finalne |
| Robot widzi inną wersję niż użytkownik | Przekierowania po IP, języku przeglądarki i cookies | Automatyczna geolokalizacja wymusza zmianę adresu | Zastąp wymuszone przekierowanie wyborem języka i stabilnymi URL-ami |
Jak naprawić błędne wskazania hreflang?
Naprawa powinna zacząć się od uporządkowania modelu adresów. Każda wersja językowa lub regionalna musi mieć stabilny, indeksowalny adres URL. Dopiero później warto poprawiać tagi w HTML, sitemapy albo nagłówki HTTP.
1. Zbuduj prawidłowe klastry alternatyw
Klaster hreflang to grupa adresów, które są odpowiednikami tej samej treści w różnych językach lub regionach. Jeśli masz stronę usługi po polsku, angielsku i niemiecku, każda z tych podstron powinna wskazywać wszystkie pozostałe oraz samą siebie.
Nie wskazuj w hreflang najbliższej podobnej strony, jeśli nie jest realnym odpowiednikiem. Przekierowywanie użytkownika z konkretnego produktu na kategorię w innym języku może być gorsze niż brak hreflang dla tej podstrony.
2. Popraw canonicale
Jeśli polska wersja ma canonical do angielskiej, Google otrzymuje sprzeczny komunikat: z jednej strony widzi alternatywy językowe, z drugiej sygnał, że wersja polska nie jest kanoniczna. W większości przypadków lokalne warianty powinny mieć canonical do własnego adresu.
3. Usuń stare i przekierowujące adresy
Po migracji często zostają stare adresy w szablonach, bazie danych, sitemapach lub konfiguracji modułu wielojęzycznego. Hreflang powinien wskazywać docelowy adres, nie adres, który dopiero przekierowuje do właściwej wersji.
4. Ujednolić źródło wdrożenia
Hreflang można wdrożyć w kodzie HTML, w mapie XML lub w nagłówkach HTTP. Nie ma obowiązku używania wszystkich metod naraz. Jeśli jednak używasz więcej niż jednej, konfiguracja musi być identyczna, inaczej Google może uznać sygnały za niespójne.
5. Zadbaj o x-default
Atrybut x-default wskazuje wersję domyślną, najczęściej globalną stronę wyboru języka lub wariant międzynarodowy. Jest szczególnie przydatny, gdy użytkownik nie pasuje jednoznacznie do konkretnego kraju lub języka.
6. Sprawdź linkowanie wewnętrzne
Przełączniki językowe powinny prowadzić do odpowiadającej podstrony, a nie zawsze do strony głównej danego kraju. Jeśli użytkownik jest na produkcie, powinien przejść do odpowiednika tego produktu, o ile istnieje.
7. Zaplanuj monitoring po poprawkach
Po wdrożeniu zmian nie oczekuj natychmiastowej korekty wyników. Google musi ponownie odwiedzić adresy, przetworzyć sygnały i zaktualizować wybór wersji. W zależności od wielkości serwisu może to potrwać od kilku dni do kilku tygodni.
Jeśli problem z hreflang dotyczy większego projektu międzynarodowego, naprawa powinna być elementem szerszej strategii pozycjonowania, a nie jednorazową poprawką w szablonie.
Lista kontrolna po wdrożeniu poprawek
Po naprawie warto wykonać kontrolę techniczną na próbie adresów z każdej wersji językowej. Nie ograniczaj się do strony głównej, ponieważ błędy najczęściej występują na poziomie kategorii, produktów, wpisów blogowych i landing page.
- Każdy adres w hreflang zwraca kod 200.
- Żaden adres alternatywny nie ma noindex.
- Robots.txt nie blokuje wersji językowych ani katalogów lokalnych.
- Canonical każdej wersji wskazuje właściwy adres kanoniczny, najczęściej samą siebie.
- Każda wersja językowa wskazuje wszystkie pozostałe wersje w tym samym klastrze.
- Nie ma starych adresów sprzed migracji w tagach hreflang.
- Sitemapy XML zawierają tylko aktualne, indeksowalne adresy.
- Kody języka i kraju są poprawne, na przykład en-GB zamiast en-UK.
- Przełącznik językowy prowadzi do odpowiedników konkretnych podstron.
- Nie ma wymuszonych przekierowań po IP, które uniemożliwiają robotom dostęp do adresu.
- Wdrożenie jest spójne między HTML, sitemapą i nagłówkami HTTP, jeśli używasz kilku metod.
- Dane w Google Search Console są monitorowane osobno dla kluczowych katalogów, domen lub rynków.
Jeśli po poprawkach Google nadal pokazuje błędny kraj lub język, sprawdź nie tylko tagi. Wpływ mogą mieć także jakość treści lokalnej, sygnały linkowe, historia adresu, przekierowania po migracji i to, która wersja jest silniej linkowana wewnętrznie.
Kiedy warto skonsultować problem z ekspertem?
Samodzielna korekta ma sens, gdy serwis ma kilka wersji językowych i prostą strukturę adresów. Konsultacja jest wskazana, gdy po migracji doszło do spadków widoczności, błędnych wersji w Google, utraty ruchu z rynków zagranicznych lub problemów z indeksacją tysięcy podstron.
Duża migracja lub wiele rynków
Im więcej wersji językowych, domen, subdomen i katalogów, tym większe ryzyko błędnych klastrów oraz sprzecznych sygnałów technicznych.
Spadki sprzedaży lub leadów
Jeśli błędna wersja językowa wpływa na przychody, priorytetem jest szybka diagnoza przyczyn i plan naprawczy z kolejnością działań.
Konflikt hreflang z canonical
To jeden z problemów, który wymaga ostrożności, ponieważ pochopne zmiany mogą pogorszyć indeksację właściwych adresów.
Brak jasnych danych
Gdy raporty pokazują mieszanie krajów, języków i adresów, potrzebna jest analiza techniczna oraz interpretacja danych z narzędzi SEO.
W RankHero analizujemy takie problemy w ramach audytów technicznych, migracji SEO i działań naprawczych po spadkach. Sprawdzamy nie tylko sam hreflang, ale również indeksowalność, przekierowania, canonicale, sitemapy, strukturę linkowania i sygnały dla poszczególnych rynków.
Potrzebujesz diagnozy hreflang po migracji?
Jeśli Google pokazuje nieodpowiednią wersję kraju lub języka, warto szybko ustalić, czy problem dotyczy tagów hreflang, canonicali, sitemap, przekierowań czy całej architektury po migracji.
O czym jeszcze pamiętać przy serwisach wielojęzycznych?
Hreflang pomaga Google zrozumieć relacje między wersjami, ale nie rozwiązuje problemów jakościowych. Jeżeli lokalna podstrona jest automatycznym tłumaczeniem, ma niepełne dane, gorszą ofertę lub znacznie słabsze linkowanie wewnętrzne, Google może mimo wszystko preferować inną wersję.
W projektach B2B częstym błędem jest tworzenie wielu wersji językowych bez realnego dopasowania do rynku. W e-commerce problemem bywają różnice w dostępności produktów, cenach i parametrach. Wtedy hreflang powinien odzwierciedlać rzeczywiste odpowiedniki, a nie życzeniową strukturę serwisu.
Jeśli chcesz uporządkować pojęcia techniczne przed rozmową z zespołem IT lub agencją, skorzystaj ze słownika pojęć. Wspólny język ułatwia rozdzielenie problemów z hreflang, canonical, indeksacją i przekierowaniami.
FAQ
Czy hreflang gwarantuje wyświetlenie właściwej wersji językowej?
Nie. Hreflang jest sygnałem, a nie bezwzględną dyrektywą. Google może go zignorować, jeśli adresy są nieindeksowalne, canonicale są sprzeczne, brakuje wzajemności albo treść i linkowanie sugerują inną wersję jako ważniejszą.
Czy po migracji można zostawić stare adresy w hreflang, jeśli mają przekierowania 301?
Nie jest to rekomendowane. Hreflang powinien wskazywać finalne adresy ze statusem 200. Linkowanie do adresów przekierowujących utrudnia przetwarzanie sygnałów i może opóźnić stabilizację po migracji.
Co jest lepsze: hreflang w HTML czy w sitemapie XML?
Obie metody mogą działać poprawnie. Ważniejsza od wyboru metody jest spójność, kompletność i aktualność danych. W dużych serwisach sitemapy bywają wygodniejsze operacyjnie, ale muszą być generowane bez błędów i regularnie aktualizowane.
Czy każda wersja językowa musi wskazywać samą siebie?
Tak, rekomendowane jest używanie self-referencing hreflang, czyli wskazania również bieżącego adresu. Pomaga to zbudować kompletny klaster wersji alternatywnych.
Czy x-default jest obowiązkowy?
Nie jest obowiązkowy, ale często jest przydatny. Szczególnie wtedy, gdy masz stronę globalną, stronę wyboru kraju lub wersję domyślną dla użytkowników, którzy nie pasują do konkretnego języka i regionu.
Dlaczego Google pokazuje wersję globalną zamiast lokalnej?
Najczęstsze przyczyny to silniejszy canonical lub linkowanie do wersji globalnej, brak kompletnego hreflang, błędne kody kraju, noindex na wersji lokalnej, stare adresy po migracji albo niewystarczające dopasowanie treści do rynku.
Jak długo trwa naprawa efektów po błędnym hreflang?
Sama poprawka techniczna może być szybka, ale widoczne efekty zależą od tempa ponownego crawlowania i przetwarzania adresów przez Google. Dla małych serwisów może to być kilka dni, dla dużych sklepów lub portali kilka tygodni.
Czy problem z hreflang może wpływać na sprzedaż?
Tak. Jeśli użytkownik trafia na niewłaściwy język, kraj, walutę lub ofertę, spada zaufanie i prawdopodobieństwo konwersji. W e-commerce może to oznaczać błędne ceny, koszty dostawy i nieadekwatne komunikaty dla rynku.