Znaczniki hreflang dla dwóch wersji językowych. Jak wdrożyć je bez błędów?

Firma ma stronę po polsku i po angielsku, a mimo to klient z zagranicy trafia z Google na polską podstronę, z której niczego nie rozumie. Bywa też odwrotnie: polski klient widzi w wynikach angielski tytuł i rezygnuje z kliknięcia. Przyczyna jest zwykle ta sama. Wyszukiwarka nie dostała jasnej informacji, że obie podstrony są swoimi odpowiednikami w różnych językach.

Taką informację przekazują znaczniki hreflang. Ta instrukcja jest przeznaczona dla właścicieli firm i osób opiekujących się stroną, która ma dokładnie dwie wersje językowe, na przykład polską i angielską albo polską i niemiecką. Przy dwóch wersjach wdrożenie jest proste, pod warunkiem że wykona się je starannie, bo jedna literówka potrafi unieważnić całą pracę.

Po lekturze czytelnik będzie umiał dobrać właściwe kody języków, ułożyć poprawny zestaw znaczników, umieścić go na stronie jedną z trzech metod opisanych przez Google, sprawdzić wynik i naprawić najczęstsze pomyłki. Dowie się też, czego po hreflang można oczekiwać, a czego nie.

Do czego służą znaczniki hreflang i czego nie należy od nich oczekiwać?

Hreflang to atrybut, którym opisuje się odpowiedniki tej samej podstrony przygotowane w innych językach lub dla innych krajów. Google podaje w dokumentacji, że dzięki tej informacji kieruje użytkownika do najodpowiedniejszej wersji strony na podstawie języka lub regionu. Osoba szukająca po angielsku ma więc większą szansę zobaczyć w wynikach wersję angielską, a nie polską.

Google zaznacza, że potrafi znaleźć inne wersje językowe także bez tych znaczników. Dodaje jednak, że wyraźne wskazanie odpowiedników jest zazwyczaj najlepszym rozwiązaniem.

Trzeba też wiedzieć, czego te znaczniki nie robią. Google wprost pisze, że nie używa hreflang ani atrybutu lang do rozpoznawania języka strony. Język określa samodzielnie, na podstawie widocznej treści. Jeśli więc „angielska” podstrona ma angielskie menu, ale opisy pozostały po polsku, sam znacznik niczego nie naprawi.

Hreflang nie podnosi także pozycji strony. Nie sprawia, że strona zacznie się wyświetlać w kraju, w którym do tej pory nie była widoczna. Jego zadanie jest węższe: gdy Google i tak chce pokazać daną stronę, ma wybrać właściwą wersję językową.

Wiele osób obawia się, że dwie wersje językowe zostaną uznane za powieloną treść. Dokumentacja Google rozstrzyga tę wątpliwość: zlokalizowane wersje strony są uznawane za duplikaty tylko wtedy, gdy główna treść pozostaje nieprzetłumaczona. Rzetelne tłumaczenie nie jest więc duplikatem.

Kiedy strona z dwiema wersjami językowymi potrzebuje hreflang?

Google wymienia trzy typowe sytuacje, w których zaleca wskazanie wersji alternatywnych. W przypadku dwóch języków wyglądają one następująco:

• cała zawartość strony jest przetłumaczona, czyli każda podstrona polska ma swój odpowiednik w drugim języku,
• treść jest w tym samym języku, ale różni się szczegółami dla dwóch krajów, na przykład walutą, cenami lub warunkami dostawy,
• przetłumaczony jest tylko szablon, czyli menu i stopka, a główna treść pozostaje w jednym języku, co zdarza się na stronach z wpisami użytkowników.

Warunkiem podstawowym jest to, aby każda wersja językowa miała własny adres. Google zaleca stosowanie różnych adresów URL dla różnych wersji językowych zamiast zmieniania treści pod tym samym adresem na podstawie plików cookie lub ustawień przeglądarki. Jeżeli strona pod jednym adresem pokazuje raz tekst polski, a raz angielski, nie ma czego oznaczać, a wyszukiwarka może w ogóle nie znaleźć drugiej wersji.

Układ adresów może być dowolny, o ile jest konsekwentny. Wersja angielska może działać w katalogu, na przykład example.com/en/, na subdomenie en.example.com albo w osobnej domenie. Google wyraźnie dopuszcza powiązanie znacznikami adresów z różnych domen. Odradza natomiast rozróżnianie języków parametrem w adresie.

Nie każda podstrona musi mieć odpowiednik. Jeżeli blog jest prowadzony tylko po polsku, wpisy blogowe po prostu nie dostają znaczników. Hreflang dodaje się wyłącznie tam, gdzie rzeczywiście istnieje para.

Co przygotować, zanim powstanie pierwszy znacznik?

Większość błędów bierze się z pośpiechu na etapie przygotowań. Zalecam poświęcić na nie pół godziny i wykonać czynności w podanej kolejności.

1. Sporządzenie spisu par w arkuszu kalkulacyjnym. W pierwszej kolumnie wpisuje się adres podstrony polskiej, w drugiej adres jej odpowiednika w drugim języku. Jeden wiersz to jedna para.
2. Ustalenie ostatecznej postaci każdego adresu. Należy otworzyć adres w przeglądarce i przepisać go z paska dokładnie w takiej formie, w jakiej strona się wczytała: z https, z przedrostkiem „www” lub bez niego, z ukośnikiem na końcu lub bez.
3. Wykreślenie adresów, które przekierowują w inne miejsce, zwracają błąd albo są wyłączone z indeksowania. Do znaczników trafiają tylko działające, docelowe adresy.
4. Dobranie kodu dla każdej z dwóch wersji według zasad opisanych niżej.
5. Podjęcie decyzji, która wersja ma być pokazywana osobom posługującym się innym językiem niż dwa obsługiwane. Do tego służy wartość x-default.
6. Wybór jednej metody wdrożenia: kod strony, mapa witryny albo nagłówek HTTP.

Jak dobrać kod języka i regionu?

Według dokumentacji Google wartość atrybutu składa się z jednej lub dwóch części rozdzielonych dywizem. Pierwsza część to kod języka w formacie ISO 639-1, czyli dwie litery. Druga, nieobowiązkowa, to kod regionu w formacie ISO 3166-1 alfa-2. Przykładowo pl oznacza treść po polsku bez względu na kraj, a en-GB treść po angielsku dla odbiorców z Wielkiej Brytanii.

Przy dwóch wersjach językowych w zdecydowanej większości przypadków wystarczy sam kod języka: pl i en albo pl i de. Kod regionu ma sens dopiero wtedy, gdy treść jest naprawdę przygotowana dla jednego kraju, na przykład zawiera ceny w funtach. Zapis en obejmuje wszystkich anglojęzycznych odbiorców, więc jest bezpieczniejszy dla firmy, która chce docierać szerzej.

Google ostrzega, że nie można podać samego kodu kraju. Pierwsza część zawsze oznacza język, a wyszukiwarka nie odgadnie go na podstawie kraju. Wielkość liter nie ma znaczenia dla Google, ale przyjęło się zapisywać język małymi literami, a region wielkimi.

Najwięcej pomyłek powstaje, gdy ktoś wpisuje skrót kraju znany z tablic rejestracyjnych lub z końcówki domeny zamiast kodu języka. Oto zapisy, które mylą się najczęściej:

• język angielski dla Wielkiej Brytanii to en-GB, a nie „en-UK”, ponieważ Google wymienia „UK” wśród kodów, które ignoruje,
• język czeski to cs, a nie „cz”,
• język ukraiński to uk, a nie „ua”,
• język szwedzki to sv, a nie „se”,
• język duński to da, a nie „dk”,
• język japoński to ja, a nie „jp”.

Google nie obsługuje też kodów spoza obu wymienionych standardów. Jeżeli w kreatorze wtyczki lub w szablonie pojawia się nietypowy zapis, należy porównać go z listą kodów ISO 639-1, zanim trafi na stronę.

Jak wygląda poprawny zestaw znaczników dla wersji polskiej i angielskiej?

Załóżmy, że polska podstrona z ofertą ma adres https://example.com/oferta/, a jej angielski odpowiednik https://example.com/en/offer/. Zestaw znaczników dla tej pary składa się z trzech wierszy:

<link rel="alternate" hreflang="pl" href="https://example.com/oferta/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/offer/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/offer/" />

Ten sam, identyczny zestaw umieszcza się na obu podstronach: na polskiej i na angielskiej. To najważniejsza zasada całego wdrożenia. Google wymaga, aby każda wersja językowa uwzględniała siebie oraz wszystkie pozostałe wersje. Polska podstrona wskazuje więc samą siebie i wersję angielską, a angielska samą siebie i wersję polską.

Jeżeli dwie strony nie wskazują na siebie nawzajem, znaczniki zostaną zignorowane. Google tłumaczy, że to zabezpieczenie: dzięki niemu nikt nie może na obcej stronie ogłosić jej wersją alternatywną cudzej podstrony. Skutek uboczny jest taki, że znacznik dodany tylko po jednej stronie pary nie działa wcale.

Druga zasada dotyczy adresów. Muszą być pełne i jednoznaczne, razem z protokołem. Poprawny jest zapis https://example.com/oferta/, a niepoprawne są skróty w rodzaju /oferta/ lub //example.com/oferta/.

Trzecia zasada: każda para podstron dostaje własny zestaw. Podstrona kontaktowa wskazuje angielską podstronę kontaktową, a oferta angielską ofertę. Wpisanie we wszystkich znacznikach adresu strony głównej drugiej wersji to częsty i dotkliwy błąd, o którym więcej w dalszej części.

Do czego służy wartość x-default i który adres w niej podać?

Wartość x-default wskazuje stronę dla osób, których ustawienia języka nie pasują do żadnej z przygotowanych wersji. Przy stronie polsko-angielskiej chodzi na przykład o odbiorcę z Francji lub Hiszpanii. Google zaleca dodanie takiej strony zastępczej, choć nie jest ona obowiązkowa.

Wartość ta powstała z myślą o stronach wyboru języka lub kraju, ale według dokumentacji można jej użyć na dowolnej stronie. Dla firmy z dwiema wersjami najrozsądniej wskazać w niej wersję angielską, bo to ją zrozumie większość osób spoza Polski. Jeżeli druga wersja jest niemiecka, a firma nie ma angielskiej, wybór zależy od tego, skąd pochodzi więcej zapytań.

Ten sam adres może wystąpić w zestawie dwa razy: raz z kodem języka, raz jako x-default. To zapis w pełni poprawny, zgodny z przykładami z dokumentacji.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a przejmę sprawę: zestawię pary adresów obu wersji językowych, dobiorę kody, wdrożę znaczniki i sprawdzę, czy każda podstrona ma poprawne odwołanie zwrotne.

Kod strony, mapa witryny czy nagłówek HTTP: którą metodę wybrać?

Google opisuje trzy sposoby przekazania informacji o wersjach językowych: w kodzie HTML, w nagłówkach HTTP oraz w mapie witryny. Z perspektywy wyszukiwarki są równoważne. Można stosować wszystkie naraz, ale nie daje to żadnych korzyści, a utrzymanie kilku wdrożeń jest wyraźnie trudniejsze. Radzę wybrać jedną metodę i trzymać się jej w całym serwisie.

Znaczniki w kodzie HTML to rozwiązanie najprostsze i najczęściej stosowane przy małych i średnich stronach. Zestaw wierszy umieszcza się w sekcji head każdej podstrony. Większość systemów do prowadzenia stron wielojęzycznych robi to samodzielnie.

Nagłówek HTTP jest przeznaczony głównie dla plików, które nie mają kodu HTML, takich jak dokumenty PDF. Jeżeli firma udostępnia cennik lub katalog w dwóch językach jako pliki PDF, serwer może dołączyć do odpowiedzi nagłówek w takiej postaci:

Link: <https://example.com/katalog.pdf>; rel="alternate"; hreflang="pl",
      <https://example.com/en/catalogue.pdf>; rel="alternate"; hreflang="en"

Nagłówek zwracany dla obu plików musi być identyczny i zawierać obie wersje, łącznie z tą, o którą właśnie poproszono. Ustawienie nagłówków wymaga dostępu do konfiguracji serwera, dlatego tę metodę lepiej zlecić administratorowi hostingu.

Jak zapisać wersje językowe w mapie witryny?

Mapa witryny sprawdza się, gdy podstron jest bardzo dużo albo gdy nie ma dostępu do sekcji head, na przykład w zamkniętym systemie sklepowym. Każdy adres dostaje własny element url z adresem w elemencie loc oraz z wpisami xhtml:link dla wszystkich wersji, łącznie z tą, której dotyczy dany element. Dla pary polsko-angielskiej plik zawiera więc dwa elementy url, a w każdym z nich ten sam zestaw wpisów.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
  xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/oferta/</loc>
    <xhtml:link rel="alternate" hreflang="pl" href="https://example.com/oferta/"/>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/offer/"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/offer/"/>
  </url>
  <url>
    <loc>https://example.com/en/offer/</loc>
    <xhtml:link rel="alternate" hreflang="pl" href="https://example.com/oferta/"/>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/offer/"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/offer/"/>
  </url>
</urlset>

Dwie rzeczy decydują o tym, czy plik zostanie odczytany. Pierwsza to deklaracja przestrzeni nazw xmlns:xhtml w elemencie otwierającym, przepisana dokładnie tak jak w przykładzie. Bez niej wpisy xhtml:link są dla wyszukiwarki niezrozumiałe. Druga to komplet wpisów w każdym elemencie url, również tego, który wskazuje własny adres.

Google podaje, że kolejność wpisów nie ma znaczenia, ale radzi jej nie zmieniać między elementami, bo wtedy łatwiej zauważyć pomyłkę. Wpisy podrzędne nie wliczają się do limitu adresów w mapie witryny. Mapa może ponadto zawierać tylko adresy z katalogu, w którym jest przechowywana, lub z jego podkatalogów.

Gotowy plik trzeba przekazać wyszukiwarce. Sposób postępowania opisałem we wpisie o tym, jak zgłosić mapę witryny w Google Search Console. Jeżeli wersje językowe działają w dwóch domenach, każda z nich powinna być dodana do Search Console jako osobna usługa.

Jak dodać znaczniki w WordPressie i w innych systemach?

W WordPressie druga wersja językowa powstaje zwykle dzięki wtyczce do wielojęzyczności, takiej jak Polylang lub WPML. Wtyczki tego rodzaju dodają znaczniki hreflang samodzielnie, ale tylko dla tych podstron, których tłumaczenia zostały ze sobą powiązane w panelu. Sama obecność angielskiej podstrony nie wystarczy, jeżeli system nie wie, czyim jest odpowiednikiem.

1. Należy otworzyć w panelu listę stron i przejść po kolei przez pozycje ze spisu par.
2. Przy każdej polskiej podstronie trzeba potwierdzić, że wtyczka pokazuje przypisane tłumaczenie i że jest nim właściwa podstrona, a nie jej kopia robocza.
3. Podstrony, które mają odpowiednik, ale nie są z nim połączone, wiąże się w edytorze tej podstrony, w polu tłumaczeń udostępnianym przez wtyczkę.
4. W ustawieniach języków wtyczki należy odczytać kod przypisany każdemu językowi i porównać go z kodem ustalonym wcześniej.
5. Po zmianach trzeba wyczyścić pamięć podręczną strony, ponieważ wtyczki przyspieszające potrafią jeszcze długo podawać starą wersję kodu.
6. Na koniec należy otworzyć obie podstrony z jednej pary i obejrzeć ich kod źródłowy w sposób opisany w dalszej części.

Jeżeli obie wersje językowe działają jako dwie osobne instalacje, na przykład w dwóch domenach, wtyczka do wielojęzyczności nie pomoże, bo żadna z instalacji nie zna adresów drugiej. Wtedy znaczniki dodaje się ręcznie lub przez wtyczkę przeznaczoną do łączenia osobnych witryn, a spis par z arkusza staje się podstawą całej pracy.

Przy ręcznym dodawaniu trzeba uważać na miejsce. Google wymaga, aby znaczniki znajdowały się w poprawnie zbudowanej sekcji head. Wklejenie ich w treść wpisu lub w stopkę nie przynosi efektu. Bezpieczniej użyć pola przeznaczonego na kod nagłówka w motywie lub we wtyczce niż edytować pliki motywu, ponieważ aktualizacja motywu nadpisuje takie zmiany.

W gotowych systemach sklepowych i kreatorach stron należy najpierw ustalić w dokumentacji dostawcy, czy system sam dodaje hreflang dla powiązanych tłumaczeń. Jeżeli nie, a dostęp do sekcji head jest zamknięty, pozostaje mapa witryny.

Jedna przestroga dotyczy wszystkich systemów: znaczniki powinny pochodzić z jednego źródła. Gdy dodaje je jednocześnie wtyczka językowa, wtyczka SEO i ręcznie wklejony kod, na stronie pojawiają się dwa lub trzy zestawy, często sprzeczne ze sobą.

Jak pogodzić hreflang z tagiem kanonicznym, przekierowaniami i przełącznikiem języka?

Hreflang nie działa w oderwaniu od reszty strony. Trzy inne ustawienia potrafią go wzmocnić albo unieważnić, dlatego należy je przejrzeć przy okazji wdrożenia.

Tag kanoniczny

Tag kanoniczny mówi wyszukiwarce, który adres jest właściwą wersją danej treści. Przy przetłumaczonych podstronach każda wersja językowa powinna wskazywać w nim samą siebie: polska oferta polską ofertę, angielska angielską. Wskazanie w angielskiej podstronie polskiego adresu jako kanonicznego oznacza prośbę o pominięcie wersji angielskiej, co stoi w sprzeczności ze znacznikami hreflang.

Adresy w hreflang powinny być tymi samymi adresami, które widnieją w tagach kanonicznych. Jeżeli hreflang prowadzi do adresu bez ukośnika na końcu, a tag kanoniczny do adresu z ukośnikiem, wyszukiwarka dostaje dwa różne komunikaty. Zasady ustawiania tego tagu omawiam osobno we wpisie o tym, jak wskazać Google właściwą wersję podstrony.

Przekierowania i blokady

Znacznik powinien prowadzić do adresu, który wczytuje się bezpośrednio. Adres przekierowujący w inne miejsce, zwracający błąd albo zablokowany w pliku robots.txt sprawia, że robot nie odczyta strony docelowej, a więc nie znajdzie na niej odwołania zwrotnego. Para przestaje wtedy być kompletna.

Osobną sprawą jest automatyczne przenoszenie odwiedzających do wersji językowej na podstawie przypuszczalnego języka lub adresu IP. Google odradza takie rozwiązanie, ponieważ utrudnia ono dostęp do pozostałych wersji zarówno ludziom, jak i wyszukiwarce. Robot Google łączy się zwykle ze Stanów Zjednoczonych i nie wysyła informacji o preferowanym języku, więc przy takim ustawieniu może nigdy nie zobaczyć wersji polskiej.

Przełącznik języka

Google zaleca, aby na każdej podstronie znajdowały się zwykłe linki do pozostałych wersji językowych. Dzięki nim odwiedzający sam wybiera język, a robot łatwiej odnajduje odpowiedniki. Najlepiej, gdy przełącznik prowadzi do odpowiednika bieżącej podstrony, a nie do strony głównej drugiej wersji.

Jak sprawdzić, czy znaczniki zostały wdrożone poprawnie?

Search Console nie udostępnia obecnie osobnego raportu poświęconego hreflang, a dokumentacja Google w części o rozwiązywaniu problemów odsyła do narzędzi innych firm. Kontrolę trzeba więc przeprowadzić samodzielnie. Przy dwóch wersjach językowych nie jest to pracochłonne.

1. Otwarcie polskiej podstrony w przeglądarce w oknie prywatnym i wyświetlenie jej kodu źródłowego skrótem Ctrl+U.
2. Wyszukanie w kodzie słowa hreflang skrótem Ctrl+F. Powinny pojawić się dokładnie trzy wiersze: dla wersji polskiej, dla drugiego języka i dla x-default.
3. Porównanie adresów w wierszach ze spisem par. Każdy znak ma znaczenie: protokół, przedrostek „www”, ukośnik końcowy.
4. Kliknięcie adresu drugiej wersji i potwierdzenie, że wczytuje się bez przekierowania.
5. Powtórzenie tych samych czynności na podstronie w drugim języku. Zestaw wierszy powinien być identyczny.
6. W Search Console należy wkleić adres w pole sprawdzania adresu URL u góry ekranu, kliknąć „Sprawdź URL wersji opublikowanej”, a następnie „Wyświetl przetestowaną stronę”. W pokazanym kodzie HTML wyszukuje się hreflang, aby potwierdzić, że robot Google widzi znaczniki.

Ostatni punkt jest ważny na stronach, na których część kodu powstaje dopiero w przeglądarce. Zdarza się, że znaczniki widać po wczytaniu strony przez człowieka, a w wersji pobranej przez robota ich nie ma albo znajdują się poza sekcją head.

Dokumentacja Google wymienia dwa zewnętrzne narzędzia pomocnicze: generator znaczników hreflang autorstwa Aleydy Solis oraz narzędzie Merkle do testowania znaczników na pojedynczej opublikowanej stronie. Google zastrzega, że ich nie obsługuje ani nie sprawdza.

Efekt w wynikach wyszukiwania pojawia się dopiero wtedy, gdy robot ponownie odwiedzi obie podstrony z pary. Trwa to od kilku dni do kilku tygodni i nie da się tego terminu z góry określić. Postęp widać w raporcie skuteczności w Search Console: po ustawieniu filtra kraju widać, które adresy wyświetlały się odbiorcom z danego państwa. Po udanym wdrożeniu w krajach anglojęzycznych powinny przeważać adresy wersji angielskiej.

Jakie błędy zdarzają się najczęściej i jak je naprawić?

Google wymienia w dokumentacji trzy typowe błędy: brak linków zwrotnych, nieprawidłowe kody języka i nieprawidłowe kody regionów. W praktyce dochodzi do nich kilka kolejnych, które wynikają ze sposobu działania systemów do prowadzenia stron.

Brak odwołania zwrotnego

Polska podstrona wskazuje angielską, ale angielska nie wskazuje polskiej. Google podaje, że w takiej sytuacji adnotacje mogą zostać zignorowane lub błędnie zinterpretowane. Najczęstsza przyczyna to tłumaczenie niepowiązane w panelu albo znaczniki dodane ręcznie tylko w jednej wersji. Naprawa polega na uzupełnieniu identycznego zestawu po drugiej stronie pary.

Błędny kod języka lub regionu

Zapis „en-UK”, sam kod kraju lub skrót wymyślony na podstawie końcówki domeny nie zostanie rozpoznany. Należy zastąpić go kodem języka z listy ISO 639-1, a kod regionu dodawać tylko wtedy, gdy jest rzeczywiście potrzebny. W razie wątpliwości bezpieczniej zostawić sam język.

Adres skrócony, przekierowany lub niekanoniczny

Znacznik zawiera adres bez protokołu, adres ze starej struktury serwisu albo wersję z „http”, która przekierowuje na „https”. Poprawia się to przez wpisanie pełnego, docelowego adresu. Po przebudowie serwisu lub zmianie adresów trzeba przejrzeć wszystkie pary na nowo. Zasady bezpiecznej zmiany adresów opisuję we wpisie o tym, jak ustawić przekierowanie 301 w pliku .htaccess.

Wszystkie znaczniki prowadzą do strony głównej

Każda polska podstrona wskazuje jako odpowiednik stronę główną wersji angielskiej. Strona główna nie odwołuje się zwrotnie do kilkudziesięciu polskich podstron, więc powiązania są niekompletne, a odbiorca i tak nie trafia na treść, której szukał. Każda podstrona musi wskazywać własny odpowiednik, a podstrony bez tłumaczenia nie powinny mieć znaczników wcale.

Znaczniki poza sekcją head

Kod wklejony w treść lub przesunięty przez inny skrypt poza sekcję head nie jest brany pod uwagę. Google radzi w razie wątpliwości wkleić kod wyrenderowanej strony do narzędzia sprawdzającego poprawność HTML. Ostrzega też, aby w jednym znaczniku link nie łączyć hreflang z innymi atrybutami, na przykład media.

Dwa zestawy znaczników na jednej stronie

W kodzie źródłowym słowo hreflang występuje sześć razy zamiast trzech. Oznacza to, że znaczniki dodają dwa różne mechanizmy. Należy ustalić, które to mechanizmy, i w jednym z nich tę funkcję wyłączyć. To samo dotyczy sytuacji, w której znaczniki są jednocześnie w kodzie strony i w mapie witryny, a ich treść się różni.

Co zrobić, gdy Google nadal pokazuje niewłaściwą wersję językową?

Zanim zacznie się szukać błędu, trzeba dać wyszukiwarce czas na ponowne odwiedzenie obu wersji. Proces można przyspieszyć: po sprawdzeniu adresu w Search Console należy kliknąć „Poproś o zindeksowanie”, osobno dla podstrony polskiej i osobno dla jej odpowiednika.

Jeżeli po kilku tygodniach nic się nie zmienia, warto przejść przez cztery pytania kontrolne. Pierwsze: czy druga wersja jest w ogóle w indeksie. Podstrona, której Google nie zaindeksował, nie pojawi się w wynikach niezależnie od znaczników. Sposób kontroli opisałem we wpisie o tym, jak sprawdzić, czy Google zaindeksował stronę.

Drugie pytanie: jaki adres Google uznał za kanoniczny. W wynikach sprawdzania adresu, w części „Indeksowanie stron”, znajduje się pole „Adres kanoniczny wybrany przez Google”. Jeżeli przy angielskiej podstronie widnieje tam adres polski, wyszukiwarka potraktowała obie wersje jako tę samą treść. Zwykle oznacza to, że tłumaczenie jest niepełne i trzeba je dokończyć.

Trzecie pytanie: czy treść każdej wersji jest jednoznacznie w jednym języku. Google radzi, aby na jednej stronie nie mieszać języków w treści i nawigacji. Czwarte: czy na obu podstronach nadal znajduje się ten sam, kompletny zestaw znaczników. Aktualizacja wtyczki lub motywu potrafi go usunąć bez żadnego komunikatu.

Trzeba też uczciwie powiedzieć, że hreflang nie daje gwarancji. Wynik zależy między innymi od ustawień przeglądarki osoby szukającej oraz od tego, w jakim języku wpisała zapytanie. Polska nazwa firmy wpisana za granicą może nadal prowadzić do wersji polskiej i nie jest to błąd wdrożenia.

Najczęstsze pytania

Czy trzeba dodawać kod regionu, na przykład pl-PL?

Nie trzeba. Według dokumentacji Google kod regionu jest częścią nieobowiązkową. Sam kod języka obejmuje wszystkich odbiorców posługujących się tym językiem bez względu na kraj, dlatego przy dwóch wersjach językowych jest zwykle najlepszym wyborem.

Czy x-default jest obowiązkowy?

Nie jest obowiązkowy, ale Google go zaleca. Dzięki niemu wyszukiwarka wie, którą wersję pokazać osobie, której język nie pasuje do żadnej z przygotowanych wersji. Bez tej wartości wybór należy do wyszukiwarki.

Czy wersje językowe mogą działać w dwóch różnych domenach?

Tak. Google wprost podaje, że alternatywne adresy nie muszą należeć do tej samej domeny. Warunek pozostaje ten sam: obie strony muszą wskazywać na siebie nawzajem, a adresy muszą być pełne.

Czy atrybut lang w kodzie strony zastępuje hreflang?

Nie. Atrybut lang opisuje język pojedynczego dokumentu i przydaje się między innymi czytnikom ekranu oraz przeglądarkom. Google podaje, że nie używa go do rozpoznawania języka strony. Nie przekazuje on też informacji o tym, gdzie znajduje się odpowiednik w innym języku.

Co zrobić, gdy część podstron nie ma tłumaczenia?

Podstrony bez odpowiednika zostawia się bez znaczników. Nie należy kierować ich do strony głównej drugiej wersji ani do przypadkowej podstrony o zbliżonym temacie. Gdy tłumaczenie powstanie, dodaje się zestaw znaczników po obu stronach nowej pary.

Czy po zmianie adresu podstrony trzeba poprawić znaczniki?

Tak, i to w obu wersjach. Stary adres w znaczniku prowadzi wtedy do przekierowania albo do błędu, przez co para przestaje być kompletna. Wtyczki do wielojęzyczności zwykle aktualizują adresy samodzielnie, natomiast zapisy ręczne i mapę witryny trzeba poprawić samemu.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Znaczniki hreflang wymagają przede wszystkim dokładności: jeden pominięty ukośnik lub niepowiązane tłumaczenie wystarczą, żeby cała para przestała działać. Jeżeli strona ma kilkadziesiąt podstron w dwóch językach, samo zestawienie i porównanie adresów potrafi zająć cały dzień. Chętnie wykonam tę pracę od początku do końca: przejrzę obie wersje językowe, zestawię pary, dobiorę kody, wdrożę znaczniki wybraną metodą, uporządkuję tagi kanoniczne i przełącznik języka, a potem sprawdzę wynik na każdej podstronie i w Search Console.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz języki, w których jest prowadzona. Odpowiem, co wymaga poprawy i jak będzie wyglądała praca.