Jak planować audyt hreflang w SEO wielojęzycznym: identyfikacja błędów tagowania, weryfikacja zwrotności, konsolidacja wersji językowych oraz workflow wdrażania poprawek
Dowiedz się, jak zaplanować audyt hreflang: od wykrycia błędnych kodów językowych po wdrożenie zwrotnych tagów i konsolidację wersji regionalnych.
Audyt hreflang ma jeden cel biznesowy: zapewnić, że użytkownik z każdego rynku trafia na właściwą wersję językową lub regionalną strony, a Google nie myli tych wersji przy wyborze wyniku do indeksu. Nie chodzi o dodanie tagów na każdej podstronie, lecz o zweryfikowanie, czy każda adnotacja jest wzajemna, używa prawidłowych kodów ISO i wskazuje adres zwracający kod 200. W praktyce oznacza to przegląd wszystkich wariantów językowych pod kątem widoczności w docelowej wyszukiwarce oraz eliminację sytuacji, w których dwie wersje konkurują o te same zapytania w jednym kraju. Pominięcie tego etapu w witrynie wielojęzycznej skutkuje wyświetlaniem użytkownikom nieprawidłowej wersji językowej, co bezpośrednio obniża współczynnik konwersji niezależnie od pozycji.
Zakres audytu i najczęstsze błędy hreflang
Zacznij od eksportu wszystkich adresów zawierających adnotacje hreflang — w sekcji <head>, nagłówkach HTTP lub mapie witryny XML. Nie pomijaj stron, które teoretycznie nie mają wersji językowych; często to właśnie one generują ruch z niepożądanych lokalizacji, ponieważ brak adnotacji x-default pozostawia Google bez sygnału wyboru.
Nieprawidłowe kody językowe i regionalne
Najczęstszy błąd to użycie kodu pl dla strony skierowanej do Polaków w Wielkiej Brytanii lub en-UK zamiast en-GB. Hreflang wymaga formatu język (ISO 639-1) opcjonalnie region (ISO 3166-1 alfa-2), rozdzielonych myślnikiem, nie podkreślnikiem. Zapisz w arkuszu każdy adres z adnotacją i zweryfikuj kody względem oficjalnych list ISO. Jeśli strona jest w języku polskim, ale nie ma wersji regionalnej, użyj samego pl. Dodanie fikcyjnego regionu pl-PL bez istotnych różnic w treści wprowadza szum informacyjny i zwiększa ryzyko błędnej interpretacji przez algorytm.
Brak wzajemności tagów zwrotnych
Google odrzuca adnotację hreflang, jeśli strona A wskazuje na B jako wariant hiszpański, ale strona B nie zawiera odniesienia z powrotem do A. To błąd wzajemności. Przygotuj macierz w arkuszu: wiersze to adresy źródłowe, kolumny to warianty językowe. W każdej komórce zapisz, czy zwrotny tag istnieje i czy prowadzi do dokładnie tego samego adresu URL — łącznie z protokołem i wariantem www lub non-www. Różnica w ukośniku na końcu adresu wystarczy, by wzajemność została uznana za zerwaną.
Wskazywanie adresów z błędnym kodem HTTP
Adnotacja hreflang musi wskazywać stronę zwracającą kod 200. Jeśli hiszpańska wersja zwraca 301, 404 lub jest zablokowana w robots.txt, cała grupa adnotacji traci wiarygodność. Dla każdego hreflang uruchom szybkie sprawdzenie nagłówka HTTP. Oznacz jako błąd krytyczny każde odniesienie do adresu niezwracającego 200. Szczególnie częsty przypadek to przekierowanie wersji regionalnej na ogólną — wtedy robot indeksuje docelowy URL, ale adnotacja wskazuje adres źródłowy, co generuje konflikt w raporcie Hreflang w Google Search Console.
Mapowanie struktury wielojęzycznej i wariant x-default
Zdecyduj, czy wdrażasz hreflang na poziomie strony w <head>, w nagłówkach HTTP, czy w mapie witryny XML. Mieszanie metod w jednej domenie prowadzi do konfliktów, gdy robot napotka różne zestawy adnotacji w zależności od źródła. Wybierz jedną metodę i trzymaj się jej konsekwentnie. Dla witryn opartych na CMS z wieloma wariantami językowymi najbardziej skalowalne jest wdrożenie w mapie XML, ponieważ nie wymaga modyfikacji szablonu każdej podstrony.
Strona domyślna x-default
Atrybut x-default wskazuje wersję strony dla użytkowników, których język nie jest objęty żadnym z pozostałych wariantów. Typowo jest to wersja angielska lub strona wyboru języka. Nie stosuj x-default jako kopii jednego z istniejących wariantów bez modyfikacji — powinien to być adres funkcjonalnie neutralny lub strona landingowa z selektorem. Jeśli x-default wskazuje na ten sam URL co en, upewnij się, że obie adnotacje są obecne i zgodne. Brak x-default nie jest błędem krytycznym, ale utrudnia Google zrozumienie, którą wersję wybrać dla użytkowników spoza zadeklarowanych regionów.
Identyfikacja kanibalizacji między wersjami językowymi
Kanibalizacja w hreflang występuje, gdy dwie wersje językowe — na przykład polska i czeska — docelowo konkurują o te same zapytania w jednym kraju, zamiast być rozdzielone geolingwistycznie. Sprawdź w Google Search Console raport Wydajność z filtrem kraju i zapytania. Jeśli polska wersja pojawia się w wynikach w Czechach, a czeska w Polsce, oznacza to, że Google nie rozróżnia wariantów lub użytkownicy nie otrzymują właściwej wersji.
Reguła weryfikacji
Porównaj listę najważniejszych zapytań — top sto według kliknięć — dla każdej wersji językowej. Jeśli te same frazy kluczowe generują ruch na dwóch wersjach w tym samym kraju, przejrzyj adnotacje hreflang dla tych adresów. Upewnij się, że kody regionów są prawidłowe. Jeśli nie targetujesz regionalnie, rozważ usunięcie atrybutu regionu i pozostawienie samego kodu języka, aby zmniejszyć ryzyko błędnej segmentacji. Pamiętaj, że hreflang to sygnał, nie dyrektywa — Google może zignorować adnotację, jeśli inne sygnały, takie jak profil linków lub treść na stronie, wskazują inaczej.
Workflow wdrażania poprawek hreflang
Zastosuj kolejność, która zapobiega propagacji błędów między wersjami językowymi:
- Inwentaryzacja: Wyeksportuj wszystkie adresy z adnotacjami hreflang z crawlera, GSC i logów serwera. Pogrupuj je w zestawy według tematu — każdy temat powinien mieć tyle wariantów, ile jest aktywnych wersji językowych.
- Weryfikacja kodów: Zweryfikuj poprawność każdego kodu języka i regionu. Popraw błędy składniowe: myślniki zamiast podkreślników, małe litery w kodzie języka, wielkie w regionie.
- Naprawa wzajemności: Dla każdego zestawu upewnij się, że wszystkie warianty wskazują się nawzajem. Jeśli jeden wariant nie ma zwrotnego tagu, dodaj go przed wdrożeniem jakichkolwiek innych zmian.
- Walidacja adresów docelowych: Upewnij się, że każdy adres w hreflang zwraca 200, nie jest przekierowany i nie jest zablokowany przed crawlowaniem.
- Wdrożenie i testy: Wdróż zmiany w środowisku przedprodukcyjnym. Przetestuj losową próbkę 10% zestawów. Użyj raportu Hreflang w Google Search Console lub dedykowanego narzędzia do walidacji masowej.
- Dokumentacja: Prowadź rejestr zestawów hreflang z datą weryfikacji, liczbą wariantów i zidentyfikowanymi błędami. Zapisz, które adresy wymagały zmiany kodu języka, a które naprawy zwrotności.
Checklist jakości po wdrożeniu
Po wdrożeniu poprawek zweryfikuj następujące punkty przed zamknięciem zadania:
- Wszystkie kody językowe używają formatu ISO 639-1, a kody regionów ISO 3166-1 alfa-2.
- Każda adnotacja hreflang ma pełną wzajemność w obrębie zestawu.
- Żaden adres w hreflang nie zwraca kodu 3xx, 4xx ani 5xx.
- Wariant
x-defaultjest zdefiniowany i wskazuje na stronę neutralną lub selektor języka. - Adnotacje są wdrożone tylko w jednym źródle:
<head>, nagłówek HTTP lub mapa XML — bez dublowania. - Wewnętrzne linki w każdej wersji językowej prowadzą do odpowiedników w tym samym języku, a nie do wersji domyślnej.
- Raport Hreflang w Google Search Console nie zgłasza błędów zwrotności ani nieprawidłowych adresów URL.
Analiza logów serwera a segmentacja językowa
W logach serwera sprawdź, czy robot Googlebot crawluje wersje językowe zgodnie z ich udziałem w ruchu. Jeśli niemiecki Googlebot regularnie pobiera polską wersję zamiast niemieckiej, oznacza to, że sygnały hreflang są niewystarczające lub że niemiecka wersja jest słabiej zlinkowana wewnętrznie. Porównaj liczbę zapytań do poszczególnych wersji językowych z liczbą adresów w indeksie — duża dysproporcja wskazuje na problem z dystrybucją crawl budget między wariantami. W takim przypadku rozważ dodanie linków wewnętrznych między wariantami w stopce lub nawigacji, aby wzmocnić sygnał hreflang poprzez strukturę witryny.
Jeśli zarządzasz witryną wielojęzyczną i potrzebujesz uporządkowanego workflow audytu hreflang bez zbędnych teorii, w Nelavio planujemy takie audyty jako zestaw konkretnych reguł decyzyjnych dla każdego wariantu językowego — jeśli chcesz omówić zakres prac dla swojej struktury, skontaktuj się z nami.
Chcesz publikować takie treści regularnie?
Nelavio planuje, pisze i publikuje artykuły na własną stronę przez GitHub lub webhook.
Nelavio