Jak wdrożyć tagi hreflang dla wielojęzycznego WordPressa
Przetłumaczyłeś całą swoją stronę WordPress na sześć języków. Pliki .po są czyste, pliki .mo skompilowane, każdy ciąg znaków wyświetla się perfekcyjnie po francusku, niemiecku i japońsku. Jednak tygodnie po uruchomieniu, sprawdzasz Google Search Console i odkrywasz coś zdumiewającego: Twoja francuska strona rankuje dla niemieckich zapytań, Twoja hiszpańsko-meksykańska strona jest wyświetlana użytkownikom w Hiszpanii, a dwie z Twoich wersji językowych po cichu kanibalizują się nawzajem w rankingach. Treść jest w porządku. Problem polega na tym, że Google nie wie, która wersja należy do której grupy odbiorców.
To właśnie tagi hreflang WordPress mają za zadanie naprawić. Hreflang to sygnał, który informuje wyszukiwarki, którą wersję językową i regionalną strony wyświetlić któremu użytkownikowi. Jeśli popełnisz błąd, cierpisz na rozmycie duplikacji treści, błędne wyniki językowe i marnotrawstwo budżetu indeksowania. Jeśli zrobisz to dobrze, każda przetłumaczona strona dotrze do odbiorców, dla których została napisana. Ten przewodnik omawia składnię, różnicę między kodami językowymi a językowo-regionalnymi, obowiązkowy x-default, wzajemność tagów zwrotnych oraz trzy praktyczne sposoby implementacji w WordPressie.
Do czego właściwie służy hreflang
Hreflang niczego nie tłumaczy. To mapa relacji. Kiedy masz tę samą stronę w wielu językach, adnotacje hreflang mówią Google: „ten URL to wersja angielska, ten to wersja niemiecka, a ten jest dla osób mówiących po hiszpańsku w Meksyku”. Google używa tej mapy do wyświetlania prawidłowej wersji w wynikach wyszukiwania na podstawie ustawień językowych i lokalizacji użytkownika.
Adnotacja znajduje się w sekcji <head> Twojego kodu HTML jako zestaw elementów <link>. Każdy element określa docelową stronę oraz język (i opcjonalnie region), który obsługuje. Oto poprawny zestaw tagów hreflang dla strony dostępnej w angielskim (USA), angielskim (Wielka Brytania) i hiszpańskim (Meksyk), z domyślnym fallbackiem:
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/pricing/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/pricing/" />
<link rel="alternate" hreflang="es-MX" href="https://example.com/es-mx/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing/" />
Każda strona w zestawie powinna wyświetlać ten sam blok, wymieniając każdą alternatywną wersję, włącznie z samą sobą. Ten ostatni punkt jest mylący dla większości ludzi i wrócimy do niego.
Dlaczego to jest ważne dla SEO
Bez hreflang Google traktuje Twoje przetłumaczone strony jako niemal duplikaty konkurujące o te same słowa kluczowe. Wynikiem jest rozmycie: sygnały rankingowe są rozdzielone między wersje zamiast się konsolidować. Dzięki prawidłowemu hreflang każda wersja dziedziczy autorytet całego zestawu i trafia do właściwych wyszukiwarek. Jest to jeden z najbardziej wpływowych ruchów SEO, jakie może wykonać wielojęzyczna strona, i uzupełnia, a nie zastępuje, rzeczywiste tłumaczenie treści w plikach .po. Stronę treści szczegółowo omawiamy w naszym przewodniku jak tłumaczenie plików PO wpływa na rankingi Google.
Kody językowe a kody językowo-regionalne
Którego powinieneś użyć: en czy en-GB? Użyj najprostszego kodu, który jest prawdziwy. Jeśli Twoje treści angielskie są ogólne i nie utrzymujesz oddzielnych wersji brytyjskiej i amerykańskiej, użyj samego en. Dodaj subtag regionu tylko wtedy, gdy faktycznie dostarczasz różne treści do różnych krajów.
Wartości hreflang przyjmują format language lub language-region. Część językowa to kod ISO 639-1 (en, es, de, pt). Opcjonalny region to dwuliterowy kod kraju ISO 3166-1 Alpha 2 (US, GB, MX, BR). Zatem:
endociera do wszystkich osób mówiących po angielsku, niezależnie od kraju.en-GBdociera do osób mówiących po angielsku w Wielkiej Brytanii.esdociera do wszystkich osób mówiących po hiszpańsku.es-MXdociera konkretnie do osób mówiących po hiszpańsku w Meksyku.
Kluczowy szczegół: subtag regionu to kraj, a nie wariant językowy. es-MX nie oznacza „dialektu hiszpańskiego meksykańskiego”, oznacza „hiszpański, wyświetlany użytkownikom w Meksyku”. Google nadal wyświetla go na podstawie lokalizacji użytkownika. Jeśli utrzymujesz dialekty regionalne w swoich tłumaczeniach, kod regionu jest sposobem, w jaki je kierujesz. Zagłębiamy się w lingwistyczną stronę tego zagadnienia w naszym przewodniku po regionalnych wariantach hiszpańskiego i portugalskiego.
Typowy błędny przykład
Oto błędny blok hreflang, który stale widzimy:
<link rel="alternate" hreflang="en-uk" href="https://example.com/uk/" />
<link rel="alternate" hreflang="sp" href="https://example.com/es/" />
<link rel="alternate" hreflang="pt-PT_BR" href="https://example.com/pt/" />
Trzy błędy. en-uk jest nieprawidłowe, ponieważ kod kraju dla Wielkiej Brytanii to GB, a nie UK. sp w ogóle nie jest kodem językowym; hiszpański to es. A pt-PT_BR łączy dwa regiony z podkreśleniem, które nie ma znaczenia w hreflang. Wyszukiwarki cicho ignorują źle sformułowane wartości, więc nie otrzymujesz błędu ani korzyści, tylko godziny debugowania, zastanawiając się, dlaczego nic się nie zmieniło.
Zauważ, że hreflang używa myślnika (en-GB), podczas gdy pliki lokalizacyjne WordPressa używają podkreślenia (en_GB). Nie kopiuj kodów nazw plików .po bezpośrednio do tagów hreflang.
x-default i wzajemność tagów zwrotnych
Dwie zasady powodują więcej cichych błędów hreflang niż cokolwiek innego: brakujący x-default i zerwana wzajemność.
Wartość x-default informuje Google, którą stronę wyświetlić, gdy żaden inny język nie pasuje do użytkownika. Jest to Twój fallback, zazwyczaj selektor języka lub strona główna dla rynku docelowego. Nie jest ściśle obowiązkowy według specyfikacji, ale w praktyce zawsze powinieneś go uwzględnić. Bez niego, odwiedzający mówiący po portugalsku, dla którego nie masz portugalskiej wersji, otrzymuje losową stronę zamiast celowego domyślnego wyboru.
Wzajemność tagów zwrotnych jest bezwzględnie konieczna. Każda strona w zestawie hreflang musi wskazywać na każdą inną stronę, włączając w to samą siebie. Jeśli Twoja angielska strona wymienia niemiecką jako alternatywną, Twoja niemiecka strona musi wymieniać angielską jako alternatywną. Jeśli niemiecka strona pominie odniesienie zwrotne, Google nie ufa całej relacji i ignoruje adnotacje.
<!-- On the German page, the set must still list ALL versions -->
<link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
Samoodwołanie (de wskazujące na stronę niemiecką podczas przeglądania strony niemieckiej) jest wymagane, nie opcjonalne. Zestaw pięciu wersji językowych oznacza, że każda z pięciu stron wyprowadza wszystkie pięć tagów <link> plus x-default.
Trzy sposoby implementacji hreflang w WordPressie
Masz trzy praktyczne opcje, od pełnej kontroli manualnej po całkowicie zautomatyzowane.
Metoda 1: Ręczne za pomocą wp_head
Dla małego, statycznego zestawu stron możesz wstrzyknąć tagi hreflang bezpośrednio poprzez akcję wp_head w pliku functions.php Twojego motywu:
add_action( 'wp_head', function () {
if ( ! is_page( 'pricing' ) ) {
return;
}
$alternates = array(
'en-US' => 'https://example.com/en-us/pricing/',
'es-MX' => 'https://example.com/es-mx/pricing/',
'x-default' => 'https://example.com/pricing/',
);
foreach ( $alternates as $lang => $url ) {
printf(
'<link rel="alternate" hreflang="%s" href="%s" />' . "\n",
esc_attr( $lang ),
esc_url( $url )
);
}
} );
Dzięki temu kod HTML Twojej strony jest oszczędny, a mapa językowa scentralizowana w jednym pliku, który Google z łatwością indeksuje. Większość wtyczek SEO może to wygenerować automatycznie.
Metoda 2: Wtyczka wielojęzyczna
Jeśli używasz Polylang, WPML lub TranslatePress, hreflang jest generowany automatycznie na podstawie Twoich relacji tłumaczeniowych. Jest to właściwa odpowiedź dla większości stron, ponieważ wtyczka już wie, który post jest tłumaczeniem którego, więc wzajemność i x-default są obsługiwane automatycznie. Kosztem jest narzut na środowisko wykonawcze, który te wtyczki dodają, co jest kompromisem, który badamy w naszym porównaniu manualnych i AI podejść do tłumaczenia.
Metoda 3: Mapa witryny XML z xhtml:link
Zamiast umieszczać hreflang w sekcji <head> każdej strony, możesz zadeklarować relacje w swojej mapie witryny XML, używając przestrzeni nazw xhtml:link. Każdy wpis <url> wymienia wszystkie swoje alternatywne języki:
<url>
<loc>https://example.com/en/about/</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
</url>
Dzięki temu kod HTML Twojej strony jest oszczędny, a mapa językowa scentralizowana w jednym pliku, który Google z łatwością indeksuje. Większość wtyczek SEO może to wygenerować automatycznie.
hreflang uzupełnia tłumaczenie, nie zastępuje go
Oto punkt, który wszyscy pomijają: hreflang jest bezwartościowy, jeśli podstawowe strony nie są faktycznie przetłumaczone. Tag mówi Google „to jest niemiecka wersja”, ale jeśli niemiecki URL nadal wyświetla angielskie ciągi wtyczek, nieprzetłumaczone etykiety koszyka lub niedokończone pliki .po, po prostu powiedziałeś Google, aby z pełnym zaufaniem wyświetlał uszkodzone treści niemieckim użytkownikom.
Prawdziwe wielojęzyczne SEO składa się z dwóch warstw. Warstwa treści to przetłumaczone pliki .po, .pot, .json i .xliff, które przekładają każdy ciąg znaków motywu i wtyczki na język docelowy. Warstwa sygnałowa to hreflang, kierujący każdą gotową wersję do jej odbiorców. Obie muszą być solidne. Nieskazitelny zestaw hreflang na stronie przetłumaczonej w 40 procentach gwarantuje po prostu gorsze wrażenia w szybszym tempie.
Tutaj utrzymanie warstwy tłumaczeń w czystości ma największe znaczenie. Kiedy tłumaczysz pliki interfejsu, symbole zastępcze takie jak %s, %1$s i {name} muszą pozostać nienaruszone, w przeciwnym razie Twoja „przetłumaczona” niemiecka strona wyświetli się z dosłownymi tokenami %s, które wyglądają na uszkodzone zarówno dla użytkowników, jak i wyszukiwarek. Potok tłumaczeniowy obsługujący gettext z funkcją Syntax Locking automatycznie chroni te tokeny, dzięki czemu każda alternatywna strona, na którą wskazuje hreflang, jest faktycznie gotowa do produkcji. Ponieważ działa w chmurze z funkcją Smart Batching, możesz przetłumaczyć całą wielojęzyczną witrynę, nie instalując wtyczek tłumaczeniowych, które zwiększają obciążenie środowiska wykonawczego obsługującego te same strony.
Najpierw zadbaj o treść, a potem pozwól hreflang wykonać swoją pracę. Te dwa elementy razem konsolidują sygnały rankingowe, eliminują wyniki w niewłaściwym języku i umieszczają każdą przetłumaczoną stronę przed ludźmi, którzy potrafią ją przeczytać.
Gotowy, aby naprawić wyniki wyszukiwania w niewłaściwym języku u źródła? Wypróbuj SimplePoTranslate za darmo — karta kredytowa nie jest wymagana. Tłumacz swoje pliki
.po,.poti.jsonna darmowym planie, a następnie skieruj swoje tagi hreflang na strony, które są faktycznie gotowe na każdy rynek.