-
×
10 linków SEO AI (budownictwo,dom,ogród, nieruchomości)
1 × 350,00 zł
Definicja: Hreflang to atrybut HTML sygnalizujący wyszukiwarkom właściwą wersję językową lub regionalną strony dla danego użytkownika, oparty na trzech zasadach: (1) kodzie języka ISO 639-1 z opcjonalnym kodem regionu ISO 3166-1 Alpha-2; (2) wzajemnym odsyłaniu stron tworzącym parę hreflang (self-reference + return tag); (3) wdrożeniu jedną z trzech metod — tagami HTML, nagłówkami HTTP lub sitemap XML.
Ostatnia aktualizacja: 2026-02-23
Szybkie fakty
- Badanie przeprowadzone na 374 756 domenach wykazało, że 67% wdrożeń hreflang zawiera przynajmniej jeden błąd implementacyjny (Ahrefs, 2025).
- Google traktuje hreflang jako sygnał, nie dyrektywę — algorytm może wybrać inną wersję strony niż wskazana w atrybucie, gdy uzna ją za trafniejszą.
- Strony oznaczone tagiem hreflang muszą być indeksowalne — blokada noindex lub robots.txt dezaktywuje cały zestaw tagów dla danej wersji językowej.
Wdrożenie hreflang polega na dodaniu atrybutu <link rel="alternate" hreflang="[kod]"> do każdej strony, tak aby wskazywała na wszystkie równoważne wersje językowe łącznie z sobą samą.
- Wzajemność: każda strona w klastrze musi odsyłać do pozostałych wersji i otrzymywać tag powrotny
- Kompletność: każda wersja wymienia wszystkie warianty językowe w jednym zestawie tagów w
<head> - Metoda: tagi HTML w
<head>, nagłówki HTTP lub sitemap XML — wybór jednej metody dla całej witryny
Atrybut hreflang sygnalizuje wyszukiwarkom powiązania między wersjami językowymi strony, lecz Google traktuje go jako sygnał, nie dyrektywę — algorytm może wybrać inną wersję niż wskazana, gdy uzna ją za trafniejszą dla danego użytkownika. Studium przeprowadzone na 374 756 domenach wykazało, że 67% wdrożeń zawiera co najmniej jeden błąd implementacyjny. Artykuł omawia trzy dostępne metody — tagi HTML, nagłówki HTTP oraz sitemap XML — z kryteriami doboru dla różnych architektur witryn, a także wyjaśnia mechanizm best-match, który decyduje o tym, jaką wersję językową Google wyświetla przy braku idealnego dopasowania do profilu użytkownika. Opisana zostaje również oryginalna tabela diagnostyczna obejmująca dziewięć typowych błędów hreflang wraz z przyczynami, skutkami SEO i metodami naprawy.
Czym jest hreflang i jak Google go przetwarza
Hreflang to atrybut rel="alternate" wskazujący Google powiązane wersje językowe strony — algorytm stosuje go jako sygnał, co oznacza, że wybór wyświetlanej wersji należy ostatecznie do Google, nie do webmastera. Odróżnienie hreflanga od dyrektywy ma fundamentalne znaczenie praktyczne: nawet przy poprawnym technicznie wdrożeniu Google może wyświetlić inną wersję niż wskazana, jeśli jej własne sygnały (historia użytkownika, lokalizacja IP, język przeglądarki) sugerują inne dopasowanie.
Mechanizm best-match definiuje kolejność, według której Google wybiera wersję językową dla danego użytkownika: najpierw dopasowanie języka i kraju jednocześnie (np. pl-PL dla polskiego użytkownika w Polsce), następnie sam kod języka bez regionu (np. pl), a na końcu wersja oznaczona x-default jako rezerwowa. Mechanizm ten jest nieobecny w polskich źródłach w TOP10 i stanowi kluczowy element zrozumienia, dlaczego hreflang nie zawsze wyświetla oczekiwaną wersję.
Kody wartości atrybutu muszą być zgodne ze standardem ISO 639-1 dla języka (np. pl, en, de) i opcjonalnie ISO 3166-1 Alpha-2 dla regionu (np. PL, US, GB). Google ignoruje wartości niezgodne z tymi standardami — błędne kody takie jak pl-pl (małe litery w kodzie regionu są akceptowane) czy nieistniejące kody językowe powodują, że cały tag jest pomijany. Zasada self-reference wymaga, aby każda strona w zestawie wskazywała na siebie samą — jej pominięcie to jeden z dziewięciu najczęstszych błędów identyfikowanych przez narzędzia audytu. Return tag (tag powrotny) oznacza, że strona wskazana w hreflang musi z kolei wskazywać z powrotem na stronę źródłową — bez tej wzajemności Google ignoruje całą deklarację.
Przy wdrożeniach wieloregionalnych, gdzie ta sama witryna obsługuje np. użytkowników w Wielkiej Brytanii, Stanach Zjednoczonych i Australii przy wspólnym języku angielskim, poprawność kodów ISO determinuje, czy klaster hreflang działa jako zamknięty zestaw wzajemnych sygnałów, czy jako zbiór niezależnych, nieskutecznych deklaracji.
Trzy metody wdrożenia — kryteria wyboru dla różnych architektur witryn
Hreflang wdraża się na trzy sposoby — tagi <link> w sekcji <head>, nagłówki HTTP lub zapis w sitemap XML — przy czym każda metoda ma inne wymagania techniczne i odmienną skalę zarządzania przy aktualizacjach. Wybór metody nie wpływa na skuteczność sygnału — Google przetwarza wszystkie trzy równorzędnie.
Tagi HTML w <head> to metoda uniwersalna dla stron HTML. Każda strona w sekcji <head> zawiera komplet tagów <link rel="alternate" hreflang="[kod]" href="[URL]"> wskazujących na wszystkie wersje językowe łącznie z sobą samą. Wymaga edycji szablonu lub wtyczki CMS generującej tagi automatycznie — w WordPress realizują to wtyczki Yoast SEO i Rank Math przy aktywnej konfiguracji wielojęzyczności.
Nagłówki HTTP Link header stanowią jedyną dostępną metodę dla plików PDF i innych zasobów nie-HTML, gdzie edycja sekcji <head> nie jest możliwa. Wymaga dostępu do konfiguracji serwera (Apache: .htaccess, Nginx: dyrektywy add_header) lub obsługi po stronie aplikacji. Format nagłówka: Link: <URL>; rel="alternate"; hreflang="[kod]".
Sitemap XML jest rozwiązaniem efektywnym przy dużych witrynach liczących powyżej kilku tysięcy URL, ponieważ centralizuje zarządzanie całym klastrem hreflang w jednym pliku bez konieczności edytowania każdej strony. Wymaga deklaracji namespace xmlns:xhtml="http://www.w3.org/1999/xhtml" w elemencie <urlset> oraz poprawnej struktury <xhtml:link rel="alternate" hreflang="[kod]" href="[URL]"/> zagnieżdżonej w każdym elemencie <url>. Brak namespace to jeden z najczęstszych błędów przy tej metodzie — sitemap jest wówczas ignorowana przez Google.
„Każda wersja językowa musi wymienić siebie, a także wszystkie inne wersje językowe.”1
Zasada ta obowiązuje niezależnie od wybranej metody wdrożenia — zarówno tagi HTML, nagłówki HTTP, jak i wpisy sitemap XML muszą tworzyć kompletny, wzajemny zestaw dla każdego URL w klastrze.
Hreflang w HTML <head> czy w sitemap XML — którą metodę wybrać dla witryny WordPress?
Dla witryny WordPress z zainstalowaną wtyczką SEO (Yoast, Rank Math) tagi HTML w sekcji <head> stanowią rozwiązanie standardowe — wtyczki generują je automatycznie na podstawie konfiguracji języków. Sitemap XML jest rozwiązaniem korzystniejszym przy witrynach liczących powyżej kilku tysięcy URL, ponieważ pozwala zarządzać całym klastrem hreflang z jednego pliku bez edytowania każdej strony. Kryteria oceny wiarygodności metody powinny obejmować: zgodność z dokumentacją Google Search Central jako źródłem P1, możliwość weryfikacji przez narzędzia crawlujące (Screaming Frog sprawdza tagi HTML bezpośrednio ze stron, sitemap wymaga dodatkowej konfiguracji skanu), oraz spójność z pozostałymi mechanizmami CMS. W obu przypadkach obecność self-reference i tagów powrotnych wymaga osobnej weryfikacji, niezależnie od wybranej metody.
Hreflang stanowi techniczną podstawę każdej strategii pozycjonowania zagranicznego — dobór metody implementacji wynika bezpośrednio z architektury witryny i docelowych rynków językowych.
Przy mieszaniu metod — równoległym stosowaniu tagów HTML i sitemap XML — Google nie wskazuje żadnych korzyści, a ryzyko niespójności zestawów tagów rośnie proporcjonalnie do liczby stron w klastrze. Spójność metody w całej witrynie jest warunkiem utrzymania poprawności zestawu przy dodawaniu kolejnych wersji językowych.
Tabela diagnostyczna — 9 błędów hreflang i metody naprawy
Ahrefs zidentyfikował dziewięć kategorii błędów powtarzających się w 67% witryn stosujących hreflang — każdy z nich skutkuje ignorowaniem zestawu tagów lub wyświetlaniem nieodpowiedniej wersji językowej przez Google.
| Typ błędu | Przyczyna | Skutek SEO | Metoda naprawy |
|---|---|---|---|
| Brak tagu powrotnego (return tag) | Strona docelowa nie odsyła z powrotem do strony źródłowej | Google ignoruje całą parę hreflang | Dodać tag <link rel="alternate" hreflang="[kod]" href="[URL źródłowy]"> na stronie docelowej |
| Brak self-reference | Strona nie wskazuje na siebie samą w zestawie tagów | Niekompletny klaster — ryzyko pominięcia wersji przez algorytm | Dodać tag hreflang z własnym URL do zestawu tagów na każdej stronie |
| Nieprawidłowy kod języka lub regionu | Użycie kodu niezgodnego z ISO 639-1 lub ISO 3166-1 Alpha-2 | Google ignoruje cały tag — wersja językowa nieuwzględniana | Zastąpić błędny kod poprawnym kodem ISO (np. en-gb zamiast en-EN) |
| Hreflang wskazuje na URL z przekierowaniem 301 | URL w atrybucie href prowadzi do adresu, który przekierowuje na inny URL | Sprzeczny sygnał z rel=alternate — tag ignorowany | Zaktualizować href w tagu hreflang tak, aby wskazywał bezpośrednio na docelowy, kanoniczny URL |
| Hreflang wskazuje na URL z noindex | Strona docelowa oznaczona dyrektywą noindex lub zablokowana przez robots.txt | Google dezaktywuje cały zestaw tagów dla tej wersji językowej | Usunąć blokadę noindex ze strony lub zmienić URL w hreflang na indeksowalny odpowiednik |
| Konflikt canonical vs hreflang | rel=alternate i rel=canonical wskazują na różne URL tej samej strony | Sprzeczne sygnały — Google ignoruje oba tagi | Zaktualizować hreflang tak, aby wskazywał wyłącznie na kanoniczny URL |
| Brak tagu x-default | Nie zdefiniowano wersji domyślnej dla użytkowników spoza obsługiwanych języków | Brak strony rezerwowej — Google samodzielnie wybiera wersję | Dodać <link rel="alternate" hreflang="x-default" href="[URL domyślny]"> do zestawu |
| Błędna struktura sitemap XML (brak namespace) | Brak deklaracji xmlns:xhtml w elemencie <urlset> | Sitemap z hreflang ignorowana przez Google | Dodać xmlns:xhtml="http://www.w3.org/1999/xhtml" do elementu otwierającego <urlset> |
| Niepełny klaster | Co najmniej jedna wersja językowa nie jest uwzględniona w zestawie tagów pozostałych stron | Niesymetryczny klaster — algorytm może nie rozpoznać powiązań między wersjami | Zaktualizować zestawy tagów na wszystkich stronach klastra tak, aby każda wymieniała wszystkie wersje |
Tabela obejmuje błędy zidentyfikowane w dokumentacji Google Search Central oraz w studium Ahrefs przeprowadzonym na próbie 374 756 domen. Każdy z wymienionych błędów jest wykrywalny przez narzędzia crawlujące — Screaming Frog, Ahrefs Site Audit — lub przez raport International Targeting w Google Search Console.
Przy rozbudowywaniu witryny o kolejne wersje językowe ryzyko pojawienia się błędów typu niekompletny klaster rośnie — każda nowa wersja wymaga aktualizacji zestawów tagów na wszystkich istniejących stronach, nie tylko na stronach nowo dodanej wersji.
Hreflang a tag canonical — jak unikać konfliktu sygnałów
Konflikt między hreflang a canonical powstaje, gdy rel="alternate" wskazuje na inny URL niż rel="canonical" tej samej strony — Google interpretuje taką sytuację jako sprzeczne deklaracje i ignoruje oba sygnały. Jest to jeden z trudniejszych do wykrycia błędów, ponieważ tagi canonical i hreflang mogą być zarządzane przez różne moduły CMS lub wtyczki działające niezależnie.
Zasada fundamentalna: hreflang zawsze musi wskazywać na kanoniczny URL strony, nie na alias, URL z parametrami sesji, URL z przekierowaniem 301 ani żaden inny adres, który sam posiada odmienny tag canonical. Jeśli strona example.com/pl/oferta/ ma tag canonical wskazujący na example.com/pl/oferta (bez końcowego slash), to hreflang musi używać dokładnie tego samego formatu URL co canonical.
Błąd „hreflang to non-canonical” widoczny w raporcie Google Search Console w zakładce International Targeting oznacza, że Google zidentyfikował niezgodność między URL wskazanym w hreflang a kanonicznym URL strony. Procedura naprawy obejmuje: (1) wyeksportowanie listy URL z błędem z GSC, (2) porównanie wartości href w tagach hreflang z wartościami rel=canonical na tych samych stronach, (3) ujednolicenie URL tak, aby hreflang wskazywał wyłącznie na adresy kanoniczne.
Duplikat treści językowej — sytuacja, gdy dwie wersje językowe zawierają podobną treść — nie jest problemem, jeśli hreflang jest wdrożony poprawnie. Google dzieli sygnały rankingowe między wersje w klastrze zamiast traktować je jako konkurujące duplikaty, co zmniejsza ryzyko penalizacji. Strony z parametrami sesji (?sid=), parametrami śledzenia UTM lub filtrami kategorii stanowią najczęstsze źródło niezamierzonych konfliktów canonical vs hreflang.
Zależność między tagu canonical a indeksacją strony ma bezpośredni wpływ na skuteczność hreflang — jeśli rel=alternate wskazuje na URL z innym tagiem canonical, algorytm traktuje taką deklarację jako sprzeczny sygnał i ignoruje obie.
Przy migracjach witryny wielojęzycznej — np. przy przechodzeniu ze struktury subdomenowej na podkatalogową — ryzyko konfliktu canonical vs hreflang jest szczególnie wysokie w okresie przejściowym, gdy przekierowania 301 funkcjonują równolegle ze starymi tagami hreflang wskazującymi na adresy przed migracją.
Wartość x-default — zastosowanie, rola i typowe błędy
Wartość x-default wskazuje stronę wyświetlaną użytkownikom, których język nie odpowiada żadnej z dostępnych wersji językowych — jej brak nie blokuje indeksacji, lecz pozbawia witrynę zdefiniowanej wersji domyślnej. Google wówczas samodzielnie wybiera wersję na podstawie własnych sygnałów, co może skutkować niespójnym doświadczeniem użytkowników z krajów nieobjętych żadną wersją językową.
„Wartość hreflang x-default określa neutralny pod względem języka i regionu adres URL do fragmentu treści, gdy witryna nie obsługuje języka i regionu użytkownika.”2
Definicja ta pochodzi z oficjalnego bloga Google Search Central i precyzuje funkcję x-default jako elementu rezerwowego klastra hreflang, nie jako domyślnej wersji językowej witryny w ogólnym sensie.
Typowe zastosowania x-default obejmują dwa scenariusze: stronę wyboru języka (language selector), która nie jest przypisana do żadnego konkretnego rynku językowego, lub wersję angielską jako fallback dla użytkowników spoza obsługiwanych regionów. Mechanizm best-match stosowany przez Google przebiega w sekwencji: dopasowanie język+kraj (np. pl-PL), następnie sam kod języka (np. pl), a na końcu wersja x-default. Dopiero przy braku wszystkich trzech dopasowań algorytm działa na podstawie własnych sygnałów.
W 2024 roku Gary Illyes z Google potwierdził aktualizację dokumentacji zakazującą łączenia wielu atrybutów hreflang w jednym tagu <link>. Oznacza to, że każda kombinacja język–URL musi być zadeklarowana jako osobny tag — zapis <link rel="alternate" hreflang="pl" hreflang="pl-PL" href="..."> jest niepoprawny. Aktualizacja ta nie jest omawiana w żadnym polskim artykule z TOP10, a jej naruszenie skutkuje ignorowaniem zduplikowanych deklaracji.
Typowym błędem przy x-default jest przypisanie tej wartości do strony oznaczonej noindex lub zablokowanej przez robots.txt. Taka strona jest nieindeksowalna — Google ignoruje jej deklarację x-default, co dezaktywuje mechanizm rezerwowy dla całego klastra. Przed wdrożeniem x-default weryfikacja indeksowalności wskazanego URL jest elementem obowiązkowym.
Przy braku x-default klaster hreflang jest formalnie kompletny technicznie, lecz pozbawiony jawnie zdefiniowanej wersji rezerwowej — co nie generuje błędu w GSC, ale może prowadzić do niespójnego wyświetlania wersji dla użytkowników spoza obsługiwanych rynków językowych.
Weryfikacja i audyt wdrożenia hreflang
Weryfikacja hreflang obejmuje trzy warstwy — raport GSC, skanowanie crawlerem i testy pojedynczych URL — przy czym każda warstwa wykrywa inne kategorie błędów. Pełna weryfikacja wymaga zastosowania wszystkich trzech warstw sekwencyjnie.
Google Search Console — raport International Targeting dostępny w zakładce Language — wskazuje błędy brakujących tagów powrotnych, nieprawidłowych kodów językowych oraz stron hreflang nieindeksowalnych. Raport ten działa na danych zebranych podczas crawlowania przez Googlebota, więc nowe wdrożenie pojawia się w raporcie dopiero po przeliczeniu przez algorytm — proces ten trwa od kilku dni do kilku tygodni w zależności od częstotliwości crawlowania witryny.
Screaming Frog SEO Spider w trybie skanowania HTML weryfikuje kompletność tagów hreflang na poziomie każdego URL — identyfikuje brakujące self-reference, nieprawidłowe kody ISO oraz tagi wskazujące na URL niedostępne (błąd 404) lub przekierowujące (301/302). Konfiguracja skanowania powinna obejmować wszystkie wersje językowe jako zakresy crawlowania, aby narzędzie mogło sprawdzić wzajemność tagów między domenami lub subdomenami.
Ahrefs Site Audit umożliwia masową weryfikację klastrów hreflang — raport Hreflang Issues prezentuje pogrupowane błędy według typu wraz z listą dotkniętych URL. Narzędzie wykrywa broken links w tagach hreflang (URL wskazany w href zwraca błąd), co jest szczególnie istotne przy dużych witrynach, gdzie ręczna weryfikacja URL jest niepraktyczna.
Checklist pre-launch dla wdrożeń hreflang obejmuje: weryfikację wzajemności tagów (return tag na każdej stronie docelowej), obecność self-reference na każdej stronie, poprawność kodów ISO 639-1 i ISO 3166-1 Alpha-2, brak dyrektywy noindex na stronach wskazanych w hreflang, brak blokad robots.txt dla URL klastra.
Sprawdzenie, czy żadna ze stron klastra hreflang nie posiada blokady strony noindex, jest elementem obowiązkowym checklisty przed publikacją, ponieważ taka blokada dezaktywuje cały zestaw tagów dla danej wersji językowej.
Jeśli po wdrożeniu hreflang Google nadal wyświetla nieodpowiednią wersję językową, najbardziej prawdopodobne jest, że jeden z tagów powrotnych jest brakujący lub wskazuje na URL inny niż kanoniczny — te dwie przyczyny odpowiadają łącznie za większość udokumentowanych przypadków nieprawidłowego działania hreflang w warunkach produkcyjnych.
Najczęściej zadawane pytania
Czym różni się hreflang od atrybutu HTML lang?
Atrybut HTML lang informuje przeglądarki i czytniki ekranu o języku strony, natomiast Google nie wykorzystuje go do geotargetowania ani wyboru wersji językowej w wynikach wyszukiwania. Hreflang stanowi sygnał SEO przeznaczony dla Google i Yandex, wskazujący powiązania między wielojęzycznymi wersjami strony. Oba atrybuty powinny pozostawać spójne, ponieważ inne wyszukiwarki (Bing, DuckDuckGo) korzystają z atrybutu lang przy rozpoznawaniu języka dokumentu.
Czy brak tagu x-default powoduje błąd indeksacji?
Brak x-default nie blokuje indeksacji i nie generuje błędu w raporcie Google Search Console — Google traktuje tę wartość jako zalecenie, nie wymóg techniczny. Jego pominięcie oznacza jedynie brak zdefiniowanej strony domyślnej dla użytkowników, których język nie pasuje do żadnej wersji językowej w klastrze. Google wówczas samodzielnie wybiera wersję do wyświetlenia na podstawie własnych sygnałów — historia użytkownika, lokalizacja IP, język interfejsu przeglądarki.
Jak hreflang działa przy wielu wersjach tego samego języka, np. en-US i en-GB?
Przy kilku regionalnych wariantach tego samego języka wdrażane są tagi z kodem języka i regionu (hreflang="en-us", hreflang="en-gb") oraz ogólny tag językowy bez regionu (hreflang="en") jako fallback dla użytkowników anglojęzycznych spoza tych dwóch krajów. Google stosuje sekwencję best-match: najpierw dopasowanie język+kraj, następnie sam język, na końcu x-default. Wszystkie warianty — en-us, en-gb, en — muszą wzajemnie się wskazywać w kompletnym zestawie tagów.
Czy można stosować hreflang jednocześnie w HTML i sitemap XML?
Technicznie jest to możliwe, ale Google nie wskazuje żadnych korzyści z jednoczesnego stosowania obu metod — wystarczy jedna, konsekwentnie stosowana w całej witrynie. Mieszanie metod utrudnia zarządzanie przy aktualizacjach i generuje ryzyko niespójności zestawów tagów, gdy jedna metoda zostanie zaktualizowana, a druga nie. Właściwe podejście to wybór metody adekwatnej do architektury witryny i utrzymanie jej spójności przy każdym dodaniu nowej wersji językowej.
Jak zweryfikować poprawność wdrożenia hreflang po publikacji?
Raport International Targeting w Google Search Console (zakładka Language) wskazuje brakujące tagi powrotne i nieprawidłowe kody językowe na podstawie danych zebranych przez Googlebota. Skanowanie przez Screaming Frog lub Ahrefs Site Audit pozwala sprawdzić kompletność tagów na poziomie każdego URL bez oczekiwania na recrawl. Zewnętrzne narzędzia walidacyjne, takie jak generator tagów hreflang Aleydy Solis, umożliwiają testowanie poprawności składni pojedynczych zestawów tagów przed wdrożeniem na produkcję.
Co powoduje błąd „hreflang to non-canonical” i jak go naprawić?
Błąd pojawia się, gdy tag hreflang wskazuje na URL niebędący kanonicznym adresem strony — np. na URL z przekierowaniem 301, na adres z parametrami sesji lub na wersję strony posiadającą odmienny tag rel="canonical". Google ignoruje takie tagi, ponieważ rel="alternate" i rel="canonical" wskazujące na różne adresy tworzą sprzeczny sygnał, który algorytm nie może jednoznacznie rozstrzygnąć. Naprawa polega na wyeksportowaniu listy błędnych URL z GSC, porównaniu wartości href w hreflang z tagami canonical na tych stronach i zaktualizowaniu tagów hreflang tak, aby wskazywały wyłącznie na kanoniczne adresy.
Podsumowanie
- Tagi hreflang wdrażane są w sekcji
<head>HTML, nagłówkach HTTP lub sitemap XML — wybór metody determinuje skalę zarządzania przy aktualizacjach struktury językowej - Każda strona zawiera pełny zestaw tagów obejmujący wszystkie wersje językowe łącznie z odniesieniem do siebie samej (self-reference)
- Tagi hreflang działają parami — brak tagu powrotnego sprawia, że Google ignoruje całą deklarację dla danej pary stron
- Regularne audyty przez Google Search Console i narzędzia crawlujące pozwalają wykrywać błędy: nieprawidłowe kody ISO, broken links i brakujące self-reference
Źródła
- Ahrefs: How to Construct a Hreflang Tag
- Moz: Hreflang Tag Attributes — How to Implement Them
- Delante: Hreflangi. Jak prawidłowo oznaczać wersje językowe strony?
- Google Search Central: Poinformuj Google o zlokalizowanych wersjach strony ↩︎
- Google Search Central Blog: Jak może Ci pomóc x-default ↩︎
