SEO & vizibilitate
Hreflang în WordPress: configurare pentru un site multilingv
Configurează hreflang pentru pagini traduse: coduri de limbă, relații reciproce, canonical, x-default și verificări înainte de publicare.
Hreflang descrie relația dintre versiuni lingvistice sau regionale echivalente. Pentru un site WordPress multilingv, configurarea începe cu maparea paginilor traduse și se validează în ambele direcții, nu prin simpla apariție a unei etichete în cod.
Un magazin are o categorie în română și traducerea ei în engleză. Ambele se deschid, însă într-o căutare apare uneori versiunea nepotrivită pentru utilizator. Înainte de a adăuga reguli, verifică dacă paginile chiar sunt echivalente, dacă fiecare are un URL stabil și dacă vizitatorul poate schimba limba fără să fie trimis la homepage.
Acest ghid privește relația dintre pagini internaționale, nu optimizarea profilului unei afaceri pe hartă. Pentru prezența unei locații, consultă ghidul SEO local. Pentru alegerea unui singur URL dintre duplicate în aceeași limbă, folosește explicația canonical. Confundarea celor trei scopuri produce implementări care se contrazic.
Ce semnale transmite hreflang
Google folosește adnotările hreflang pentru a înțelege variantele localizate ale unei pagini. Implementarea poate fi făcută în HTML, în antete HTTP sau în sitemap. Aceste metode sunt echivalente din perspectiva Google; repetarea aceleiași configurații în toate trei nu aduce automat un avantaj. [1]
Hreflang nu traduce conținutul și nu înlocuiește calitatea paginii. Un text românesc ascuns sub un URL care sugerează limba engleză rămâne o problemă editorială. Nici moneda selectată într-un selector nu demonstrează că există o versiune lingvistică distinctă. Înaintea etichetelor, inventariază ceea ce livrează efectiv fiecare adresă.
Pentru proiectul tău, scrie într-o propoziție scopul fiecărei versiuni: „pagina în română pentru cititorii de română” sau „pagina în engleză cu livrare și termeni specifici unei piețe”. Dacă nu poți descrie diferența, este posibil să creezi variante inutile. Analiza se face pe nevoie reală, nu pe numărul de steaguri din meniu.
Pasul 1: alege structura și păstrează URL-uri accesibile
Pregătește o structură în care fiecare versiune poate fi vizitată direct. Nu te baza exclusiv pe un cookie sau pe alegerea memorată în browser. Un coleg trebuie să poată copia adresa unei pagini în engleză, iar alt coleg să vadă aceeași versiune fără să parcurgă mai întâi un selector.
Google descrie mai multe opțiuni pentru site-uri multilingve și regionale și recomandă URL-uri distincte pentru versiuni de limbă. Redirecționarea automată exclusiv după limba presupusă a vizitatorului poate îngreuna accesul la alternative. [2] Alegerea dintre subdirectoare, subdomenii și domenii separate trebuie adaptată echipei și infrastructurii, nu făcută numai pentru aspect.
Într-un exemplu de planificare, două subdirectoare sunt mai ușor de inventariat într-un singur tabel. Totuși, echipele cu oferte și operațiuni diferite pot avea alte nevoi. Discută structura împreună cu strategia afacerii online și cu responsabilul de dezvoltare înainte să creezi sute de traduceri.
Pasul 2: construiește matricea paginilor echivalente
Fiecare rând al matricei reprezintă o singură intenție: o categorie, un produs, un serviciu sau un ghid. Coloanele sunt limbile disponibile. Nu pune în același rând o categorie și un articol despre acea categorie doar fiindcă au cuvinte asemănătoare. Echivalența trebuie să aibă sens pentru persoana care schimbă limba.
| Familie demonstrativă | Română | Engleză | Observație |
|---|---|---|---|
| Scaune de birou | /ro/scaune-birou/ |
/en/office-chairs/ |
Aceeași categorie |
| Ghid de montaj | /ro/ghid-montaj/ |
/en/assembly-guide/ |
Aceleași instrucțiuni |
| Serviciu disponibil local | /ro/instalare/ |
Nedisponibil | Nu inventăm echivalent |
Când traducerea nu există, lasă celula goală. Nu completa toate lipsurile cu homepage-ul în limba respectivă. În meniul vizibil poți explica disponibilitatea, dar în matricea tehnică păstrează numai relații justificate. Această disciplină previne erori care se multiplică ulterior printr-un șablon automat.
Pentru un catalog, adaugă și un identificator stabil al familiei. Două produse cu nume traduse diferit pot fi același obiect, iar două pagini cu titluri similare pot descrie modele distincte. Leagă maparea de datele produsului, nu doar de potrivirea textelor. Vezi și organizarea SEO a unui magazin online.
Pasul 3: alege corect codurile
Codul indică mai întâi limba și, opțional, regiunea. De exemplu, ro descrie româna, iar en-GB engleza pentru Regatul Unit. Pentru regiune nu utiliza UK în loc de GB și nu trata EU drept cod valid pentru o versiune europeană. [1]
Nu adăuga o regiune doar pentru că firma este înregistrată într-o anumită țară. Dacă pagina este un ghid în engleză fără ofertă regională distinctă, documentează motivul pentru care ai avea nevoie de mai multe variante. Costul editorial include actualizarea exemplelor, a informațiilor comerciale și a legăturilor pentru fiecare piață.
Creează un mic dicționar intern: cod, limbă, piață, URL de bază și persoana care aprobă traducerea. Acesta devine punctul de referință pentru dezvoltator și editor. Fără el, aceeași limbă poate ajunge etichetată diferit în plugin, sitemap și integrarea de produse.
Pasul 4: implementează un set coerent în WordPress
Verifică mai întâi pluginul de traducere existent și codul generat. Nu adăuga manual un al doilea set dacă prima componentă generează deja relațiile. Rezultatul urmărit este o singură sursă administrabilă a mapării, cu aceeași logică pe toate tipurile de pagini.
Pentru două pagini demonstrative, setul din secțiunea head poate arăta astfel. Ambele pagini includ aceeași listă de alternative; URL-urile sunt exemple, nu rute ale site-ului KEPA:
<link rel="alternate" hreflang="ro"
href="https://example.com/ro/scaune-birou/">
<link rel="alternate" hreflang="en"
href="https://example.com/en/office-chairs/">
Pentru o familie, fiecare versiune trebuie să se includă pe sine și să indice alternativele, iar relațiile trebuie confirmate și în sens invers. URL-urile trebuie să fie complete. [1] În verificare, nu copia lista de la prima categorie pe toate celelalte: aceeași structură de cod poate ascunde destinații complet greșite.
În cazul unui site fără o componentă care gestionează aceste relații, pregătește cerințe pentru dezvoltare WordPress personalizată. Cerința trebuie să includă salvarea mapării, tratarea traducerilor retrase și testele pentru paginile noi, nu doar inserarea unui fragment în antet.
Când folosești x-default
O destinație de rezervă poate ajuta pentru limbile care nu sunt acoperite explicit. Valoarea x-default este potrivită în special pentru pagini de selecție a limbii sau regiunii. [1] În exemplul nostru, un selector real poate fi adăugat numai dacă există și se comportă conform planului.
Nu transforma această opțiune într-un link universal către o pagină oarecare. Deschide selectorul pe telefon, verifică etichetele și urmărește unde ajunge utilizatorul după alegere. Ideal, schimbarea limbii păstrează contextul paginii atunci când există echivalent. Când nu există, comunică lipsa fără să ascunzi navigarea.
Păstrează selectorul accesibil prin tastatură și cu denumiri textuale ale limbilor. Un steag singur poate fi ambiguu. Detaliile de interacțiune țin de proiectarea experienței de navigare, separat de etichetele care ajung în codul pentru motoarele de căutare.
Cum aliniezi hreflang și canonical
Revizuiește canonical-ul fiecărei versiuni împreună cu relațiile de limbă. Pentru pagini traduse pe care dorești să le păstrezi distincte, nu trimite mecanic toate canonical-urile către versiunea română. Google recomandă, la folosirea hreflang, indicarea unei pagini canonice în aceeași limbă sau a celei mai bune alternative disponibile. [3]
Separă două întrebări în fișa de test: „care este URL-ul preferat pentru această versiune?” și „care sunt versiunile echivalente în alte limbi?”. Prima ține de consolidare; a doua de localizare. O singură coloană numită „link SEO” nu este suficientă pentru a surprinde ambele decizii.
Când există parametri pentru valută, filtre sau tracking, nu îi introduce automat în familia de limbă. Întreabă dacă reprezintă pagini distincte sau doar stări ale aceleiași pagini. Pentru semnalele tehnice în ansamblu, folosește checklistul SEO tehnic, iar pentru schimbări definitive de adresă verifică redirecționările 301.
Pasul 5: testează relațiile, nu numai sintaxa
Alege o categorie, un produs, un ghid și o pagină fără traducere. Pentru fiecare, salvează HTML-ul livrat și extrage alternativele. Deschide fiecare destinație și repetă verificarea în sens invers. Un validator de sintaxă nu îți spune dacă pagina în engleză descrie același produs.
Adaugă statusul HTTP, canonical-ul și indexabilitatea în tabel. O adresă care redirecționează trebuie analizată până la destinația finală; o ciornă nu trebuie anunțată ca alternativă publică. Pentru verificări punctuale poți utiliza inspecția răspunsului HTTP și verificările disponibile în SEO Lab, completate de lectura efectivă a paginii.
Nu testa doar primul rând al catalogului. Include nume cu diacritice, pagini paginate, produse retrase și traduceri publicate recent. Tocmai excepțiile arată dacă logica este robustă. Un export cu zece exemple explicate este mai util decât o afirmație că „etichetele există peste tot”.
Publicare, cache și pagini retrase
Publică mapările după ce traducerile sunt aprobate. Dacă două pagini intră live în momente diferite, verifică din nou perechea după publicarea celei de-a doua. O versiune salvată doar în administrare nu trebuie să apară ca destinație accesibilă publicului.
După schimbarea unei relații, reîmprospătează paginile din familia afectată, nu numai pagina editată. Altfel, un răspuns vechi poate păstra o mapare unilaterală. În proiectele cu CDN, verifică separat HTML-ul livrat și configurația salvată. Diagnosticul cache-ului explică de ce o salvare nu dovedește ce copie primește vizitatorul.
Când retragi o traducere, actualizează toate relațiile care o indicau. Nu lăsa mențiunea până la următorul redesign. Include această acțiune în procedura de mentenanță a site-ului și în verificările de import ale catalogului.
Exemplu de eroare care trece un control superficial
Imaginează-ți trei categorii în română și trei traduceri. Un șablon copiat corect generează două etichete pe fiecare pagină, dar toate categoriile românești indică aceeași categorie în engleză. Numărătoarea etichetelor arată bine; experiența cititorului și matricea sunt greșite.
Remedierea începe cu identificatorul familiei. Compară rândul fiecărei categorii, corectează mapările și verifică întoarcerea din engleză. Apoi golește numai copiile afectate și repetă testul într-un context nelogat. Nu adăuga etichete suplimentare pentru a compensa relația greșită; repară sursa datelor.
În raport notează diferența dintre „sintaxă validă”, „destinație accesibilă” și „echivalență confirmată”. Cele trei criterii răspund unor întrebări diferite. Dacă traducerea nu este încă revizuită, marcheaz-o ca neconfirmată, chiar dacă testul HTTP este verde.
Cum monitorizezi fără să promiți poziții
Urmărește în rapoartele Search Console paginile și țările relevante, pe perioade comparabile. O fluctuație de la o zi la alta nu dovedește nici succesul, nici eșecul implementării. Notează data lansării, numărul de familii verificate și alte schimbări publicate în aceeași perioadă.
Pentru conținutul nou, păstrează și un brief editorial pe limbă. Traducerea mecanică a cuvintelor-cheie nu demonstrează intenția locală a căutării. Analiza cererii de căutare trebuie făcută pentru piața vizată, iar redactarea și revizia conținutului trebuie să respecte contextul cititorilor.
La revizia lunară, verifică familiile noi și excepțiile, nu modifica etichetele pentru fiecare scădere de impresii. Dacă paginile sunt accesibile, echivalente și consecvente, investigația poate continua spre relevanță, concurență și calitatea ofertei. Hreflang nu este un buton de creștere automată a autorității.
Ce verifici într-un selector de limbă al unei pagini de produs
Ia un produs demonstrativ cu două variante de limbă și deschide pagina în română. Selectează o culoare, apoi schimbă limba. Întrebarea de test nu este doar dacă apare un text englezesc, ci dacă utilizatorul rămâne la produsul echivalent și dacă informația despre disponibilitate este coerentă. Înregistrează separat comportamentul variantei selectate, deoarece nu orice platformă îl păstrează automat.
Revino prin selector și verifică adresa, titlul și legăturile din pagină. Un meniu tradus corect poate ascunde un buton de cumpărare care trimite spre cealaltă versiune. Acest defect ține de experiența utilizatorului și de maparea aplicației; adăugarea unui hreflang suplimentar nu îl repară. Echipa trebuie să identifice componenta care generează butonul.
Testează și un produs fără traducere. Interfața poate explica indisponibilitatea unei limbi sau poate oferi navigare alternativă, dar nu trebuie să pretindă că o categorie generală este traducerea acelui produs. În fișa editorială, marchează lipsa echivalentului și păstrează familia incompletă până când există o pagină verificată.
Înainte de lansarea unui lot de traduceri, fă același exercițiu pe câteva familii diferite. Dacă toate au aceeași eroare, repară șablonul sau maparea înainte să publici restul. Corectarea unei reguli la sursă este mai ușor de urmărit decât zeci de excepții manuale aplicate după publicare.
Pentru un site de servicii, adaptează proba la formularul și oferta fiecărei limbi. O traducere trebuie să descrie ceea ce poți livra efectiv publicului respectiv. Nu păstra automat afirmații despre transport, termene sau jurisdicții care nu se aplică. Revizia lingvistică și cea comercială sunt condiții separate de validitatea etichetelor.
Întrebări frecvente despre hreflang
Trebuie să traduc toate paginile înainte de lansare?
Nu toate paginile trebuie să aibă echivalent în fiecare limbă. Publică numai traduceri utile și verificate, apoi declară relațiile existente. Nu umple lipsurile prin trimiteri automate către homepage. Prioritizează paginile care susțin efectiv oferta și operațiunile pentru publicul respectiv.
Pot folosi simultan sitemap și etichete HTML?
Tehnic, da, dar întreținerea mai multor surse poate produce contradicții. Alege o metodă administrabilă și verifică rezultatul public. Pentru un proiect în care pluginul generează deja relațiile în HTML, documentează un motiv real înainte să adaugi o implementare paralelă în sitemap.
Schimbă hreflang limba browserului sau redirecționează vizitatorul?
Nu este un selector de limbă executat în browser. Navigația vizibilă și comportamentul de redirecționare se configurează separat. Testează-le independent: un set corect de adnotări nu repară un buton care trimite utilizatorul la o pagină greșită.
Surse și documentație
Matricea, exemplele și procedura de revizie sunt propuneri editoriale. Domeniul example.com este demonstrativ; nu descrie o implementare live KEPA.
AI CLARIFICAT PROBLEMA?
Hai să o transformăm
într-o implementare.
Folosește ghidul pentru diagnostic. Pentru intervenții în proiect, stabilim ce trebuie schimbat și cum verificăm rezultatul.
