Jedna strona może mieć kilka wersji językowych albo osobne adresy dla różnych krajów. Bez właściwych oznaczeń wyszukiwarka może pokazać polskiemu użytkownikowi wersję angielską, a klientowi z Wielkiej Brytanii stronę przygotowaną dla Stanów Zjednoczonych. W tym artykule wyjaśniam, czym jest atrybut hreflang, kiedy go stosować, jak wdrożyć go w HTML i jak uniknąć błędów, które osłabiają SEO międzynarodowe.
Najważniejsze informacje o oznaczeniach językowych stron
-
hreflangwskazuje wyszukiwarce alternatywne wersje językowe lub regionalne tej samej strony. - Każda wersja powinna wskazywać siebie oraz pozostałe odpowiadające jej adresy.
-
langihreflangmają różne zadania, dlatego nie należy ich stosować zamiennie. -
x-defaultmoże kierować użytkowników do wersji ogólnej, na przykład z wyborem języka. - Najczęstsze problemy to brak wzajemnych wskazań, błędne kody języków i blokowanie stron przed indeksacją.
Co naprawdę oznacza hreflang w SEO
Atrybut hreflang informuje wyszukiwarkę, że dana strona ma alternatywne wersje językowe lub regionalne. Nie jest to przekierowanie i nie zmienia zawartości strony. Pomaga jedynie dopasować właściwy adres do języka oraz lokalizacji użytkownika.
Przykładowo polska wersja produktu może mieć odpowiednik angielski, niemiecki oraz osobny wariant angielski dla Wielkiej Brytanii. W takim układzie wyszukiwarka otrzymuje dodatkową informację, że te adresy opisują odpowiadające sobie wersje treści. Google opisuje ten mechanizm jako sposób na wskazanie użytkownikom najbardziej odpowiedniej wersji językowej lub regionalnej. [Google Search Central](https://developers.google.com/search/docs/specialty/international/localized-versions)
Trzeba przy tym oddzielić trzy różne elementy:
| Element | Do czego służy |
|---|---|
lang |
Opisuje język dokumentu dla przeglądarek, czytników ekranowych i narzędzi dostępności. |
hreflang |
Wskazuje wyszukiwarce powiązane wersje językowe lub regionalne adresu. |
canonical |
Wskazuje preferowany adres spośród stron bardzo podobnych lub powielonych. |
To rozróżnienie ma praktyczne znaczenie. lang="pl" nie zastępuje hreflang="pl", a oznaczenie języka w kodzie HTML nie służy do mapowania kilku adresów tej samej treści.
Kiedy warto wdrożyć oznaczenia językowe i regionalne
Największy sens mają wtedy, gdy witryna rzeczywiście obsługuje więcej niż jeden język lub rynek. Dotyczy to sklepów internetowych, serwisów SaaS, stron firmowych, portali turystycznych i organizacji działających w kilku krajach.
Różne języki
Jeżeli pod tym samym adresem nie pokazujesz automatycznie zmienianej treści, lecz masz osobne strony, możesz połączyć je za pomocą odpowiednich kodów. Przykładowo użyjesz pl dla polskiego, en dla angielskiego i de dla niemieckiego.
Nie musisz dodawać oznaczeń tylko dlatego, że strona ma przełącznik języka. Liczy się to, czy każda wersja ma osobny, indeksowalny adres i odpowiada tej samej podstronie w innym języku.
Różne kraje w jednym języku
Wersja en-GB może być przeznaczona dla Wielkiej Brytanii, a en-US dla Stanów Zjednoczonych. Rozróżnienie ma sens, gdy zmieniasz ceny, walutę, dostępność produktów, jednostki miary, prawo lub sposób kontaktu.
Jeśli wszystkie wersje są identyczne i różnią się wyłącznie domeną, nie zakładałbym automatycznie, że potrzebujesz osobnego wariantu regionalnego. Sam inny kraj docelowy nie wystarczy, jeżeli użytkownik otrzymuje dokładnie tę samą ofertę i treść.
Kiedy hreflang nie rozwiąże problemu
Ten mechanizm nie przetłumaczy strony, nie naprawi słabej architektury informacji i nie zagwarantuje wyższej pozycji. Google zaznacza również, że nie używa atrybutu hreflang ani HTML-owego lang jako jedynego sposobu rozpoznawania języka strony. Oznaczenia są sygnałem pomocniczym, dlatego sama ich obecność nie zastąpi dobrej treści i poprawnej indeksacji.
Nie wdrażałbym ich także dla kilku adresów, które mają zupełnie inną intencję, zakres tematyczny albo grupę odbiorców. Powiązane powinny być odpowiedniki tej samej podstrony, a nie przypadkowe strony z różnych wersji serwisu.
Jak wdrożyć hreflang w kodzie HTML
Najpopularniejsze wdrożenie polega na umieszczeniu oznaczeń w sekcji . Każda wersja strony powinna zawierać pełny zestaw powiązań, czyli wskazywać siebie oraz wszystkie odpowiadające jej warianty.
Dla strony produktowej dostępnej po polsku, angielsku i niemiecku schemat może wyglądać tak:
W działającym serwisie atrybut href powinien prowadzić do kanonicznego adresu konkretnej wersji. Warto stosować pełne adresy HTTPS, nie blokować ich w pliku robots.txt i zadbać o to, aby strona zwracała kod odpowiedzi 200.
Wzajemność jest ważniejsza niż liczba wpisów
Jeśli polska strona wskazuje angielską, angielska powinna wskazywać polską. Brak takiego powrotnego połączenia jest jednym z najczęstszych powodów, dla których wdrożenie działa częściowo albo jest ignorowane.
W praktyce najlepiej generować te wpisy automatycznie z jednego źródła danych. Ręczne edytowanie kilkudziesięciu szablonów szybko prowadzi do literówek, pominiętych wariantów i odwołań do nieistniejących stron.
Przeczytaj również: PageRank w SEO - jak działa i co naprawdę liczy się dziś?
Jak zapisywać kody
Najpierw podaje się kod języka, a dopiero potem opcjonalny kod regionu, na przykład fr-CA dla francuskiej wersji kanadyjskiej. Nie należy używać samego kodu kraju jako zamiennika języka. Wariant regionalny powinien wynikać z realnej różnicy dla odbiorcy.
Wartość x-default można zastosować dla strony neutralnej, selektora języka albo wersji kierowanej do użytkowników, których języka nie opisano osobnym wpisem. Nie jest obowiązkowa, ale w rozbudowanych serwisach często porządkuje ścieżkę użytkownika.
HTML, mapa XML czy nagłówki HTTP
HTML nie jest jedynym sposobem wdrożenia. Wybór metody zależy od rodzaju serwisu, liczby wersji i tego, czy kontrolujesz kod każdej strony. Najważniejsze jest zachowanie spójnego zestawu oznaczeń, a nie samo miejsce ich publikacji.
| Metoda | Kiedy sprawdza się najlepiej | Ograniczenie |
|---|---|---|
| HTML | Klasyczne strony, sklepy i serwisy z dostępem do szablonów. | Duża liczba wersji zwiększa objętość kodu. |
| Mapa XML | Duże witryny z wieloma adresami i automatycznie generowanymi podstronami. | Wymaga poprawnej składni oraz sprawnej aktualizacji pliku. |
| Nagłówki HTTP | Pliki PDF i zasoby, których nie można oznaczyć bezpośrednio w HTML. | Konfiguracja bywa trudniejsza dla zespołu bez dostępu do serwera. |
Nie łączyłbym kilku metod bez powodu. Jeśli HTML, mapa XML i nagłówki HTTP zawierają różne adresy, powstaje trudny do diagnozy bałagan. Przy dużej stronie rozsądnie jest wybrać jedno główne źródło, a pozostałe stosować tylko wtedy, gdy wynika to z architektury witryny.
Przy wdrożeniach opartych na mapie XML każda grupa alternatyw powinna obejmować wszystkie odpowiadające sobie adresy. W przypadku PDF-ów podobny efekt można osiągnąć przez nagłówek HTTP, ponieważ sam dokument nie ma sekcji .
Najczęstsze błędy i szybka kontrola wdrożenia
Najwięcej problemów wynika nie z samej składni, lecz z niespójności między wersjami. Przed publikacją sprawdzam nie tylko obecność tagów, ale też to, czy wskazane strony naprawdę istnieją i opisują tę samą treść.
- Brak wskazania zwrotnego - każda wersja powinna odwzajemnić relację.
- Niepoprawny kod - język i region zapisuj w prawidłowej kolejności.
- Adres przekierowujący - wskazuj finalny adres, a nie stronę z przekierowaniem.
- Strona z blokadą indeksacji - oznaczenie nie pomoże, jeśli wersja ma blokadę robots lub dyrektywę noindex.
- Niekanoniczny adres - wpisuj adres zgodny z deklaracją canonical.
- Brak wersji alternatywnej - nie dodawaj wpisu, jeśli odpowiadająca strona nie istnieje.
- Automatyczna zmiana języka bez osobnego adresu - wyszukiwarka nie otrzymuje wtedy stabilnego celu.
Szczególnie często widzę błąd polegający na wskazywaniu strony głównej jako alternatywy dla każdej podstrony. To nie jest prawidłowe mapowanie. Karta produktu powinna prowadzić do karty tego samego produktu, a artykuł do jego tłumaczenia, nie do strony startowej.
Do kontroli można użyć raportów dotyczących stron międzynarodowych w narzędziach dla webmasterów, crawlera SEO albo prostego skryptu sprawdzającego pary adresów. W małym serwisie wystarczy tabela z kolumnami adres źródłowy, kod języka, adres alternatywny i status HTTP. Przy większej witrynie automatyczna walidacja oszczędza wiele godzin ręcznej pracy.
Co sprawdzić przed uruchomieniem wersji zagranicznej
Najlepszy moment na wdrożenie oznaczeń jest jeszcze przed publikacją kolejnego rynku. Wtedy można od razu ustalić strukturę adresów, zasady canonicalizacji i sposób generowania powiązań, zamiast później łatać je w wielu systemach.
Ja zaczynam od odpowiedzi na trzy pytania. Czy każda wersja ma własny adres, czy tłumaczenie obejmuje tę samą podstronę oraz czy różnice regionalne są wystarczająco duże, aby uzasadnić osobny wariant. Jeśli na któreś pytanie odpowiedź brzmi „nie”, samo hreflang raczej nie będzie najlepszym rozwiązaniem.
Najważniejszy efekt nie polega na mechanicznym zdobyciu dodatkowych punktów rankingowych. Chodzi o to, aby właściwy użytkownik trafił na właściwą wersję, z odpowiednią walutą, językiem, ofertą i informacją kontaktową. Dobrze przygotowane oznaczenia wspierają ten cel, ale muszą działać razem z poprawną architekturą serwisu i wartościową treścią.
