Egy magyar vállalkozás weboldala ritkán születik többnyelvűnek. Előbb megvan magyarul, aztán jön egy német ajánlatkérés, egy osztrák partner, egy angol katalógus, és valaki gyorsan felrak egy fordító bővítményt. Az a döntés, ami ilyenkor három perc alatt megszületik, vagyis hogy milyen URL alatt éljenek a fordítások, utána évekig visszaköszön minden költözésnél, minden riportban és minden indexelési vitában.
Melyik URL-szerkezet jár a legkevesebb későbbi átirányítással?
Rövid válasz. A nyelvi alkönyvtár jár a legkevesebb későbbi átirányítással, mert ez az egyetlen megoldás, ami egyszerre bővíthető új nyelvvel, elbírja a domain- és tárhelyváltást, és nem kényszerít arra, hogy később paraméteres címeket cserélj valódi útvonalakra.
Hivatalosan igazolt. A Google Search Central dokumentációja a nyelvi vagy országspecifikus változatokra három javasolt szerkezetet sorol fel, az országkódos domaint, az aldomaint és az alkönyvtárat, az URL-paraméterrel megkülönböztetett változatot pedig kifejezetten nem ajánlja, mert nehéz szegmentálni és a felhasználó számára sem olvasható.
Saját tapasztalat. A magyar kkv-oldalakon, amiket az évek során átvettünk, a fordítás szinte mindig kisebb probléma volt, mint az, hogy hány réteg átirányítás ült már az oldalon. Ahol paraméteres nyelvkezeléssel indultak, ott a későbbi rendberakás jellemzően három külön munkát jelentett, a címek cseréjét, az átirányítási szabályok megírását és a belső linkek javítását. Ahol alkönyvtárral indultak, ott a nyelv hozzáadása általában csak tartalmi feladat maradt.
Mit jelent a gyakorlatban a három megoldás?
Nyelvi alkönyvtár
A fordítás a fő domain alatt, külön útvonalon él, például pelda.hu/de/impressum/ alakban. Egy tárhely, egy tanúsítvány, egy Search Console tulajdon, egy mérési property. A domain minden korábbi értéke, hivatkozása és ismertsége ugyanazon a néven marad. A WordPress oldalán ezt a Polylang, a WPML és a TranslatePress is tudja, a TranslatePress gyakorlatilag csak ezt.
URL-paraméter
A fordítás ugyanazon az útvonalon, lekérdezési paraméterrel jelenik meg, például pelda.hu/kapcsolat/?lang=de alakban. Ez a leggyorsabban bekapcsolható mód, mert nem kell hozzá se átírási szabály, se rendes permalink-struktúra, és olyan tárhelyen is működik, ahol nincs jogod a szerverkonfigurációhoz nyúlni. A WPML ezt a módot alapból kínálja, jellemzően ott, ahol az átírás nem oldható meg.
Aldomain és külön országdomain
A fordítás önálló hoszton él, például de.pelda.hu vagy pelda.de címen. Ez adja a legerősebb országjelzést és a legtisztább szétválasztást, viszont ez kerül a legtöbbe üzemeltetésben, mert minden hoszt külön tanúsítványt, külön DNS-t, külön mérést és többdomainos felállásnál külön WordPress-példányt vagy multisite hálózatot jelent.
Miért a paraméteres megoldás termeli a legtöbb duplikációs munkát?
Rövid válasz. Mert a paraméter nem viselkedik stabil azonosítóként, így minden rendszer, ami az URL-t kulcsként használja, külön kezelést igényel.
Saját nézőpont. Ez a cikk fő állítása. A paraméteres nyelvkezelés rövid távon a legolcsóbb, hosszú távon viszont ez hozza a legtöbb ismétlődő kézimunkát. Nem egyetlen nagy hiba miatt, hanem mert öt-hat helyen szivárog.
- A gyorsítótár és a CDN alapértelmezés szerint gyakran figyelmen kívül hagyja vagy éppen túl bőven kezeli a lekérdezési paramétereket, így vagy rossz nyelv jelenik meg, vagy feleslegesen sokszorozódik a cache.
- A canonical-kezelés kényes, mert a paraméteres és a paraméter nélküli cím ugyanazt a sablont adja vissza, és egy rosszul beállított bővítmény könnyen a magyar változatra mutató kanonikus jelzést tesz a német oldalra.
- Az elemzésben és a Search Console-ban nem tudod egyszerűen külön mappaként nézni a német forgalmat, mert nincs mappa.
- A megosztott linkekről gyakran lemarad a paraméter, így a német ajánlatkérő a magyar oldalra érkezik.
- A nyomkövető paraméterekkel együtt (például kampányazonosítókkal) sokféle kombináció jön létre ugyanabból a tartalomból.
Hivatalosan igazolt. A Google 2022-ben megszüntette a Search Console URL-paraméter eszközét, tehát az a menekülőút már nincs meg, amivel korábban központilag lehetett jelezni a paraméterek szerepét. Maradt a canonical, a hreflang és a belső linkelés fegyelme.
Szakmai feltételezés. A válaszmotorok és az AI-crawlerek szempontjából jó eséllyel szintén az alkönyvtár a biztonságosabb, mert az idézhető forrás címe önmagában hordozza a nyelvet, és kevésbé sérülékeny arra, hogy egy közvetítő réteg lehagyja a paramétert. Ez nem hivatalos állásfoglalás, hanem a megfigyelt viselkedésből levont következtetés.
Milyen kérdések döntik el, melyik szerkezet való hozzád?
Hat kérdés általában elég a döntéshez. Válaszold meg őket sorban, mielőtt bővítményt választasz.
- Hány nyelvet akarsz, és mennyi lesz belőle három év múlva? Két nyelvnél még minden megoldás elviselhető. Négy nyelv fölött az alkönyvtár marad kezelhető, mert a bővítés nem jár új hoszttal, új tanúsítvánnyal és új méréssel.
- Ugyanaz a tartalom más nyelven, vagy tényleg más az ajánlat országonként? Ha az árazás, a szállítás, a garancia és a jogi tájékoztató is eltér, akkor nem fordításról van szó, hanem országváltozatról. Ilyenkor a külön országdomain vagy legalább az ország szerinti alkönyvtár indokolt.
- Ki fordít? Ha belső kolléga vagy fordítóiroda dolgozik a WordPress admin felületén, az egy telepítés a legkényelmesebb. Ha országonként külön marketinges csapat van saját jogosultsággal és saját ütemezéssel, akkor a szétválasztás valós előny.
- Mennyire szabad a szerver? Ha van hozzáférésed az átírási szabályokhoz és a virtuális hoszt beállításaihoz, minden út nyitva áll. Ha csak egy szűk tárhelyed van szép permalinkek nélkül, a paraméteres megoldás lehet az egyetlen, ami ma elindul. Ilyenkor tudatos ideiglenes döntés legyen, ne véglegesnek szánt.
- Ki üzemelteti a webhelyet hat hónap múlva? Több domain több frissítési kört, több biztonsági mentést és több lejáró tanúsítványt jelent. Ha nincs gazdája, előbb-utóbb az egyik változat elavult bővítményekkel fut.
- Mennyi hivatkozás és ismertség van már a jelenlegi domainen? Erős magyar domainnél az alkönyvtár őrzi meg a legtöbbet, mert nem osztja szét a webhelyet több néven.
Hogyan tedd gépi olvashatóvá a nyelvváltót?
Rövid válasz. A nyelvváltó akkor olvasható gépileg, ha minden nyelvi változat valódi, kattintható hivatkozásként szerepel a HTML-ben, és ugyanezt a kapcsolatot hreflang-annotáció is kimondja mindkét irányban.
- A váltó legyen igazi
<a href>elem, ne JavaScripttel átírt legördülő. Ha a lista csak kattintásra épül fel, a crawler nem látja a másik nyelvet. - Minden oldalra kerüljön ki a teljes hreflang-készlet, benne az önhivatkozással. Példa egy kapcsolati oldalra.
<link rel="alternate" hreflang="hu" href="https://pelda.hu/kapcsolat/" /><link rel="alternate" hreflang="de" href="https://pelda.hu/de/kontakt/" /><link rel="alternate" hreflang="x-default" href="https://pelda.hu/kapcsolat/" /> - A hivatkozás legyen kölcsönös. Ha a magyar oldal mutat a németre, a németnek vissza kell mutatnia a magyarra, különben az annotáció figyelmen kívül maradhat.
- Abszolút URL-t használj, a végleges protokollal és a végleges domainnel. Relatív cím és vegyes
www-kezelés esetén a párosítás elromlik. - A
<html lang="de">attribútumot is állítsd helyesen. Hivatalosan igazolt, hogy a Google a nyelvi célzáshoz a hreflanget és nem ezt az attribútumot használja, viszont a képernyőolvasók és több feldolgozó eszköz igen, tehát nem díszítés. - Nyelvenként külön webhelytérkép-bejegyzés menjen ki, a hreflang-kapcsolatokat pedig a webhelytérképben is megadhatod, ha a sablonba nehéz beleírni.
- Ellenőrizd a valóságot, ne a beállítást. Kérd le nyersen az oldalt és nézd meg, mi került ki.
curl -s https://pelda.hu/de/kontakt/ | grep -i hreflang
Saját tapasztalat. A hibák nagy része nem a hreflang megírásánál keletkezik, hanem utána. Valaki átnevez egy német oldalt, a magyar párja marad a régi címen, és a kapcsolat csendben félbetörik. Érdemes havonta egyszer végigfuttatni egy bejárást, ami kigyűjti a párját vesztett annotációkat.
Mit kezdj a nem lefordított oldalakkal?
Rövid válasz. Amit nem fordítottál le, azt ne mutasd fordításként. A leggyakoribb kár nem a hiányzó német oldalból származik, hanem abból, hogy a német nyelvváltó magyar tartalomra visz.
- A nyelvváltóban csak a ténylegesen létező fordítások jelenjenek meg. Ha az adott oldalnak nincs német párja, a váltó vigyen a német nyitóoldalra, és mondja is meg, hogy az adott aloldal nem érhető el németül.
- A hiányzó párra ne tegyél hreflang-hivatkozást. Az olyan annotáció, ami valójában magyar tartalomra mutat németként, félrevezető jelzés.
- A gépi fordítást átolvasás nélkül ne tedd indexelhetővé. Hivatalosan igazolt, hogy a Google a gépi fordítást önmagában nem tiltja, de az emberi ellenőrzés nélküli, értéket nem adó tömeges fordítást a spamre vonatkozó irányelvei alatt kezeli.
- Ha szakaszosan fordítasz, előbb a pénzt hozó útvonal menjen, vagyis a nyitóoldal, a szolgáltatás- vagy termékoldal, a kapcsolati oldal és az ajánlatkérő űrlap. A blogarchívum ráér.
- A részlegesen kész nyelvi ágat átmenetileg
noindexjelzéssel is tarthatod, amíg összeáll. Ilyenkor jegyezd fel, mikor kell levenni, mert elfelejteni könnyű. - Az űrlapokat, a visszaigazoló e-maileket és a hibaüzeneteket is nézd át. Egy német érdeklődő magyar nyelvű visszaigazolása legalább annyit ront a bizalmon, mint egy lefordítatlan aloldal.
Hogyan válts, ha már paraméteres szerkezeten ülsz?
A váltás nem bonyolult, de sorrendfüggő, és mentés nélkül nem kezdhető el. Az alábbi menet a gyakorlatban bevált.
- Készíts teljes mentést, és dolgozz először másolaton.
- Gyűjtsd ki a jelenlegi paraméteres címeket a szerver naplójából és a keresési teljesítmény adataiból, hogy tudd, mit kell átirányítani.
- Állítsd át a bővítményt alkönyvtáras módra, és ellenőrizd, valóban a várt címeken jelenik-e meg minden nyelv.
- Írd meg az átirányítást a régi paraméteres címekről az újakra. Apache alatt ez nagyjából így néz ki.
RewriteCond %{QUERY_STRING} (^|&)lang=de(&|$)RewriteRule ^(.*)$ /de/$1? [R=301,L]
A szabály végi kérdőjel dobja el az eredeti lekérdezési karakterláncot, enélkül a paraméter végigöröklődik. - Javítsd a belső hivatkozásokat az adatbázisban, először szárazon futtatva.
wp search-replace 'pelda.hu/?lang=de' 'pelda.hu/de/' --dry-run - Ürítsd a gyorsítótárat a WordPressben, a szerveren és a CDN-en is, majd nézd meg, a cache kulcsa jó helyre esik-e.
- Generáld újra a webhelytérképet, és nyújtsd be az új változatot.
- Két-három hétig figyeld a lefedettségi jelentést és a 404-eket. A legtöbb elmaradt átirányítás itt bukik ki.
Szakmai feltételezés. Az újraindexelés üteme webhelyenként erősen eltér, és a beavatkozás nem garantál sem gyorsabb bejárást, sem jobb helyezést. Reálisan annyit vársz tőle, hogy a szerkezet a továbbiakban ne dolgozzon ellened.
Ellenőrzőlista indulás előtt
- Minden nyelv saját, stabil, beszédes címen él, és nem paraméter dönti el, mit lát a látogató.
- A nyelvváltó valódi hivatkozásokból áll, és csak létező fordításokat kínál.
- A hreflang mindkét irányban ki van vezetve, önhivatkozással és
x-defaultértékkel együtt. - Minden nyelvi változatnak saját, önmagára mutató canonical jelzése van.
- A gyorsítótár és a CDN nyelvenként külön tárolja a válaszokat.
- A webhelytérkép minden nyelvet tartalmaz, és a régi címek átirányítása működik.
- Az űrlapok, visszaigazolások, hibaüzenetek és sütibanner is a megfelelő nyelven jelennek meg.
- Van gazdája a frissítéseknek, a mentésnek és a tanúsítványoknak minden hoszton.
Források és további olvasnivalók
- Google Search Central, Managing multi-regional and multilingual sites
- Google Search Central, Tell Google about localized versions of your page (hreflang)
- Google Search Central, Spam policies for Google web search
- Google Search Central Blog, a Search Console URL-paraméter eszközének megszüntetése
- W3C Internationalization, Language tags in HTML and XML
- IETF BCP 47, Tags for Identifying Languages
- WordPress Developer Resources, WordPress Multisite kézikönyv
- WPML, Polylang és TranslatePress hivatalos dokumentációja a nyelvi URL-módokról
- Schema.org, inLanguage tulajdonság
- A nyelvi alkönyvtár bővíthető, költöztethető és nem kényszerít későbbi URL-cserére, ezért alapesetben ezzel jársz a legjobban.
- A ?lang= paraméteres szerkezet gyorsan bekapcsolható, de a canonical, a cache, a mérés és a linkelés szintjén folyamatos kézi munkát hoz.
- Külön ccTLD csak akkor éri meg, ha tényleg országspecifikus a tartalom, a jogi háttér és a felelős ember is.
- A nyelvváltó akkor gépi olvasható, ha valódi hivatkozásokból áll, és hreflang-annotáció is tartozik hozzá minden irányban.
- A nem lefordított oldalakat ne mutasd fordításként, inkább hagyd ki a nyelvváltóból és a hreflang-párokból.
Gyakori kérdések
Az aldomain vagy az alkönyvtár a jobb választás egy magyar kkv-nak?
A legtöbb esetben az alkönyvtár, mert egy tárhelyen, egy tanúsítvánnyal és egy méréssel üzemeltethető, és a domain eddigi ismertségét sem osztja szét. Aldomaint akkor érdemes választani, ha az adott nyelvi ágat külön csapat viszi, külön ütemezéssel és külön jogosultsággal.
Rontja a helyezést, ha ?lang= paraméterrel oldom meg a nyelveket?
Önmagában nem szankcionált megoldás, de a Google dokumentációja nem ajánlja, mert nehezen szegmentálható és a felhasználó számára sem olvasható. A gyakorlati kockázat inkább az, hogy a canonical, a gyorsítótár és a megosztott linkek szintjén csúszik félre valami, és emiatt jelenik meg rossz nyelvű tartalom.
Kell hreflang, ha csak két nyelv van az oldalon?
Igen, két nyelvnél is érdemes kitenni, mert ez mondja meg egyértelműen, hogy a két cím ugyanannak a tartalomnak a nyelvi változata. Mindkét oldalon szerepeljen az önhivatkozás és a másik nyelvre mutató sor is, különben az annotáció figyelmen kívül maradhat.
Mi legyen azokkal az oldalakkal, amiket még nem fordítottunk le?
Ne szerepeljenek a nyelvváltóban fordításként, és ne kapjanak hreflang-párt sem. Ha a látogató mégis nyelvet vált egy le nem fordított aloldalon, vidd a másik nyelv nyitóoldalára, és jelezd, hogy az adott aloldal azon a nyelven még nem érhető el.
Használható gépi fordítás a kezdéshez?
Használható kiindulásnak, de átolvasás nélkül ne tedd indexelhetővé. A Google a gépi fordítást nem tiltja, viszont az emberi ellenőrzés nélküli, hozzáadott érték nélküli tömeges fordítást a spamre vonatkozó irányelvei alatt kezeli, tehát a kockázat valós.
Mennyire kockázatos később átállni paraméteresről alkönyvtárasra?
Elvégezhető munka, ha van mentés, teljes URL-lista és rendes átirányítási szabály. A kockázat nem a technikában van, hanem az elfelejtett részletekben, jellemzően a belső linkekben, a gyorsítótárban és a régi webhelytérképben, ezért a váltás után két-három hétig figyelni kell a 404-eket.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.