Polska strona linkuje do angielskiej, angielska do innej polskiej, a trzecia wersja przekierowuje wszystkich na homepage. Canonical wskazuje jeszcze inny adres. Hreflang jest obecny, więc technicznie „mamy go”. Praktycznie użytkownik i wyszukiwarka dostają trzy różne instrukcje wyboru języka.
Hreflang powinien opisywać rzeczywiste odpowiedniki treści. Wymaga zwrotnych linków, pełnych adresów i spójnego canonical. Nie jest tłumaczeniem ani mechanizmem naprawiającym przypadkową strukturę językową.
Zacznij od mapy rzeczywistych wersji
Wypisz polskie i angielskie adresy, intencję, wersję treści, status i właściciela. Nie każda strona ma odpowiednik. Nie twórz hreflang do strony głównej jako zamiennika każdego artykułu.
Jeżeli tłumaczenie jest robocze lub niekompletne, oznacz proces przed publikacją. Wersja językowa powinna odpowiadać na to samo pytanie, ale może mieć lokalne przykłady i warunki.
Nie tłumacz automatycznie całej biblioteki dla samej obecności. Lepiej mieć kilka zatwierdzonych odpowiedników niż setki stron z niepewnymi faktami.
Kiedy hreflang jest potrzebny
Stosuj go przy rzeczywistych wersjach językowych lub regionalnych tej samej treści. Google opisuje go jako sposób wskazania alternatywnych wariantów, nie jako wymóg dla każdej strony.
Jeżeli serwis jest tylko polski, nie dodawaj hreflang dla samego posiadania. Nie twórz angielskich stron bez użytkowników i procesu. Brak hreflang nie jest błędem w jednojęzycznej witrynie.
Przy regionalnych wersjach tego samego języka zapisz, co się różni: cena, warunki, prawo, dostępność. Nie używaj regionu dla samej mapy marketingowej.
Pełne adresy i zwrotne linki
Każda wersja powinna linkować do innych oraz do samej siebie zgodnie z aktualnymi zaleceniami Google. Używaj pełnych adresów z protokołem. Nie polegaj na jednokierunkowej mapie w CMS.
Jeżeli strona A wskazuje B, B powinna wskazywać A. Brak zwrotnych linków może powodować zignorowanie adnotacji. Test musi obejmować wszystkie wersje, nie tylko polską.
Nie wskazuj na przekierowania i strony testowe. Adresy powinny być kanoniczne i dostępne. Po zmianie URL zaktualizuj wszystkie wzajemne odwołania.
Kody języka i regionu
Użyj poprawnych kodów języka ISO 639-1 i opcjonalnie regionu ISO 3166-1 Alpha 2. Pierwszy kod oznacza język, a opcjonalny kolejny region. Wielkość liter nie zmienia znaczenia: przykładowo samo „PL” oznacza język polski, natomiast „pl-PL” oznacza polski dla Polski.
Dla polskiej treści zwykle używasz pl, dla angielskiej en. Regionalne warianty wymagają rzeczywistej różnicy i procesu. Nie twórz en-PL tylko dlatego, że brzmi międzynarodowo.
Google opisuje również ograniczenia niektórych kodów. Sprawdź aktualną dokumentację przed wdrożeniem. Nie generuj własnych skrótów dla wygodnych regionów.
x-default jako ścieżka zapasowa
x-default wskazuje wariant dla użytkowników bez dopasowanej wersji. Może być stroną wyboru języka lub rozsądnym domyślnym adresem. Nie musi prowadzić do przypadkowej wersji regionu.
Nie używaj x-default jako sposobu na naprawę braku mapowania. Najpierw zadbaj o rzeczywiste odpowiedniki. Strona zapasowa powinna pomagać wybrać, a nie blokować treści.
Sprawdź, czy strona wyboru nie wymaga niepotrzebnego kliknięcia przy każdej wizycie. Użytkownik powinien móc otworzyć właściwą wersję i wrócić do niej później.
Canonical zgodny z wersją
Każda wersja językowa powinna mieć właściwy canonical, zwykle do siebie, jeżeli jest samodzielną treścią. Nie wskazuj wszystkich wersji na polską jako jedyną prawdę, jeżeli chcesz ich używać w wynikach.
Canonical i hreflang odpowiadają na różne pytania. Jeden opisuje preferowany adres wariantu, drugi relacje językowe. Nie używaj jednego do naprawy drugiego bez analizy.
Przy duplikatach technicznych stosuj zasady z artykułu o testach canonical i linków. Sprawdź zgodność kodu z publicznym adresem.
Tłumaczenie treści i metadanych
Przetłumacz title, description, H1, treść, alt, anchor i dane strukturalne. Nie zostawiaj angielskich metadanych przy polskiej stronie tylko dlatego, że CMS kopiuje je automatycznie.
Zachowaj tę samą intencję i warunki. Nie zmieniaj ceny, obietnic ani źródeł bez procesu. Model może przygotować szkic, ale redaktor i właściciel potwierdzają znaczenie.
Przy tłumaczeniach stosuj zasady z artykułu o słowniku i redakcji AI. Hreflang nie ocenia jakości tłumaczenia. To twoja praca.
Linki wewnętrzne w wersji językowej
Linki powinny prowadzić do odpowiedników w tym samym języku, jeżeli istnieją. Nie kieruj angielskiego czytelnika na polską dokumentację bez informacji i alternatywy.
Przy usługach Aeneia pokazuj właściwą wersję strony i zakres. Nie tłumacz nazwy usługi bez zgodności z oficjalną ofertą. Aeneia Design i Aeneia Audit powinny być opisane zgodnie z rzeczywistym procesem.
Przełącznik języka powinien prowadzić do odpowiednika, nie do strony głównej. Użytkownik nie powinien tracić miejsca w artykule po zmianie języka.
Obrazy, daty i autorzy
Zachowaj rzeczywistego autora i rolę, ale przetłumacz bio zgodnie z procesem. Nie twórz osobnych osób dla każdej wersji. Autor w danych strukturalnych powinien być zgodny z widoczną treścią.
Obraz może wymagać innego tekstu lub wersji, jeżeli zawiera język i lokalne dane. Sprawdź prawa i alt. Nie przenoś automatycznie wszystkich zrzutów.
Data publikacji i modyfikacji powinna odpowiadać historii wersji. Nie przepisuj oryginalnej daty na nowe tłumaczenie bez procesu. Zachowaj wersję źródła.
Przykład: polski artykuł i angielski odpowiednik
Polska strona opisuje test dokumentów z polskimi znakami. Angielska zachowuje ten sam proces i przykłady, ale objaśnia kontekst dla czytelnika spoza Polski. Obie wersje mają właściwe canonical i linki zwrotne.
Anchor w polskiej prowadzi do angielskiej jako wersji językowej, a nie zastępuje linków do polskiej dokumentacji. x-default wskazuje rozsądną stronę wyboru lub domyślną.
Po zmianie testu aktualizujesz obie wersje i sprawdzasz daty. Nie publikujesz nowego wyniku tylko po angielsku bez decyzji o polskiej wersji.
Przykład: brak angielskiej wersji
Nie ma zatwierdzonego tłumaczenia. Polska strona nie dodaje hreflang do strony głównej EN. Przełącznik języka pokazuje dostępne wersje zgodnie z procesem, a nie udaje kompletu.
Jeżeli użytkownicy potrzebują tłumaczenia, przygotuj je i odbierz. Dopiero potem publikujesz relację. Brak odpowiednika jest lepszy niż zły odpowiednik.
Nie zgłaszaj angielskiego adresu do sitemapy przed publikacją i odbiorem. Strona robocza nie powinna być indeksowana jako kompletna.
Test na wszystkich wersjach
Otwórz każdą wersję i porównaj linki, canonical, hreflang, treść, daty i metadane. Sprawdź pełne adresy oraz status 200. Nie testuj tylko polskiej strony.
Sprawdź, czy linki zwrotne prowadzą do tego samego odpowiednika i czy x-default działa. Po zmianie adresu powtórz zależne przypadki. Jedna stara wersja może zepsuć całą relację.
Przy odbiorze użyj użytkownika lub redaktora języka. Automatyczny test nie oceni, czy tłumaczenie zmienia warunek lub ton. Technika i język wymagają dwóch kontroli.
Migracja wersji językowych
Przy zmianie adresów przygotuj mapę jeden do jednego dla każdej wersji. Nie przekierowuj wszystkich języków na polską stronę główną. Zachowaj intencję i relacje.
Zaktualizuj przekierowania, canonical, hreflang, sitemapę i linki wewnętrzne. Stare wersje nie powinny zostawać jako nieoznaczone duplikaty.
Przy migracji stosuj zasady z artykułu o przekierowaniach AI i SEO. Każdy język wymaga własnego testu skutku.
Odbiór przez technikę i redaktora języka
Technik sprawdza kody, linki, canonical, statusy i sitemapę. Redaktor ocenia intencję, warunki, ton i metadane. Właściciel produktu potwierdza wersje funkcji i ceny.
Nie akceptuj tłumaczenia na podstawie samego podobieństwa słów. Porównaj przykłady i źródła. Model może zgładzić warunek, który zmienia decyzję.
Po publikacji sprawdź przełącznik, linki i dane strukturalne na telefonie. Użytkownik powinien trafić na tę samą odpowiedź we właściwym języku bez dodatkowej detektywistyki.
Utrzymanie po nowych publikacjach
Przy każdym nowym artykule zdecyduj, czy ma wersję językową i kto ją odbiera. Nie kopiuj hreflang automatycznie z poprzedniego artykułu. Slug i odpowiednik muszą być zgodne.
Przy zmianie źródła zaktualizuj zależne wersje. Nie zostawiaj jednej z nowym faktem i drugiej z archiwalnym bez oznaczenia. Właściciel powinien znać zakres przeglądu.
Raz na jakiś czas sprawdź aktualne zasady Google. Dokumentacja jest aktualizowana, a stare porady o hreflang potrafią żyć własnym życiem w szablonach.
Minimalny standard dla dwóch języków
Zacznij od kilku ważnych stron z rzeczywistymi odpowiednikami. Dodaj pełne adresy, zwrotne linki, właściwe kody i canonical. Opcjonalnie dodaj x-default jako stronę zapasową. Przetłumacz metadane i treść z odbiorem.
Nie wdrażaj trzech metod jednocześnie bez potrzeby. Google opisuje HTML, nagłówki HTTP i sitemapę jako równoważne metody; wybierz proces, który potrafisz utrzymać. Więcej miejsc znaczy więcej możliwości sprzeczności.
Sitemapa i indeksacja wersji
Jako praktykę porządkową utrzymuj w sitemapie aktualne kanoniczne adresy opublikowanych wersji, a nie strony robocze i przekierowania. Google dopuszcza także wskazywanie wersji przez HTML lub nagłówki HTTP, bez obowiązku użycia sitemapy dla hreflang. Jeżeli wybierasz hreflang w sitemapie, zachowaj zgodność relacji przy każdym adresie zgodnie z aktualną dokumentacją Google.
Po publikacji sprawdź, czy wersje są dostępne i czy nie mają noindex. Zgłoszenie sitemapy nie gwarantuje indeksacji ani wyboru właściwej wersji. Monitoruj, jakie adresy są widoczne i czy użytkownicy trafiają na odpowiedni język.
Automatyczne testy relacji
Przygotuj test sprawdzający, czy każda strona linkuje do siebie i właściwych odpowiedników, czy linki są zwrotne oraz czy kody są poprawne. Dodaj kontrolę pełnych adresów i braku przekierowań. Nie ograniczaj się do obecności atrybutu hreflang.
Dodaj przypadek braku odpowiednika i stronę usuniętą. System nie powinien zgadywać go z podobnego artykułu. Po zmianie sluga zaktualizuj zależne relacje przed publikacją. Jeden automatyczny alias może utworzyć pętlę zgodnych formalnie błędów.
Język interfejsu i treści niezależnych
Nie tłumacz tylko menu i stopki, zostawiając główną treść w innym języku bez oznaczenia. Google opisuje takie sytuacje jako możliwe warianty, ale użytkownik powinien rozumieć, co jest przetłumaczone. Nie przedstawiaj częściowej wersji jako pełnej.
Jeżeli dokumentacja jest tylko polska, opisz to przy linku z angielskiej strony. Możesz zaproponować kontakt lub inną pomoc bez udawania dostępnej wersji. Jasność jest lepsza niż automatyczne przekierowanie na stronę główną.
Przegląd po zmianie treści źródłowej
Przy zmianie oryginału przygotuj listę różnic dla redaktora języka. Nie generuj całego tłumaczenia od nowa, jeżeli zmiana dotyczy jednego warunku. Zachowaj zatwierdzone fragmenty i powtórz tylko zależny odbiór.
Sprawdź, czy obie wersje opisują ten sam fakt i datę. Jeżeli jedna wymaga późniejszej aktualizacji, oznacz to w procesie. Relacja hreflang nie zastępuje synchronizacji treści. Jest tylko adresem do wersji, za które nadal odpowiadasz.
Aeneia Design pomaga zaprojektować wersje językowe i doświadczenie. Przy technicznym odbiorze pomocny jest przewodnik Aeneia Signal.
Dla pary stron otwórz obie wersje i sprawdź wzajemne wskazania hreflang oraz ich kanoniczne adresy. Następnie porównaj warunki oferty i daty w treści, ponieważ poprawne znaczniki nie wyrównują różnic redakcyjnych. Jeśli odpowiednik jeszcze nie istnieje, nie wskazuj przypadkowej strony tylko po to, by wypełnić relację.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
