Hogyan implementáljuk a hreflang címkéket többnyelvű WordPress webhelyen
Lefordította a teljes WordPress webhelyét hat nyelvre. A .po fájlok hibátlanok, a .mo fájlok le vannak fordítva, minden szövegrész tökéletesen jelenik meg franciául, németül és japánul. Mégis, hetekkel az indulás után ellenőrzi a Google Search Console-t, és valami zavarba ejtőt talál: a francia oldala német lekérdezésekre rangsorol, a spanyol-mexikói oldala spanyolországi keresőknek jelenik meg, és két nyelvi verziója csendesen kannibalizálja egymást a rangsorban. A tartalom rendben van. A probléma az, hogy a Google-nak fogalma sincs, melyik verzió melyik közönséghez tartozik.
Pontosan ezt hivatottak orvosolni a hreflang WordPress címkék. A hreflang az a jel, amely megmondja a keresőmotoroknak, hogy egy oldal melyik nyelvi és regionális verzióját melyik felhasználónak jelenítsék meg. Ha rosszul csinálja, akkor duplikált tartalom hígulástól, hibás nyelvű találatoktól és felesleges feltérképezési költségvetéstől szenved. Ha jól csinálja, minden lefordított oldal eléri azt a közönséget, amelynek készült. Ez az útmutató bemutatja a szintaxist, a nyelvi és nyelvi-regionális kódok közötti különbséget, a kötelező x-default értéket, a visszatérő címkék kölcsönösségét, és három gyakorlati módot a WordPress-ben való megvalósítására.
Mire való valójában a hreflang
A hreflang nem fordít semmit. Ez egy kapcsolati térkép. Ha ugyanaz az oldal több nyelven is elérhető, a hreflang annotációk azt mondják a Google-nak: "ez az URL az angol verzió, ez a német verzió, ez pedig a mexikói spanyol anyanyelvűeknek szól." A Google ezt a térképet használja, hogy a felhasználó nyelvi beállításai és tartózkodási helye alapján a megfelelő verziót jelenítse meg a keresési eredményekben.
Az annotáció a HTML <head> részében található, <link> elemek halmazaként. Minden elem megnevez egy céloldalt és a nyelvet (opcionálisan a régiót), amelyet szolgál. Íme egy helyes hreflang címkekészlet egy oldalhoz, amely elérhető amerikai angol, brit angol és mexikói spanyol nyelven, alapértelmezett tartalékkal:
<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/" />
A készlet minden oldalának ugyanazt a blokkot kell kiadnia, felsorolva minden alternatívát, beleértve önmagát is. Ez az utolsó pont téveszt meg a legtöbb embert, és még visszatérünk rá.
Miért fontos ez a SEO szempontjából
Hreflang nélkül a Google közel duplikált tartalomként kezeli a lefordított oldalakat, amelyek ugyanazokért a kulcsszavakért versenyeznek. Az eredmény hígulás: a rangsorolási jelek szétoszlanak a különböző verziók között ahelyett, hogy konszolidálódnának. Helyes hreflang használatával minden verzió örökli a készlet egészének tekintélyét, és a megfelelő keresők számára jelenik meg. Ez az egyik legnagyobb tőkeáttételű SEO lépés, amit egy többnyelvű webhely megtehet, és kiegészíti, nem pedig felváltja a .po fájlokban lévő tényleges tartalomfordítást. A tartalmi oldalról részletesen írunk a hogyan befolyásolja a PO fájlok fordítása a Google rangsorolását című útmutatónkban.
Nyelvi kontra nyelvi-regionális kódok
Melyiket érdemes használni, az en vagy az en-GB kódot? Használja a legegyszerűbb, igaz kódot. Ha az angol tartalma általános, és nem tart fenn külön brit és amerikai verziókat, akkor csak az en kódot használja. Csak akkor adjon hozzá régió al-címkét, ha valóban eltérő tartalmat kínál különböző országoknak.
A hreflang értékek a language vagy language-region formátumot követik. A nyelvi rész egy ISO 639-1 kód (en, es, de, pt). Az opcionális régió egy ISO 3166-1 Alpha 2 országkód (US, GB, MX, BR). Tehát:
- Az
enminden angol anyanyelvűt céloz, országtól függetlenül. - Az
en-GBaz Egyesült Királyságban élő angol anyanyelvűeket célozza. - Az
esminden spanyol anyanyelvűt céloz. - Az
es-MXkifejezetten a mexikói spanyol anyanyelvűeket célozza.
Kritikus részlet: a régió al-címke egy ország, nem egy nyelvi változat. Az es-MX nem azt jelenti, hogy „mexikói spanyol dialektus”, hanem azt, hogy „spanyol, a mexikói felhasználóknak mutatva”. A Google továbbra is a felhasználó tartózkodási helye alapján jeleníti meg. Ha regionális dialektusokat tart fenn a fordításaiban, a régiókód az, amellyel irányíthatja őket. Ennek nyelvi oldalát részletesebben tárgyaljuk a regionális spanyol és portugál változatokról szóló útmutatónkban.
Gyakori hibás példa
Íme egy hibás hreflang blokk, amelyet folyamatosan látunk:
<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/" />
Három hiba. Az en-uk érvénytelen, mert az Egyesült Királyság országkódja GB, nem UK. Az sp egyáltalán nem nyelvkód; a spanyol az es. A pt-PT_BR pedig két régiót kever egy aláhúzással, amelynek nincs jelentése a hreflangban. A keresőmotorok csendesen figyelmen kívül hagyják a rosszul formázott értékeket, így nem kap hibát és semmilyen előnyt, csak órákig tartó hibakeresést, azon tűnődve, miért nem változott semmi.
Ne feledje, hogy a hreflang kötőjelet (en-GB) használ, míg a WordPress területi fájlok aláhúzást (en_GB) használnak. Ne másolja be közvetlenül a .po fájlnevek kódjait a hreflang címkékbe.
Az x-default és a visszatérő címkék kölcsönössége
Két szabály okoz több csendes hreflang hibát, mint bármi más: a hiányzó x-default és a sérült kölcsönösség.
Az x-default érték megmondja a Google-nak, melyik oldalt jelenítse meg, ha egyetlen más nyelv sem egyezik a felhasználóval. Ez a tartalék, jellemzően a nyelvi választója vagy az elsődleges piaci honlapja. Specifikáció szerint nem feltétlenül kötelező, de a gyakorlatban mindig érdemes szerepeltetni. Enélkül egy portugálul beszélő látogató, akinek nincs portugál verziója, véletlenszerű eredményt kap a szándékos alapértelmezett helyett.
A visszatérő címkék kölcsönössége nem képezi alku tárgyát. Egy hreflang készlet minden oldalának vissza kell mutatnia minden más oldalra, beleértve önmagát is. Ha az angol oldala a németet alternatívaként sorolja fel, akkor a német oldalának is fel kell sorolnia az angolt alternatívaként. Ha a német oldal kihagyja a visszatérő hivatkozást, a Google bizalmatlanná válik az egész kapcsolattal szemben, és figyelmen kívül hagyja az annotációkat.
<!-- 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/" />
Az önreferencia (de mutat a német oldalra, miközben a német oldalt nézzük) kötelező, nem opcionális. Öt nyelvi változatból álló készlet esetén mind az öt oldal mind az öt <link> címkét és az x-default értéket is kiadja.
Három módja a hreflang megvalósításának WordPressben
Három gyakorlati lehetősége van, a teljes manuális vezérléstől a teljesen automatizáltig.
1. módszer: Manuális a wp_head segítségével
Kis statikus oldalkészlet esetén a hreflang címkéket közvetlenül beillesztheti a wp_head akción keresztül a témája functions.php fájljába:
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 )
);
}
} );
Ez pontos vezérlést biztosít, de nem skálázható. A kölcsönösség kézi fenntartása több száz bejegyzésen keresztül karbantartási csapda.
2. módszer: Többnyelvű bővítmény
Ha Polylang, WPML vagy TranslatePress bővítményeket használ, a hreflang automatikusan generálódik a fordítási kapcsolatok alapján. Ez a megfelelő válasz a legtöbb webhely számára, mivel a bővítmény már tudja, melyik bejegyzés melyiknek a fordítása, így a kölcsönösséget és az x-default értékét is kezeli Ön helyett. A költség az, hogy ezek a bővítmények futásidejű többletterhelést okoznak, ami az a kompromisszum, amelyet a manuális versus AI fordítási megközelítések összehasonlításában vizsgálunk.
3. módszer: XML Sitemap xhtml:link-kel
Ahelyett, hogy minden oldal <head> részébe tenné a hreflang címkét, az XML sitemapben is deklarálhatja a kapcsolatokat az xhtml:link névtér használatával. Minden <url> bejegyzés felsorolja az összes nyelvi alternatíváját:
<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>
Ez karcsún tartja az oldal HTML-jét, és egyetlen feltérképezhető fájlban központosítja a nyelvi térképet, amelyet a Google örömmel olvas. A legtöbb SEO bővítmény automatikusan képes ezt generálni.
A hreflang kiegészíti a fordítást, nem helyettesíti
Itt van az a pont, amit mindenki kihagy: a hreflang értéktelen, ha az alapul szolgáló oldalak valójában nincsenek lefordítva. A címke azt mondja a Google-nak, hogy „ez a német verzió”, de ha a német URL továbbra is angol bővítmény szövegeket, fordítatlan fizetési címkéket vagy félkész .po fájlokat mutat, akkor egyszerűen azt mondta a Google-nak, hogy teljes bizalommal szolgáltasson hibás tartalmat a német felhasználóknak.
A valódi többnyelvű SEO két rétegből áll. A tartalmi réteg a lefordított .po, .pot, .json és .xliff fájlok, amelyek minden téma és bővítmény szövegét a célnyelvre viszik át. A jelszint réteg a hreflang, amely minden kész verziót a közönségéhez irányít. Mindkettőnek stabilnak kell lennie. Egy makulátlan hreflang készlet egy 40 százalékban lefordított webhelyen csak gyorsabban garantálja a rosszabb élményt.
Ez az, ahol a fordítási réteg tisztán tartása a legfontosabb. Amikor lefordítja az interfész fájlokat, az olyan helyőrzőknek, mint %s, %1$s és {name} érintetlenül kell maradniuk, különben a „lefordított” német oldala szó szerinti %s tokenekkel jelenik meg, amelyek hibásnak tűnnek mind a felhasználók, mind a keresőmotorok számára. Egy gettext-kompatibilis fordítási folyamat a Syntax Locking funkcióval automatikusan védi ezeket a tokeneket, így minden alternatív oldal, amelyre a hreflang mutat, valóban gyártásra kész. Mivel a felhőben fut a Smart Batching segítségével, egy teljes többnyelvű webhelyet átengedhet rajta anélkül, hogy fordító bővítményeket kellene telepítenie, amelyek megnövelik azokat a futásidejű erőforrásokat, amelyek éppen ezeket az oldalakat szolgálják ki.
Először tegye rendbe a tartalmat, aztán hagyja, hogy a hreflang elvégezze a dolgát. A kettő együtt konszolidálja a rangsorolási jeleket, megszünteti a hibás nyelvű találatokat, és minden lefordított oldalt az elolvasni tudó emberek elé tárja.
Készen áll a hibás nyelvű keresési eredmények forrásnál történő kijavítására? Próbálja ki ingyen a SimplePoTranslate-et — nincs szükség hitelkártyára. Fordítsa le
.po,.potés.jsonfájljait az ingyenes szinten, majd irányítsa hreflang címkéit olyan oldalakra, amelyek valóban készen állnak minden piacra.