Menerjemahkan Situs Web Next.js: Rute Bahasa yang Dapat Dirayapi dan SEO
Pelajari cara menerjemahkan situs Next.js dengan URL bahasa berbasis jalur, metadata yang dilokalkan, hreflang, dan alur kerja glosarium yang mudah dikelola—tanpa pergantian bahasa yang hanya mengandalkan cookie.
![Translating a Next.js Website: a Next.js app-router folder tree with a [locale] node feeding a page on a white grid](https://gloteo.com/images/blog/translating-a-nextjs-website/translating-a-nextjs-website-hero.970f6828.webp)
Translating a Next.js website is not only an i18n library exercise. Search engines need distinct, crawlable URLs for each language version, with metadata and body copy rendered in the initial HTML response. Cookie-based locale switches or client-only toggles on a single URL leave Google without separate pages to index.
Quick answer: crawlable locale routes beat cookie switches
If you need a single rule before diving into App Router segments: give every language its own crawlable URL. Google recommends different URLs per language or region rather than relying on cookies or browser language alone. Path prefixes such as /en/ and /de/, dedicated subdomains, or separate domains each create indexable addresses. Cookie-only switches on one URL do not.
Cookie-based locale switching can feel convenient during development because you avoid duplicating routes. In production SEO, that pattern hides language variants from crawlers. Path-based locales expose stable addresses you can list in sitemaps, annotate with hreflang, and monitor in Search Console. For a deeper framing of market versus language strategy, see our guide on international SEO versus multilingual SEO.
Choose a Next.js URL pattern for languages
Next.js teams usually pick one of three crawlable patterns:
- Subdirectories —
example.com/en/docs,example.com/fr/docs. Easy to deploy on one host; clear hierarchy for hreflang. - Subdomains —
en.example.com,fr.example.com. Useful when regional teams operate semi-independently; still needs reciprocal hreflang. - ccTLDs or dedicated domains — strongest geographic signal when you truly operate separate properties; highest operational overhead.
Google determines page language primarily from visible content. Whichever pattern you choose, keep each URL predominantly in one language—including navigation, footer links, and error pages. Avoid mixing languages on the same template without a clear user-facing reason.
Do not automatically redirect visitors based on guessed language or location. Google advises against that behavior because it can block crawlers and frustrate users. Offer a visible language selector that links to the alternate locale URL instead.
App Router and locale segment design
In the App Router, a dynamic [locale] segment is the common pattern: app/[locale]/layout.tsx wraps localized pages. Define supported locales in one config object and validate params.locale in layouts or middleware. Invalid locales should 404, not silently fall back to English on the same URL.
Middleware can redirect bare / to a default locale folder such as /en/, but keep alternates linkable. Pair middleware with generateStaticParams when you statically generate marketing pages so each locale builds ahead of time.
Cookie vs path locales: Cookie or header negotiation on a single URL changes content without changing the address. Crawlers typically fetch one URL once; they will not see every language variant. Path-based locales (or subdomain/domain equivalents) align with Google’s different-URL guidance. Cookies may still store user preference after they choose a language, as long as public URLs remain distinct.
Use next-intl, next-i18next, or similar libraries for message loading, but let routing—not cookies alone—define public URLs.
Localize metadata, Open Graph and structured data
Each locale route needs its own <title>, meta description, canonical, and Open Graph tags in the server-rendered HTML. In App Router, use generateMetadata per page, reading translated strings from your message files. Localized title and meta description should not depend on a client-side language swap after hydration.
Apply the same discipline to JSON-LD: WebPage, Organization, and FAQ blocks should use translated strings and locale-appropriate inLanguage values. If you emit hreflang link elements, generate the full reciprocal set in the layout or page metadata helper—missing return links break hreflang clusters.
Hreflang, canonicals and sitemaps for Next.js
Hreflang tells Google about alternate language or regional URLs. Every URL in a cluster must reference every other member, including itself, with matching codes. Implement hreflang in <head>, HTTP headers, or XML sitemaps via xhtml:link entries—pick one consistent method per site.
Each locale URL also needs a canonical pointing to the preferred URL for that language when duplicates exist (for example, tracking parameters or print views). Do not canonical a French page to its English equivalent; canonicals consolidate duplicates within the same language.
Generate per-locale sitemaps or one sitemap index listing all language URLs. Sitemaps improve discovery and can carry hreflang annotations. After deploy, verify samples with Search Console URL Inspection and an hreflang testing workflow. Our multilingual SEO platform overview explains how SEO teams audit these signals across locales.
Avoiding client-only language shells
A frequent Next.js pitfall is rendering an English HTML shell, then swapping strings in useEffect. Crawlers may not execute that swap reliably; users see a flash of wrong language. Server Components, static generation, or SSR should render translated copy in the first response. Client Components can hydrate interactive pieces, but marketing copy and headings belong in the server tree.
Path- or subdomain-based locale routes create distinct crawlable URLs; cookie-only locale switches do not meet Google’s recommendation. If you use a translation proxy for preview, ensure production still serves complete HTML per locale URL.
Content workflow: glossary, TM and review
Engineering choices fail in market when translations drift from product terminology. Layer a glossary, translation memory (TM), and human review on top of Next.js i18n files. Google helpful-content guidance prioritizes people-first pages; thin or boilerplate-only language versions are weak SEO and weak answer sources.
Workflow sketch:
- Extract strings from JSON or PO files into a CAT-friendly pipeline.
- Enforce glossary terms for product names and UI labels.
- Run linguistic QA on staging URLs, not just diffing source files.
- Re-sync when English source changes; stale locales erode trust.
Daftar periksa implementasi
Before launch, confirm crawl paths, metadata, and annotations:
Bing Webmaster Guidelines also emphasize crawlable, useful content and clear structure—patterns that help Google generally help Bing indexing too.
Kesalahan umum
Cookie-only locale on one URL — hides variants from crawlers.
Missing return hreflang links — breaks reciprocity and weakens clustering.
English canonical on translated pages — sends the wrong consolidation signal.
Client-only metadata — titles/descriptions absent from initial HTML.
Auto-redirect by IP or Accept-Language — blocks crawlers and ignores user choice.
Untranslated chrome — mixed-language navigation confuses language detection.
Thin machine translation without review — fails helpful-content expectations.
Dasar-dasar mesin pencari tradisional dan mesin jawaban
Shared foundations for Next.js locale routes and server-rendered HTML still matter across Google, Bing, and answer engines: crawlable language versions, clear entities, evidence-backed claims, structured data where truthful, and real localization—not English-only shells. Treat the guides below as platform-specific lenses on the same multilingual delivery bar.
Panduan platform: Google Search
Di Google Search, penemuan halaman bergantung pada URL versi lokal yang dapat dirayapi, dengan HTML yang sesuai bahasa, judul dan tajuk yang akurat, serta hreflang timbal balik jika tersedia versi alternatif. Landasan teknisnya mencakup konten yang dapat diindeks (bukan pergantian bahasa yang hanya mengandalkan cookie), metadata yang dilokalkan, peta situs, dan penerapan URL kanonis yang konsisten. Konten berkualitas berarti konten utama yang mengutamakan pengguna dalam setiap bahasa; otoritas berasal dari identitas organisasi yang jelas dan sumber pendukung—bukan pemasaran alat penerjemahan. Implikasi multibahasa: setiap URL untuk pasar atau bahasa tertentu harus dapat berdiri sendiri. Ukur melalui cakupan pengindeksan di Search Console dan Inspeksi URL untuk setiap versi lokal. Yang diketahui dan yang belum pasti: Google mendokumentasikan cara kerja multibahasa dan hreflang, tetapi tidak menjamin peringkat dari CMS atau alur kerja MTPE apa pun.
Panduan platform: Bing
Bing menemukan dan mengindeks halaman multibahasa yang dapat dirayapi dengan struktur yang jelas, serupa dengan persyaratan Google mengenai kejelasan URL dan konten. Landasan teknisnya mencakup URL versi lokal yang dapat diakses, konten bermanfaat, dan pemantauan melalui Bing Webmaster Tools. Utamakan pelokalan tajuk, klaim, dan FAQ daripada hanya menerjemahkan elemen antarmuka. Sinyal otoritas tetap bergantung pada sumber tepercaya dan entitas yang konsisten. Implikasi multibahasa: jangan sembunyikan versi bahasa di balik pengalih yang hanya bekerja di sisi klien. Ukur pengindeksan dan statistik perayapan di Bing Webmaster Tools. Yang diketahui dan yang belum pasti: pedoman Bing menekankan konten bermanfaat yang dapat dirayapi; jangan mengada-adakan faktor pemeringkatan khusus Bing untuk alat penerjemahan.
Panduan platform: ChatGPT
ChatGPT dapat mengutip atau merangkum halaman yang dapat diakses publik jika versi bahasanya jelas dan kontennya siap digunakan sebagai jawaban. Penemuan konten tidak mengikuti pemeringkatan perayapan konvensional; visibilitas berarti terpilih sebagai sumber atau dirujuk dalam jawaban. Landasan teknis tetap dimulai dari URL HTML yang dapat diakses—bukan overlay widget yang menyembunyikan teks. Karakteristik konten yang membantu meliputi jawaban langsung, FAQ, dan terminologi konsisten berdasarkan glosarium. Otoritas berasal dari bukti dan entitas yang konsisten di seluruh versi lokal. Implikasi multibahasa: setiap halaman versi lokal harus dapat dibaca secara mandiri. Pengukurannya belum sempurna—perlakukan pemeriksaan kutipan sebagai hipotesis. Yang diketahui dan yang belum pasti: tidak ada jaminan terdokumentasi bahwa MTPE atau integrasi CMS apa pun akan menghasilkan kutipan di ChatGPT.
Panduan platform: Gemini
Gemini dan pengalaman AI Google terkait terbantu oleh entitas yang konsisten, data terstruktur yang akurat, serta halaman lokal yang dapat diindeks. Visibilitas berarti dirujuk atau dikenali—bukan mengada-adakan faktor pemeringkatan Gemini. Landasan teknisnya beririsan dengan keterayapan dan kualitas metadata di Google Search. Konten harus menyajikan klaim dan definisi yang jelas dalam setiap bahasa. Otoritas bergantung pada konsistensi organisasi dan bukti pendukung. Implikasi multibahasa: nama produk yang distandardisasi melalui glosarium mengurangi kebingungan antarversi lokal. Lakukan pengukuran konvensional melalui Search Console dan ambil sampel jawaban AI untuk penilaian kualitatif. Yang diketahui dan yang belum pasti: perilaku Gemini tidak menggantikan panduan Google Search yang terdokumentasi mengenai hreflang dan versi bahasa.
Panduan platform: Google AI Overviews
Google AI Overviews dapat menautkan halaman pendukung; dasar kelayakannya tetap bertumpu pada konten yang mengutamakan pengguna dan dapat diindeks. Fitur ini bukan pengalih bahasa dan tidak menggantikan hreflang. Landasan teknisnya tetap berupa HTML versi lokal yang dapat dirayapi dan data terstruktur yang sesuai fakta. Karakteristik kontennya meliputi jawaban ringkas dan tajuk yang jelas dalam setiap bahasa. Sinyal otoritasnya sejalan dengan standar konten bermanfaat. Implikasi multibahasa: tidak ada jaminan halaman terjemahan mana pun akan disertakan dalam AI Overviews. Ukur melalui laporan generatif Search Console jika tersedia, dan pisahkan dari metrik indeks tradisional. Yang diketahui dan yang belum pasti: tidak ada alur kerja penerjemahan yang dapat menjanjikan penempatan di AI Overviews.
Peran GlotEO
Hand-rolled Next.js i18n works for small sites; scale adds glossary control, review queues, and SEO validation across locales. GlotEO connects to modern stacks so marketers manage translations while engineers keep App Router structure.
Teams that treat localization as a routing and content-quality problem—not only a string swap—ship faster iterations without breaking crawl paths. Share a glossary before translators start, review pages in context on staging, and re-check hreflang whenever you add routes. Measure indexing in Search Console per locale folder or subdomain rather than relying on a single-site aggregate.
Explore the website localization platform at GlotEO website localization and compare GlotEO pricing and plans when scoping rollout.
Referensi
- Mendukung panduan yang dirujuk dalam artikel ini (Panduan Webmaster Bing)
- Mendukung panduan yang dirujuk dalam artikel ini (Cara menentukan URL kanonis dengan rel=canonical dan metode lainnya)
- Mendukung panduan yang dirujuk dalam artikel ini (Membuat konten yang bermanfaat, tepercaya, dan mengutamakan pengguna)
- Mendukung panduan yang dirujuk dalam artikel ini (Memberi tahu Google tentang versi halaman Anda yang dilokalkan)
- Mendukung panduan yang dirujuk dalam artikel ini (Mengelola situs multiregional dan multibahasa)
- Mendukung panduan yang dirujuk dalam artikel ini (Mempelajari peta situs)