Strona firmy po polsku, ukraińsku i angielsku: hreflang bez błędów

Firma w Warszawie mówi trzema językami, a strona jednym

Recepcja odbiera telefony po polsku, ukraińsku i angielsku, bo tylu jest klientów za drzwiami. Strona internetowa często zostaje w tyle: jedna wersja polska, czasem dorzucona angielska podstrona z przetłumaczonym menu, a ukraińska wersja — jeśli w ogóle istnieje — to osobna podstrona bez żadnego technicznego połączenia z resztą.

Efekt jest podwójny. Po pierwsze, klient szukający po ukraińsku często w ogóle nie trafia na twoją stronę, bo Google nie wie, że taka wersja istnieje albo do czego się odnosi. Po drugie — nawet jeśli trafi — może zobaczyć wersję w złym języku, bo bez poprawnej konfiguracji wyszukiwarka wybiera stronę według własnych sygnałów, a nie według twoich intencji. Analiza stron warszawskich firm pokazuje, że to właśnie takie techniczne luki, a nie brak treści, najczęściej sprawiają, że klienci nie zostawiają zapytań — trafiają na stronę, ale nie na tę, która odpowiada na ich pytanie w ich języku.

Co hreflang naprawdę mówi Google (i czego nie robi)

Hreflang to adnotacja, która informuje Google o istnieniu językowych lub regionalnych wariantów tej samej strony, żeby wyszukiwarka mogła w wynikach pokazać użytkownikowi wersję dopasowaną do jego języka lub regionu. To wszystko — hreflang nie tłumaczy treści, nie poprawia jej jakości i nie zastępuje samego tłumaczenia.

Google nie rozpoznaje języka strony po hreflang ani po atrybucie lang

To jest najczęstsze błędne założenie: hreflang nie mówi Google, w jakim języku jest napisana strona. Google ustala język strony własnymi algorytmami, analizując rzeczywistą treść — nie deklarację w kodzie. Oznacza to praktyczną konsekwencję: jeśli oznaczysz podstronę jako hreflang="uk", a tekst na niej jest po polsku, hreflang tego nie naprawi. Zanim zajmiesz się znacznikami, upewnij się, że treść faktycznie jest w deklarowanym języku — nie połowicznie, nie tylko w menu.

Trzy sposoby wdrożenia — wystarczy jeden

Google akceptuje trzy metody przekazania informacji o wersjach językowych. Nie trzeba stosować wszystkich naraz — wystarczy jedna, konsekwentnie na całej stronie.

Tagi w nagłówku head

Najpopularniejsza metoda dla stron HTML: w sekcji head każdej wersji językowej umieszcza się serię znaczników link rel="alternate" hreflang="...", po jednym dla każdej wersji, włącznie z wersją, na której się znajdujesz. To rozwiązanie sprawdza się dobrze przy kilkunastu, kilkudziesięciu podstronach — więcej i kod head zaczyna puchnąć.

Nagłówki HTTP i mapa witryny

Dla plików, które nie mają sekcji head — na przykład PDF-ów — informację o wersjach językowych można przekazać w nagłówku HTTP odpowiedzi serwera. Trzecia droga to wpisanie relacji hreflang bezpośrednio do mapy witryny (sitemap) — rozwiązanie wygodne przy dużej liczbie stron, bo aktualizuje się jeden plik zamiast kodu każdej podstrony osobno. Wybór metody zależy od tego, kto na co dzień zarządza stroną: przy stronie firmowej budowanej na jednym silniku najprościej trzymać się tagów w head.

Reguły, które trzeba spełnić niezależnie od metody

Niezależnie od wybranej metody obowiązują te same zasady techniczne, opisane przez Google Search Central:

• każda wersja językowa musi wymieniać samą siebie oraz wszystkie pozostałe wersje — nie tylko wskazywać na inne, ale też deklarować siebie;
• adresy muszą być pełne, łącznie z protokołem https:// — względne ścieżki nie działają;
• kod języka zapisuje się w formacie ISO 639-1 (np. pl, uk, en), a region — opcjonalnie — w formacie ISO 3166-1 Alpha 2 (np. pl-PL, gdy trzeba rozróżnić region, a nie tylko język).

Dla trzech wersji — polskiej, ukraińskiej i angielskiej — oznacza to, że w kodzie strony polskiej muszą znaleźć się trzy znaczniki: jeden wskazujący samą siebie, drugi na wersję ukraińską, trzeci na angielską. Dokładnie to samo powtarza się w kodzie wersji ukraińskiej i angielskiej.

x-default — strona dla języków, których nie wymieniłeś

Wartość x-default w atrybucie hreflang wskazuje stronę, którą Google powinien pokazać użytkownikom mówiącym w językach, dla których nie masz osobnej wersji — na przykład użytkownikowi piszącemu po niemiecku, gdy masz tylko pl, uk i en. Najczęściej x-default kieruje się na stronę z wyborem języka albo na wersję domyślną firmy, czyli zwykle polską.

x-default nie jest obowiązkowy, ale bez niego użytkownicy spoza trzech obsługiwanych języków trafiają do wyszukiwarki bez jasnej wskazówki, którą wersję im pokazać — a to zwiększa ryzyko, że zobaczą przypadkową podstronę zamiast strony głównej. To ten sam rodzaj problemu, co przy dostępności strony i zamawiania online — użytkownik trafia na stronę, ale nie potrafi na niej łatwo znaleźć tego, po co przyszedł.

Najczęstsze błędy, które psują hreflang

Konfiguracja hreflang bywa krucha — jeden brakujący element w jednej z wersji potrafi unieważnić całą resztę.

Brak linków zwrotnych

To błąd numer jeden według dokumentacji Google: jeśli strona X wskazuje na stronę Y jako jej wariant językowy, strona Y musi wskazywać z powrotem na X. Jeśli tego brakuje choćby dla jednej pary wersji, adnotacje mogą zostać przez Google zignorowane — nie tylko ta jedna niekompletna para, ale potencjalnie cały zestaw. Typowy scenariusz: dodajesz nową wersję ukraińską i wpisujesz w niej odnośniki do polskiej i angielskiej, ale zapominasz zaktualizować istniejące już wersje polską i angielską, żeby też wskazywały na nową ukraińską. Efekt: nowa wersja nigdy nie zaczyna działać technicznie tak, jak powinna.

Drugi typowy kłopot to wskazywanie hreflangiem na adres, który już nie istnieje albo nigdy nie istniał — na przykład po zmianie struktury adresów strony bez aktualizacji znaczników. Google napotyka błąd 404 zamiast obiecanej wersji językowej i traktuje cały zestaw z nieufnością.

Tłumaczenie tylko menu to duplikat treści

Częsty skrót: przetłumaczyć nawigację, stopkę i przycisk „zamów”, a resztę tekstu zostawić po polsku, licząc że to wystarczy jako „wersja angielska”. Z punktu widzenia wyszukiwarki to nie jest osobna wersja językowa — to niemal identyczna treść pod innym adresem, czyli duplicate content, zjawisko, przed którym ostrzega przewodnik SEO Google, zalecając ograniczanie tego rodzaju powtórzeń i stosowanie opisowych adresów URL.

rel="canonical" i kiedy go użyć

Dla stron zduplikowanych lub bardzo podobnych Google pozwala wskazać preferowany adres kanoniczny między innymi znacznikiem rel="canonical". To narzędzie do innego problemu niż hreflang: canonical mówi „to jest ta sama treść, licz tylko ten adres”, a hreflang mówi „to są różne języki tej samej treści, pokazuj każdemu jego wersję”. Mylenie tych dwóch mechanizmów — na przykład ustawienie canonicalu z wersji ukraińskiej na polską przy okazjonalnie różniącym się tekście — potrafi ukryć wersję ukraińską z wyników zamiast ją wypromować.

Co tłumaczyć obowiązkowo, a czego nie musisz

Nie każda podstrona wymaga pełnego tłumaczenia od pierwszego dnia, ale kilka elementów jest obowiązkowych, jeśli w ogóle deklarujesz daną wersję językową: opisy usług, które klient ma zrozumieć przed kontaktem, cennik lub zasady wyceny, dane kontaktowe i regulamin lub warunki świadczenia usługi. Jeśli te elementy zostają po polsku na „angielskiej” podstronie, to nie jest wersja angielska — to podstrona z angielskim nagłówkiem.

Pisanie tych treści od razu w trzech językach, a nie doklejanie tłumaczenia później, to praca copywritingu na całą stronę (Copywriting): nagłówki, ofertę i wezwania do działania spójne w każdej wersji, a nie osobne akapity dosyłane do tłumacza bez kontekstu reszty strony. Ten sam problem niespójności widać przy danych, które czytają asystenci AI — rozjazd między wersjami szkodzi w każdym języku tak samo, niezależnie od branży. Spójny opis firmy w każdej wersji wspiera też widoczność GEO / AI visibility (GEO / AI visibility), bo systemy czytające sieć widzą wtedy tę samą treść, nie trzy różne opowieści o firmie. Warto też pilnować, żeby masowe tworzenie kolejnych podstron językowych bez realnej treści nie zamieniło się w problem, przed którym ostrzega Google w wytycznych o generowaniu treści na dużą skalę — strona bez wartości dla użytkownika w danym języku nie pomoże, nawet jeśli technicznie ma poprawny hreflang.

Zrób to sam: tabela stron i sprawdzenie linków zwrotnych

Zanim uznasz konfigurację za gotową, zrób najprostszy możliwy audyt: tabelę, w której wierszami są kluczowe podstrony, a kolumnami — wersje językowe.

Puste pole w tabeli oznacza jedno z dwóch: albo wersja w tym języku nie istnieje i nie powinna mieć hreflangu, albo istnieje, ale ktoś zapomniał jej dodać do zestawu wzajemnych odnośników — a to właśnie ten drugi przypadek psuje całość.

Liczbę odnośników, które musisz sprawdzić, policzysz prostym wzorem: liczba wzajemnych odnośników = N × (N-1), gdzie N to liczba wersji językowych jednej podstrony. Dla trzech wersji (pl, uk, en) każda wersja wskazuje pozostałe dwie, więc N-1 = 2, a par kierunkowych do sprawdzenia jest 3 × 2 = 6, czyli: pl-uk, pl-en, uk-pl, uk-en, en-pl, en-uk. Dla czterech wersji byłoby to już 4 × 3 = 12 kierunków — dlatego przy każdej nowej wersji językowej warto od razu przejrzeć całą tabelę, a nie tylko dodać nowy wiersz.

Ostatni krok to jedno zdanie w wewnętrznej instrukcji firmy: kto aktualizuje wszystkie wersje językowe, gdy zmienia się cennik albo zakres usługi. Bez tego zapisu regularnie powstaje sytuacja, w której polska wersja ma nową cenę, a angielska i ukraińska — starą. Ten sam podział odpowiedzialności warto spisać przy okazji automatyzacji procesów w firmie — hreflang jest tylko jednym z wielu miejsc, gdzie brak jasnego właściciela zadania psuje efekt.

Jak to wygląda, gdy hreflang buduje system

Scenariusz publikacji nowej podstrony wygląda inaczej, kiedy hreflang nie jest ręczną checklistą:

Najpewniej działa to wtedy, gdy hreflang dla każdej pary powstaje automatycznie z jednego źródła, a wzajemne odnośniki są sprawdzane przed publikacją, żeby błąd opisany wyżej nie trafiał na żywą stronę. Poprawny hreflang to nie obietnica lepszych pozycji — to usunięcie technicznej przeszkody, która i tak nie zależy od jakości tekstu. Jeśli budujesz Strony i sklepy w kilku językach, projektowanie UI/UX (UI/UX design) przełącznika języka też ma znaczenie — użytkownik musi łatwo trafić do wersji w swoim języku, nie tylko wyszukiwarka, a osobne Landing page pod kampanie w każdym języku wymaga dokładnie tej samej dyscypliny co strona główna. Widoczność samych przetłumaczonych stron w wynikach to już zadanie SEO i map (SEO i mapy). Zobacz, jak to działa w ofercie stron i sklepów albo umów rozmowę o konkretnej stronie.

Najczęściej zadawane pytania

Czy każda wersja językowa musi mieć osobną domenę?

Nie. Hreflang działa niezależnie od tego, czy wersje językowe są na osobnych domenach, subdomenach (np. en.firma.pl) czy podkatalogach (np. firma.pl/en/) — warunkiem jest tylko to, żeby każda wersja miała swój pełny, stały adres URL i poprawnie wskazywała pozostałe wersje.

Co to jest x-default i kiedy warto go dodać?

x-default to wartość hreflang wskazująca stronę dla użytkowników w językach, których nie obsługujesz osobnymi wersjami. Warto go dodać, gdy masz np. trzy wersje (pl, uk, en), ale spodziewasz się ruchu też z innych krajów — x-default pokaże im stronę wyboru języka albo wersję domyślną zamiast przypadkowej podstrony.

Czy Google sam pozna, że moja podstrona jest po ukraińsku?

Google określa język strony na podstawie analizy samej treści, a nie na podstawie znacznika hreflang czy atrybutu lang w kodzie. Oznacza to, że jeśli podstrona ma być ukraińska, tekst na niej musi faktycznie być po ukraińsku — sam znacznik tego nie zastąpi.

Co się stanie, jeśli usunę jedną wersję językową ze strony?

Trzeba wtedy usunąć odnośniki do niej ze wszystkich pozostałych wersji, które wcześniej ją wskazywały. Pozostawienie martwego odnośnika hreflang do nieistniejącej już strony to jeden z typowych błędów, które mogą sprawić, że Google zacznie ignorować cały zestaw adnotacji.

Czy wystarczy przetłumaczyć samo menu i przycisk zamówienia?

Nie — z punktu widzenia wyszukiwarki to wciąż w większości ta sama treść pod innym adresem, czyli duplikat, a nie osobna wersja językowa. Obowiązkowo tłumaczy się przynajmniej opisy usług, cennik, dane kontaktowe i regulamin — inaczej deklarowana wersja językowa nie ma realnej treści do pokazania.

Jak sprawdzić, czy hreflang na mojej stronie w ogóle działa poprawnie?

Najprostszy sposób bez narzędzi zewnętrznych to otworzyć kod źródłowy każdej wersji językowej i ręcznie sprawdzić, czy wymienia samą siebie i wszystkie pozostałe wersje z pełnymi adresami — dokładnie według tabeli z sekcji „Zrób to sam” wyżej. Brak choćby jednego odnośnika zwrotnego wystarczy, żeby cała para przestała działać.