Witryna ma dwie albo więcej wersji językowych, znaczniki hreflang zostały wdrożone, a mimo to narzędzie do audytu pokazuje ostrzeżenie o braku tagów zwrotnych. Bywa też inaczej: żadnego ostrzeżenia nie widać, ale w niemieckim Google wyświetla się polska podstrona, a klient z Wielkiej Brytanii trafia na ofertę w złotych. W obu przypadkach przyczyna jest zwykle ta sama: strony językowe nie potwierdzają się nawzajem.
Ta instrukcja jest przeznaczona dla właścicieli firm i osób opiekujących się stroną, które nie zajmują się programowaniem na co dzień. Po lekturze będzie wiadomo, co dokładnie oznacza ten błąd, jak znaleźć jego przyczynę na konkretnej parze adresów, jak poprawić znaczniki w kodzie strony, w mapie witryny i w WordPressie oraz jak upewnić się, że poprawka została przez Google odczytana.
Jedna uwaga na początek. Google w swojej aktualnej dokumentacji nazywa ten problem „Brak linków zwrotnych”. Określenie „brak tagów zwrotnych” pochodzi z dawnego raportu w Search Console i nadal funkcjonuje w wielu narzędziach oraz w rozmowach z wykonawcami. Obie nazwy opisują dokładnie to samo.
Co oznacza brak linków zwrotnych w hreflang?
Znacznik hreflang to informacja dla wyszukiwarki: „ta strona ma odpowiednik w innym języku lub dla innego kraju i znajduje się on pod tym adresem”. Google nie przyjmuje jednak takiej deklaracji na słowo. Wymaga, aby druga strona powiedziała to samo o pierwszej.
Zasada z dokumentacji Google brzmi w skrócie tak: jeśli strona X zawiera link hreflang do strony Y, strona Y musi zawierać link zwrotny do strony X. Gdy polska podstrona wskazuje angielską, a angielska nie wskazuje polskiej, powiązanie jest jednostronne. To właśnie jest brak linku zwrotnego.
Wymóg ma swoje uzasadnienie. Gdyby wystarczała deklaracja jednej strony, każdy mógłby w obcym serwisie umieścić znacznik, który przedstawia jego stronę jako wersję językową cudzej witryny. Wzajemne potwierdzenie to zabezpieczenie przed takim nadużyciem.
Dokumentacja podaje jeszcze drugą zasadę, o której często się zapomina: każda wersja językowa musi wskazywać samą siebie oraz wszystkie pozostałe wersje. Zestaw znaczników jest więc identyczny na każdej stronie z danej grupy. Jeśli polska i angielska podstrona mają różne zestawy, błąd jest niemal pewny.
Jakie są skutki tego błędu dla widoczności firmy?
Google informuje, że przy braku wzajemnego wskazania znaczniki mogą zostać zignorowane lub nieprawidłowo zinterpretowane. Strona nie znika z wyników i nie jest to kara. Wyszukiwarka po prostu przestaje korzystać z podpowiedzi i sama decyduje, którą wersję pokazać użytkownikowi.
W praktyce objawy są następujące:
- w wynikach wyszukiwania w innym kraju pojawia się wersja w niewłaściwym języku,
- użytkownik widzi ofertę z inną walutą, innym cennikiem lub innymi warunkami dostawy, niż powinien,
- wersje dla krajów z tym samym językiem, na przykład Niemiec i Austrii, wypierają się nawzajem z wyników,
- goście z zagranicy szybko opuszczają stronę, bo nie rozumieją treści.
Uważam ten błąd za jeden z najbardziej niedocenianych przy stronach wielojęzycznych. Nie widać go gołym okiem, strona działa poprawnie, a firma traci zapytania z rynków, na które przygotowała tłumaczenia.
Gdzie dziś widać ten błąd, skoro raport z Search Console został wycofany?
Przez lata komunikat o braku tagów zwrotnych pojawiał się w raporcie „Kierowanie międzynarodowe” w Google Search Console. Ten raport został wycofany i w panelu już go nie ma. Google potwierdza przy tym, że nadal obsługuje znaczniki hreflang i z nich korzysta. Zniknął więc tylko raport, a zasady pozostały bez zmian.
Skutek jest taki, że Search Console nie ostrzega dziś o błędach hreflang. Brak ostrzeżenia w panelu nie oznacza, że wszystko jest w porządku. Informacja o problemie pochodzi obecnie z trzech źródeł.
Narzędzia do audytu stron
Programy, które przeglądają całą witrynę tak jak robot wyszukiwarki, porównują znaczniki na wszystkich podstronach i wskazują pary bez potwierdzenia. Nazwa ostrzeżenia zależy od narzędzia. W programie Screaming Frog SEO Spider jest to filtr „Missing Return Links” w zakładce „Hreflang”, w innych narzędziach spotyka się opisy w rodzaju „no return tag” albo „brak tagów zwrotnych”.
Testery pojedynczej strony
Dokumentacja Google wymienia narzędzie firmy Merkle do testowania znaczników hreflang na pojedynczej opublikowanej stronie. Google zastrzega, że nie obsługuje ani nie sprawdza narzędzi innych firm, dlatego wynik takiego testu należy traktować jako wskazówkę, a nie rozstrzygnięcie.
Objawy w wynikach wyszukiwania
Trzecie źródło to dane o ruchu. W Search Console należy otworzyć raport „Skuteczność”, ustawić filtr kraju i przejść do zakładki ze stronami. Jeśli dla Niemiec na liście dominują adresy polskiej wersji, mimo że istnieje niemiecka, znaczniki najpewniej nie działają.
Jak samodzielnie sprawdzić jedną parę stron?
Do pierwszego rozpoznania nie są potrzebne płatne programy. Wystarczy przeglądarka i dwa adresy: podstrona w jednym języku oraz jej odpowiednik w drugim. Najlepiej zacząć od strony głównej i jednej ważnej podstrony ofertowej.
- Otwarcie pierwszej strony, na przykład polskiej, w przeglądarce na komputerze.
- Wyświetlenie kodu źródłowego. W większości przeglądarek służy do tego skrót klawiszowy Ctrl+U, a na komputerach Mac skrót Cmd+Option+U.
- Uruchomienie wyszukiwania na stronie skrótem Ctrl+F i wpisanie słowa hreflang.
- Przepisanie do notatnika wszystkich znalezionych wierszy: jaki kod języka i jaki adres znajduje się w każdym z nich.
- Skopiowanie adresu wskazanego dla drugiego języka i otwarcie go w nowej karcie. Należy zwrócić uwagę, czy adres w pasku przeglądarki po załadowaniu jest identyczny ze skopiowanym.
- Powtórzenie czynności z punktów 2-4 na drugiej stronie.
- Porównanie obu zapisów. Na obu stronach powinny znajdować się te same wiersze, z tymi samymi adresami, znak po znaku.
Wynik porównania od razu podpowiada przyczynę. Jeśli na drugiej stronie słowo hreflang w ogóle nie występuje, brakuje całego zestawu. Jeśli występuje, ale adres pierwszej strony różni się choćby ukośnikiem na końcu, przyczyną jest niezgodność adresów. Jeśli po otwarciu adresu przeglądarka przeniosła się w inne miejsce, znacznik wskazuje adres z przekierowaniem.
Gdy w kodzie źródłowym nie ma znaczników na żadnej ze stron, nie musi to oznaczać ich braku. Mogą być podane w mapie witryny albo w nagłówkach HTTP. Google traktuje te trzy metody jako równoważne, dlatego przed wyciągnięciem wniosków trzeba zajrzeć także do pliku mapy.
Jakie przyczyny wywołują ten błąd i jak rozpoznać każdą z nich?
W mojej praktyce brak linków zwrotnych rzadko wynika z jednej pomyłki. Najczęściej nakłada się kilka drobiazgów, dlatego radzę przejść przez całą poniższą listę, a nie poprzestawać na pierwszym znalezionym błędzie.
Druga wersja nie ma znaczników albo ma niepełny zestaw
To przypadek najprostszy. Znaczniki zostały wpisane w szablonie jednej wersji językowej, a druga korzysta z innego szablonu albo została dodana później. Zdarza się również, że po dołożeniu trzeciego języka stare podstrony nadal wymieniają tylko dwa. Rozpoznanie: porównanie zestawów opisane wyżej pokazuje różną liczbę wierszy.
Adres w znaczniku różni się od adresu strony
Dla wyszukiwarki adresy z „http” i „https”, z „www” i bez „www”, z ukośnikiem na końcu i bez niego to różne adresy. Jeśli polska strona działa pod adresem z ukośnikiem, a angielska wskazuje ją bez ukośnika, link zwrotny prowadzi w inne miejsce niż trzeba. Rozpoznanie: adresy należy porównywać znak po znaku, najlepiej wklejone jeden pod drugim w notatniku.
Wskazany adres przekierowuje albo zwraca błąd
Po zmianie adresów podstron znaczniki często zostają ze starymi adresami. Stary adres przekierowuje wtedy pod nowy albo zwraca błąd 404, a strona docelowa potwierdza już zupełnie inny adres. Rozpoznanie: po wklejeniu adresu ze znacznika do przeglądarki adres w pasku zmienia się albo pojawia się strona błędu. Zasady poprawnego ustawiania przekierowań opisałem we wpisie o przekierowaniu 301 w pliku .htaccess.
Google nie może odczytać drugiej strony
Wyszukiwarka zobaczy link zwrotny tylko wtedy, gdy może pobrać stronę, na której się on znajduje. Blokada w pliku robots.txt, znacznik noindex albo strona dostępna dopiero po zalogowaniu sprawiają, że potwierdzenie pozostaje niewidoczne. Rozpoznanie: w Search Console należy wkleić adres drugiej strony w górnym polu wyszukiwania, czyli w narzędziu do sprawdzania adresów URL, i odczytać, czy strona jest zindeksowana oraz czy indeksowanie jest dozwolone.
Znaczniki hreflang kłócą się z tagiem kanonicznym
Tag kanoniczny mówi wyszukiwarce, który adres jest wersją właściwą. Jeśli angielska podstrona ma tag kanoniczny wskazujący polską, wyszukiwarka dostaje dwie sprzeczne informacje: „to osobna wersja językowa” i „to kopia polskiej strony”. Znaczniki hreflang powinny prowadzić wyłącznie do adresów, które same siebie wskazują jako kanoniczne. Jak to sprawdzić w całym serwisie, wyjaśniam we wpisie o tagu kanonicznym wskazującym błędny adres.
Znaczniki znalazły się poza sekcją head
Google wymaga, aby znaczniki w kodzie HTML znajdowały się w poprawnie zbudowanej sekcji <head>. Skrypt lub element wstawiony zbyt wcześnie przez wtyczkę potrafi tę sekcję przerwać, a wszystko, co znajduje się niżej, jest wtedy traktowane jak treść strony i pomijane. Rozpoznanie: w kodzie źródłowym wiersze z hreflang znajdują się poniżej elementów, które do nagłówka nie należą, na przykład poniżej znacznika <div> lub <iframe>.
Nieprawidłowy kod języka lub regionu
Wiersz z błędnym kodem jest pomijany, więc dla wyszukiwarki link zwrotny nie istnieje. Google obsługuje kody języków w formacie ISO 639-1 oraz opcjonalne kody regionów w formacie ISO 3166-1 alfa-2. Nie można podać samego kodu kraju. Typowa pomyłka to „en-UK” zamiast „en-GB”: według dokumentacji kody „UK”, „EU” i „UN” nie mają wpływu na wyszukiwarkę.
Dwa źródła znaczników podają różne dane
Zdarza się, że jeden zestaw znaczników dodaje wtyczka w kodzie strony, a drugi znajduje się w mapie witryny wygenerowanej przez inne narzędzie. Jeśli oba zestawy się różnią, część par nie ma potwierdzenia. Google podkreśla, że stosowanie kilku metod jednocześnie nie daje żadnych korzyści, a utrudnia utrzymanie porządku.
Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a ja przejmę sprawę: sprawdzę wszystkie wersje językowe serwisu, wskażę pary stron bez potwierdzenia i przygotuję poprawione znaczniki gotowe do wdrożenia.
Jak poprawić znaczniki w kodzie strony?
Przed zmianami trzeba wykonać kopię zapasową witryny. Pomyłka w pliku szablonu potrafi zatrzymać działanie całej strony, a przywrócenie kopii zajmuje kilka minut. Bezpieczniejszą drogą niż ręczna edycja plików jest pole na własny kod w nagłówku, jeśli system zarządzania treścią takie udostępnia.
Poprawny zestaw dla podstrony w dwóch językach wygląda następująco. Adresy w przykładzie są umowne, w ich miejsce wpisuje się własne.
<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/oferta/" />Dokładnie te same trzy wiersze muszą znaleźć się na polskiej i na angielskiej podstronie. Wartość „x-default” wskazuje stronę dla użytkowników, których język nie pasuje do żadnej wersji. Google zaleca ją szczególnie przy stronach głównych z wyborem języka, a jej dodanie nie jest obowiązkowe.
- Przygotowanie listy par. W arkuszu kalkulacyjnym w jednej kolumnie wpisuje się adresy polskie, w drugiej ich odpowiedniki. Każdy adres należy skopiować z paska przeglądarki po pełnym załadowaniu strony, wtedy ma on ostateczną postać.
- Sprawdzenie, czy każdy adres z listy otwiera się bez przekierowania i nie jest wyłączony z indeksowania.
- Ułożenie zestawu znaczników dla każdej pary według wzoru powyżej. Adresy muszą być pełne, razem z „https://”. Dokumentacja wprost wyklucza zapisy skrócone, takie jak sama ścieżka „/oferta/”.
- Wstawienie identycznego zestawu na obu stronach z pary, w sekcji
<head>, możliwie wysoko, przed skryptami zewnętrznych usług. - Usunięcie starych wierszy hreflang, aby na stronie nie zostały dwa różne zestawy.
- Wyczyszczenie pamięci podręcznej strony i serwera, jeśli witryna z niej korzysta.
- Ponowne obejrzenie kodu źródłowego obu stron i porównanie zestawów.
Przy trzech i więcej językach zasada pozostaje ta sama, rośnie tylko liczba wierszy. Każda podstrona wymienia wszystkie wersje, łącznie z własną. Google dopuszcza pominięcie części powiązań, gdy utrzymanie pełnego zestawu staje się zbyt trudne, i przetwarza wtedy te pary, które wskazują na siebie wzajemnie. Radzę jednak traktować to jako wyjście awaryjne, a nie sposób pracy.
Osobnego potraktowania wymagają podstrony bez tłumaczenia. Jeśli wpis istnieje tylko po polsku, nie należy wskazywać dla niego angielskiej strony głównej jako odpowiednika. Taki znacznik nigdy nie dostanie poprawnego linku zwrotnego. Podstrona bez odpowiedników powinna pozostać bez znaczników hreflang. Pełny opis pierwszego wdrożenia zawiera wpis o znacznikach hreflang dla dwóch wersji językowych.
Jak poprawić znaczniki podane w mapie witryny?
Mapa witryny jest wygodna przy dużych serwisach, bo wszystkie powiązania znajdują się w jednym pliku. Te same zasady obowiązują tu w nieco innym zapisie: każdy adres ma własny element <url>, a w nim komplet wpisów <xhtml:link> dla wszystkich wersji, łącznie z opisywaną.
<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/"/>
</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/"/>
</url>Brak linku zwrotnego w mapie ma zwykle jedną z trzech postaci. Angielski adres nie ma własnego elementu <url>, choć jest wymieniony przy polskim. Angielski adres ma własny element, ale bez wpisów podrzędnych. Albo wpisy są, lecz różnią się od tych przy polskim adresie.
W elemencie <urlset> na początku pliku musi też znajdować się deklaracja przestrzeni nazw xmlns:xhtml, w brzmieniu podanym w dokumentacji Google. Bez niej wpisy z wersjami językowymi nie zostaną poprawnie odczytane. Według dokumentacji kolejność wpisów podrzędnych nie ma znaczenia, ale stała kolejność ułatwia wyłapywanie pomyłek, a same wpisy nie wliczają się do limitu adresów w mapie.
Po poprawieniu pliku należy go ponownie przesłać w Search Console w raporcie „Mapy witryn”. Sposób postępowania opisuję we wpisie o zgłaszaniu mapy witryny w Google Search Console. Jeśli znaczniki są jednocześnie w mapie i w kodzie stron, warto zostawić jedną metodę i drugą usunąć.
Jak usunąć ten błąd w WordPressie?
W WordPressie znaczniki hreflang zwykle wstawia wtyczka do wielojęzyczności, taka jak Polylang lub WPML. Robi to automatycznie, ale tylko dla treści, które zostały ze sobą powiązane jako tłumaczenia. Ręczne dopisywanie znaczników obok wtyczki prawie zawsze kończy się dwoma sprzecznymi zestawami.
Najczęstsze przyczyny w tym systemie to:
- angielski wpis powstał jako osobna strona i nie został przypisany do polskiego oryginału jako jego tłumaczenie,
- tłumaczenie ma status szkicu albo jest zaplanowane na później, więc pod wskazanym adresem nic jeszcze nie ma,
- po zmianie adresu podstrony wtyczka do pamięci podręcznej nadal podaje starą wersję kodu,
- w motywie albo w polu na kod nagłówka pozostały znaczniki wpisane ręcznie przy poprzednim wdrożeniu,
- druga wtyczka, na przykład do pozycjonowania, dodaje własny zestaw znaczników lub własną mapę witryny z wersjami językowymi.
Naprawa zaczyna się od otwarcia edycji problematycznej podstrony i odszukania pola z językami, w którym wtyczka pokazuje przypisane tłumaczenia. Jeśli pole dla drugiego języka jest puste, trzeba wskazać w nim właściwy wpis i zapisać zmiany. Następnie należy opublikować tłumaczenie, wyczyścić pamięć podręczną i obejrzeć kod źródłowy obu stron.
Jeśli w kodzie widać dwa zestawy znaczników, trzeba ustalić, skąd pochodzi każdy z nich. Najprostsza metoda to chwilowe wyłączenie jednej wtyczki na kopii testowej strony i sprawdzenie, który zestaw zniknął. Na działającej stronie firmowej takich prób lepiej nie przeprowadzać w godzinach największego ruchu.
Po czym poznać, że naprawa zadziałała?
Sprawdzenie ma dwa etapy. Pierwszy odbywa się od razu i dotyczy tego, co strona faktycznie wysyła. Drugi wymaga cierpliwości, bo zależy od tego, kiedy robot Google ponownie odwiedzi obie strony z pary.
- Ponowne porównanie kodu źródłowego obu stron. Zestawy muszą być identyczne.
- Otwarcie Search Console i wklejenie adresu pierwszej strony w polu narzędzia do sprawdzania adresów URL.
- Kliknięcie przycisku „Test wersji opublikowanej”, a po zakończeniu testu przycisku „Wyświetl przetestowaną stronę”.
- Odszukanie w wyświetlonym kodzie HTML wierszy ze słowem hreflang. Jeśli są obecne i poprawne, Google widzi je przy pobieraniu strony.
- Kliknięcie „Poproś o zindeksowanie” i powtórzenie całości dla drugiej strony z pary.
- Ponowne uruchomienie narzędzia do audytu po kilku dniach i sprawdzenie, czy ostrzeżenie zniknęło z listy.
Według pomocy Search Console zindeksowanie po przesłaniu prośby może potrwać tydzień lub dwa, a liczba próśb w ciągu dnia jest ograniczona. Przy większej liczbie poprawionych podstron lepiej więc przesłać zaktualizowaną mapę witryny, niż zgłaszać adresy pojedynczo.
Ostatecznym potwierdzeniem są dane z raportu „Skuteczność”. Po pewnym czasie przy filtrze konkretnego kraju na liście stron powinny przeważać adresy właściwej wersji językowej. Google nie podaje terminu, w którym to nastąpi, dlatego nie należy oczekiwać zmiany z dnia na dzień.
Co zrobić, gdy błąd nie znika?
Jeśli po kilku tygodniach narzędzie nadal pokazuje ostrzeżenie albo w wynikach wciąż pojawia się niewłaściwa wersja, trzeba wrócić do diagnozy. Najczęściej okazuje się, że poprawka objęła część podstron albo że narzędzie i przeglądarka widzą różne wersje kodu.
- Narzędzie do audytu mogło korzystać z wcześniejszego odczytu. Trzeba uruchomić nowe sprawdzenie całej witryny, a nie odświeżać stary wynik.
- Pamięć podręczna na serwerze lub w sieci dostarczania treści może podawać robotom starszą wersję strony niż ta, którą widzi zalogowany administrator. Kod warto obejrzeć w oknie prywatnym przeglądarki.
- Znaczniki dodawane przez JavaScript mogą nie być widoczne w kodzie źródłowym. W takim przypadku rozstrzyga kod pokazany po kliknięciu „Wyświetl przetestowaną stronę”. Bezpieczniej jest jednak, gdy znaczniki znajdują się w kodzie wysyłanym przez serwer.
- Strona może automatycznie przekierowywać gości na inną wersję językową na podstawie lokalizacji. Robot trafia wtedy pod inny adres niż wskazany w znaczniku i nie widzi potwierdzenia.
- Google mógł uznać dwie wersje za kopie tej samej strony. Dzieje się tak, gdy przetłumaczono tylko menu i stopkę, a główna treść pozostała w jednym języku.
Ostatni punkt wymaga komentarza. Według dokumentacji wersje zlokalizowane są uznawane za duplikaty tylko wtedy, gdy główna treść strony pozostaje nieprzetłumaczona. Jeśli więc angielska wersja zawiera polskie opisy, żadne znaczniki nie zastąpią rzetelnego tłumaczenia.
W narzędziu do sprawdzania adresów URL warto też odczytać pole „Adres kanoniczny wybrany przez Google” dla każdej wersji. Jeśli dla angielskiej podstrony Google wybrał adres polski, problem leży w podobieństwie treści lub w tagach kanonicznych, a nie w samych znacznikach hreflang.
Jakich błędów unikać przy poprawianiu hreflang?
Część poprawek wprowadza nowe problemy w miejsce starych. Z mojego doświadczenia najwięcej szkód powodują poniższe działania.
- Wskazywanie strony głównej drugiego języka jako odpowiednika dla każdej podstrony bez tłumaczenia.
- Ustawianie tagu kanonicznego wszystkich wersji językowych na jedną, „główną” wersję. To sygnał, że pozostałe wersje są kopiami.
- Stosowanie znaczników hreflang na stronach wyłączonych z indeksowania lub zablokowanych w pliku robots.txt.
- Łączenie znacznika hreflang z innymi atrybutami w jednym elemencie, na przykład z atrybutem „media”. Dokumentacja wprost tego zabrania.
- Poprawianie tylko tej strony, którą wskazało narzędzie. Błąd zawsze dotyczy pary, więc trzeba obejrzeć obie strony.
- Poleganie na samym znaczniku w sprawie rozpoznania języka. Google nie używa hreflang ani atrybutu „lang” do wykrywania języka strony, robi to na podstawie treści.
Nie polecam też masowej zamiany adresów w bazie danych bez kopii zapasowej i bez testu na kopii strony. Jedna literówka powielona na setkach podstron jest trudniejsza do odwrócenia niż pierwotny błąd.
Najczęstsze pytania
Czy brak linków zwrotnych obniża pozycję strony w Google?
Google nie opisuje tego błędu jako powodu do obniżenia pozycji. Skutkiem jest zignorowanie lub błędne odczytanie znaczników, przez co wyszukiwarka sama wybiera wersję językową do pokazania. Strata polega więc na tym, że użytkownik w innym kraju dostaje niewłaściwą wersję, a nie na karze dla witryny.
Czy strona musi wskazywać w hreflang samą siebie?
Tak. Dokumentacja Google mówi, że każda wersja językowa musi uwzględniać siebie oraz wszystkie inne wersje. Zestaw znaczników jest więc taki sam na każdej stronie z grupy, a pominięcie wiersza z własnym adresem jest jednym z częstszych źródeł ostrzeżeń w narzędziach.
Czy wersje językowe mogą znajdować się w różnych domenach?
Mogą. Alternatywne adresy nie muszą należeć do tej samej domeny, więc polska wersja może działać w domenie z końcówką .pl, a niemiecka w domenie z końcówką .de. Zasada wzajemnego wskazania obowiązuje tak samo, dlatego trzeba mieć możliwość edycji kodu w obu serwisach.
Czy wielkość liter w kodzie języka ma znaczenie?
Nie ma. Google akceptuje kody pisane małymi i wielkimi literami, a zapis regionu wielkimi literami, na przykład „en-GB”, jest jedynie zgodny z przyjętą konwencją. Znaczenie ma natomiast wielkość liter w samym adresie strony, bo serwer może traktować takie adresy jako różne.
Czy wartość x-default też wymaga linku zwrotnego?
Wiersz z wartością „x-default” jest częścią zestawu, a zestaw ma być identyczny na wszystkich wersjach. Jeśli więc pojawia się na polskiej stronie, powinien w tym samym brzmieniu znaleźć się na angielskiej. Strona wskazana jako domyślna również powinna zawierać cały zestaw.
Czy lepiej podać znaczniki w kodzie strony, czy w mapie witryny?
Dla Google obie metody są równoważne, podobnie jak trzecia, czyli nagłówki HTTP przydatne przy plikach PDF. Przy małej stronie wygodniejszy bywa kod strony, bo łatwo go obejrzeć w przeglądarce. Przy serwisie z wieloma językami i tysiącami podstron porządek łatwiej utrzymać w mapie witryny.
Czy ostrzeżenie w narzędziu zawsze oznacza rzeczywisty błąd?
Nie zawsze. Narzędzie mogło nie dotrzeć do drugiej strony, bo ograniczono liczbę przeglądanych adresów albo serwer chwilowo nie odpowiadał. Dlatego każde ostrzeżenie warto potwierdzić ręcznym porównaniem kodu obu stron, zanim zacznie się cokolwiek zmieniać.
Czy przy jednej wersji językowej znaczniki hreflang są potrzebne?
Nie są. Znaczniki służą do wskazywania odpowiedników, więc przy jednej wersji nie ma czego wskazywać. Pojedynczy wiersz hreflang na stronie bez tłumaczeń niczemu nie szkodzi, ale też niczego nie daje, a w narzędziach potrafi wywoływać zbędne ostrzeżenia.
Brak czasu albo ochoty, żeby zająć się tym samodzielnie?
Porządkowanie znaczników hreflang wymaga dokładności i cierpliwości, a nie każdy właściciel firmy chce spędzać wieczór na porównywaniu adresów znak po znaku. To zupełnie zrozumiałe. Mogę zająć się tym od początku do końca: przejrzę wszystkie wersje językowe, ustalę, które pary stron nie potwierdzają się nawzajem i dlaczego, poprawię znaczniki w kodzie, w mapie witryny lub w ustawieniach WordPressa, a potem sprawdzę, czy Google odczytuje je poprawnie.
Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz języki, w których działa. Odpowiem, co wymaga poprawy i w jakiej kolejności najlepiej to zrobić.
