A Netorigo Storefront tipikusan harom nyelven szolgal: magyar, angol, kinai. A search-engine indexalas itt nem trivialis: HU-EN gyors, ZH egesz mas matek. Az alabbiakban leirom a kanonikus URL strategiat, a hreflang konfigot, plusz a Google Search Console lecket, ami megtanitotta nekunk a paginacios canonical-t.
Per-locale URL kepek
Az URL strukturak nem osztanak utat. A magyar termekoldal /termekek/asus-zenbook-14, az angol /products/asus-zenbook-14, a kinai /cn/products/asus-zenbook-14. Ez szandekos: a Google a slugok lokalizalasat ranking signalkent kezeli (a magyar feltöltő nem ugyanaz mint az angol charger).
A Next.js side dynamic route /[locale]/[section]/[slug], ahol a section is per-locale szotarbol fordul ({ hu: 'termekek', en: 'products', zh: 'products' }). Igy a getStaticPaths szinten mar a helyes path generalodik, nincs runtime rewrite reteg.
hreflang headerek
Minden HTML response head-ben szerepel a teljes locale-tabel:
<link rel="alternate" hreflang="hu" href="https://example.com/termekek/asus-zenbook-14" />
<link rel="alternate" hreflang="en" href="https://example.com/products/asus-zenbook-14" />
<link rel="alternate" hreflang="zh" href="https://example.com/cn/products/asus-zenbook-14" />
<link rel="alternate" hreflang="x-default" href="https://example.com/products/asus-zenbook-14" />
Az x-default az EN — a Google azon ranglatra fordit, ha a vizitor nyelvet nem tudja eldonteni. A magyar partner egy resze szeretne a HU-t default-kent, de a Google policy szerint az x-default-nak vilag-default-ot kell jelolnie, nem regio-default-ot.
A kanonikus URL szabaly
A <link rel="canonical"> ALWAYS LOCALE-SPECIFIC. A HU oldal canonical-ja a HU URL, nem az EN URL. Ez sok keresomotor SEO guide szerint kontroverzialis — sokan azt javasoljak, hogy a fo-nyelvi (en) URL-t adjuk meg kanonikusként a tobbi nyelvi oldal-on, hogy ne ossza ket linkjogot.
Mi NEM ezt csinaljuk. Az ervek:
- A magyar termekoldal magyar tartalmu, magyar latogatonak, magyar konverziora. Mit gyozzon meg a Google, hogy az angol URL-t indexalja?
- A hreflang mar elmondja, hogy ezek ekvivalens forditasok. A canonical felulirasa redundans, neha kart okoz.
- A Google sajat dokumentacioja ("International and multilingual sites") epp ezt ajanlja: locale-specific canonical, hreflang-clustered.
Sitemap per locale
Harom XML sitemap: /sitemap-hu.xml, /sitemap-en.xml, /sitemap-zh.xml. Egy /sitemap.xml index osszefogja oket. A Google igy fel tudja deriteni a teljes URL-keszletet anelkul, hogy egy 80000 URL-es ossz-sitemapot kellene parse-olnia (Google limit 50000 URL / sitemap).
A Google Search Console lecke
2025 majus: a Search Console riport "Duplicate, Google chose different canonical" hiba ~12000 URL-en. A vizsgalat: a paginalt PLP oldalakon (pl. /termekek?page=2) a canonical valodi maga (?page=2), nem a base (/termekek). Ez NEM hiba a kanonikai szabaly szerint — de a Google sajat heuristikaja gyakran a ?page=1-et tekinti igazi kanonikusnak, igy a ?page=2..N oldalak indexalas-szempontbol "elveszik" a base alatt.
Ket opcio:
- Mind self-canonical: ahogy mi csinaltuk, de ez veszit a 12000-bol kb. 8000-t.
- Mind a base canonical: minden
?page=Na?page=1-re canonical. Ezt is csinaltak masok, de ekkor a N-edik oldal termekei eltunhetnek a search-bol.
Mi a 1-est valasztottuk a 2-vel szemben, mert a kategoria szintű search a PLP-ket targetalja amugyis, az indexalt oldalfelek redundansak.
A ZH eset es amit elhalasztottunk
A kinai locale egy egesz mas matek: deviza (CNY), cim formatum (proviniciakkal), fizetes (Alipay, WeChat Pay nincs Stripe-on). Ezt 2025 vegen mertuk fel, es elhalasztottuk a beepitest. A kinai PLPe-k indexalva vannak (organic traffic SEO ok), de tranzakcio nincs — clutter a cart oldal cseregombokkal mar igenyel partneri SealedSecret-eket, amit nem akartunk a megfelelo arbitrazs nelkul beszerezni.
A tanusag: a SEO felulet ALATT mukodik a fizikai locale, vagyis a search ranking ott nem feltetelez teljes commerce stacket. Csak a UX-en lattszott, mert a vasarlas gomb "varjon, hamarosan elerheto" labelt mutatott.