Cum să implementezi etichetele hreflang pentru un WordPress multilingv
Ai tradus întregul tău site WordPress în șase limbi. Fișierele .po sunt curate, fișierele .mo sunt compilate, fiecare șir se randează perfect în franceză, germană și japoneză. Cu toate acestea, la câteva săptămâni de la lansare, verifici Google Search Console și descoperi ceva uluitor: pagina ta în franceză este clasată pentru interogări în germană, pagina ta Spania-Mexic este servită căutătorilor din Spania, iar două dintre versiunile tale lingvistice se canibalizează reciproc în clasamente. Conținutul este în regulă. Problema este că Google nu are nicio idee ce versiune aparține cărui public.
Acesta este exact lucrul pe care etichetele hreflang WordPress sunt concepute să-l rezolve. Hreflang este semnalul care indică motoarelor de căutare ce versiune lingvistică și regională a unei pagini să servească fiecărui utilizator. Dacă greșești, vei suferi diluarea conținutului duplicat, rezultate în limba greșită și un buget de crawling irosit. Dacă o faci corect, fiecare pagină tradusă ajunge la publicul pentru care a fost scrisă. Acest ghid acoperă sintaxa, diferența dintre codurile de limbă și codurile limbă-regiune, x-default obligatoriu, reciprocitatea etichetelor de retur și trei modalități practice de implementare în WordPress.
Ce face de fapt hreflang
Hreflang nu traduce nimic. Este o hartă de relații. Când ai aceeași pagină în mai multe limbi, adnotările hreflang îi spun lui Google "acest URL este versiunea în engleză, acesta este versiunea în germană, acesta este pentru vorbitorii de spaniolă din Mexic." Google folosește acea hartă pentru a servi versiunea corectă în rezultatele căutării, pe baza setărilor de limbă și a locației utilizatorului.
Adnotarea se află în <head> al HTML-ului tău ca un set de elemente <link>. Fiecare element numește o pagină țintă și limba (și, opțional, regiunea) pe care o servește. Iată un set corect de etichete hreflang pentru o pagină disponibilă în engleză americană, engleză britanică și spaniolă mexicană, cu o variantă de rezervă implicită:
<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/" />
Fiecare pagină din set ar trebui să afișeze același bloc, listând fiecare alternativă, inclusiv pe ea însăși. Acest ultim punct îi încurcă pe majoritatea oamenilor și vom reveni asupra lui.
De ce contează acest lucru pentru SEO
Fără hreflang, Google tratează paginile tale traduse ca pe niște duplicări aproape identice care concurează pentru aceleași cuvinte cheie. Rezultatul este diluarea: semnalele de clasare sunt împărțite între versiuni în loc să se consolideze. Cu un hreflang corect, fiecare versiune moștenește autoritatea setului în ansamblu și apare în fața căutătorilor potriviți. Aceasta este una dintre cele mai puternice acțiuni SEO pe care un site multilingv le poate face și completează, mai degrabă decât înlocuiește, traducerea efectivă a conținutului din fișierele tale .po. Abordăm în detaliu partea de conținut în ghidul nostru despre cum traducerea fișierelor PO influențează clasamentele Google.
Coduri de limbă vs. coduri limbă-regiune
Ce ar trebui să folosești, en sau en-GB? Folosește cel mai simplu cod care este adevărat. Dacă conținutul tău în engleză este generic și nu menții versiuni separate britanice și americane, folosește en singur. Adaugă un subtag de regiune doar atunci când servești cu adevărat conținut diferit pentru diferite țări.
Valorile Hreflang respectă formatul language sau language-region. Partea de limbă este un cod ISO 639-1 (en, es, de, pt). Regiunea opțională este un cod de țară ISO 3166-1 Alpha 2 (US, GB, MX, BR). Deci:
envizează toți vorbitorii de engleză, indiferent de țară.en-GBvizează vorbitorii de engleză din Regatul Unit.esvizează toți vorbitorii de spaniolă.es-MXvizează în mod specific vorbitorii de spaniolă din Mexic.
Un detaliu crucial: subtag-ul de regiune este o țară, nu o variantă de limbă. es-MX nu înseamnă "dialect spaniol mexican", ci înseamnă "spaniolă, afișată utilizatorilor din Mexic." Google o servește în continuare pe baza locației utilizatorului. Dacă menții dialecte regionale în traducerile tale, codul de regiune este modul în care le rutezi. Aprofundăm partea lingvistică a acestui aspect în ghidul nostru despre variantele regionale de spaniolă și portugheză.
Un exemplu comun greșit
Iată un bloc hreflang greșit pe care îl vedem constant:
<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/" />
Trei erori. en-uk este invalid deoarece codul de țară pentru Regatul Unit este GB, nu UK. sp nu este deloc un cod de limbă; spaniola este es. Iar pt-PT_BR combină două regiuni cu un caracter de subliniere (_) care nu are nicio semnificație în hreflang. Motoarele de căutare ignoră în tăcere valorile malformate, așa că nu primești nicio eroare și niciun beneficiu, doar ore de depanare întrebându-te de ce nimic nu s-a schimbat.
Reține că hreflang utilizează o cratimă (en-GB), în timp ce fișierele locale WordPress folosesc o subliniere (en_GB). Nu copia direct codurile de nume de fișier .po în etichetele hreflang.
x-default și reciprocitatea etichetelor de retur
Două reguli cauzează mai multe erori silențioase hreflang decât orice altceva: x-default lipsă și reciprocitatea întreruptă.
Valoarea x-default îi spune lui Google ce pagină să servească atunci când nicio altă limbă nu se potrivește cu utilizatorul. Este varianta ta de rezervă, de obicei selectorul tău de limbă sau pagina de pornire a pieței tale principale. Nu este strict obligatoriu conform specificațiilor, dar în practică ar trebui să îl incluzi întotdeauna. Fără el, un vizitator vorbitor de portugheză pentru care nu ai o versiune în portugheză primește o alegere aleatorie în loc de o implicită deliberată.
Reciprocitatea etichetelor de retur este inalterabilă. Fiecare pagină dintr-un set hreflang trebuie să indice înapoi către fiecare altă pagină, inclusiv către ea însăși. Dacă pagina ta în engleză listează germana ca alternativă, pagina ta în germană trebuie să listeze engleza ca alternativă. Dacă pagina în germană omite referința de retur, Google nu are încredere în întreaga relație și ignoră adnotările.
<!-- 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/" />
Auto-referința (de care indică pagina în germană în timp ce vizualizezi pagina în germană) este obligatorie, nu opțională. Un set de cinci versiuni lingvistice înseamnă că fiecare dintre cele cinci pagini afișează toate cele cinci etichete <link> plus x-default.
Trei modalități de implementare a hreflang în WordPress
Ai trei opțiuni practice, variind de la control manual complet la automatizare totală.
Metoda 1: Manual prin wp_head
Pentru un set mic de pagini statice, poți injecta etichete hreflang direct prin acțiunea wp_head din fișierul functions.php al temei tale:
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 )
);
}
} );
Aceasta îți oferă un control precis, dar nu scalează. Menținerea reciprocității manual pe sute de postări este o capcană de mentenanță.
Metoda 2: Un plugin multilingv
Dacă folosești Polylang, WPML sau TranslatePress, hreflang este generat automat pe baza relațiilor tale de traducere. Acesta este răspunsul potrivit pentru majoritatea site-urilor, deoarece pluginul știe deja ce postare este traducerea cui, astfel încât reciprocitatea și x-default sunt gestionate pentru tine. Costul este overhead-ul de runtime pe care aceste pluginuri îl adaugă, ceea ce reprezintă compromisul pe care îl examinăm în comparația noastră dintre abordările de traducere manuală versus AI.
Metoda 3: Sitemap XML cu xhtml:link
În loc să introduci hreflang în <head>-ul fiecărei pagini, poți declara relațiile în sitemap-ul tău XML folosind spațiul de nume xhtml:link. Fiecare intrare <url> listează toate alternativele sale de limbă:
<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>
Aceasta menține HTML-ul paginii tale curat și centralizează harta limbilor într-un singur fișier crawlabil, pe care Google îl citește cu plăcere. Majoritatea pluginurilor SEO pot genera acest lucru automat.
hreflang completează traducerea, nu o înlocuiește
Iată punctul pe care toată lumea îl ratează: hreflang este inutil dacă paginile subiacente nu sunt de fapt traduse. Eticheta îi spune lui Google "aceasta este versiunea în germană," dar dacă URL-ul în germană afișează în continuare șiruri de plugin-uri în engleză, etichete de checkout netraduse sau fișiere .po pe jumătate terminate, ai spus pur și simplu lui Google să servească conținut defect utilizatorilor germani cu încredere deplină.
SEO-ul multilingv real are două straturi. Stratul de conținut este reprezentat de fișierele tale traduse .po, .pot, .json și .xliff care duc fiecare șir de temă și plugin în limba țintă. Stratul de semnal este hreflang care rutează fiecare versiune finalizată către publicul său. Ambele trebuie să fie solide. Un set hreflang impecabil peste un site tradus în proporție de 40 la sută garantează doar o experiență mai proastă, mai rapid.
Aici contează cel mai mult menținerea stratului de traducere curat. Când traduci fișierele de interfață, placeholder-ele precum %s, %1$s și {name} trebuie să rămână intacte, altfel pagina ta germană „tradusă” se va randa cu token-uri %s literale care par defecte atât pentru utilizatori, cât și pentru motoarele de căutare. Un pipeline de traducere compatibil cu gettext, cu Syntax Locking, protejează automat aceste token-uri, astfel încât fiecare pagină alternativă către care îndrepți hreflang este cu adevărat gata de producție. Deoarece rulează în cloud cu Smart Batching, poți gestiona un întreg site multi-locale prin acesta fără a instala pluginuri de traducere care îngreunează runtime-ul care servește acele pagini.
Asigură-te mai întâi că ai conținutul corect, apoi lasă hreflang să-și facă treaba. Cele două împreună sunt ceea ce consolidează semnalele de clasare, elimină rezultatele în limba greșită și plasează fiecare pagină tradusă în fața oamenilor care o pot citi.
Ești gata să corectezi rezultatele căutării în limba greșită de la sursă? Încearcă SimplePoTranslate gratuit — nu este necesar un card de credit. Traduceți fișierele dvs.
.po,.potși.jsonîn planul gratuit, apoi direcționați etichetele hreflang către pagini care sunt cu adevărat pregătite pentru fiecare piață.