Translating a Next.js Website: Crawlable Locale Routes and SEO

Learn how to translate a Next.js site with path-based locale URLs, localized metadata, hreflang, and a maintainable glossary workflow—without cookie-only language switches.

Translating a Next.js Website: a Next.js app-router folder tree with a [locale] node feeding a page on a white grid

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.

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:

  1. Subdirectories — example.com/en/docs, example.com/fr/docs. Easy to deploy on one host; clear hierarchy for hreflang.
  2. Subdomains — en.example.com, fr.example.com. Useful when regional teams operate semi-independently; still needs reciprocal hreflang.
  3. 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.

قائمة التحقق من التنفيذ

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.

أخطاء شائعة

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.

أسس البحث التقليدي ومحركات الإجابة

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.

في بحث Google، يعتمد اكتشاف المحتوى على عناوين URL قابلة للزحف للنسخ اللغوية والإقليمية، مع محتوى HTML باللغة المناسبة، وعناوين وعناوين فرعية دقيقة، وروابط hreflang متبادلة عند وجود نسخ بديلة. وتشمل الأسس التقنية محتوى قابلًا للفهرسة، لا تبديلًا يعتمد على ملفات تعريف الارتباط وحدها، وبيانات وصفية موطّنة، وخرائط مواقع، وضبطًا دقيقًا للروابط الأساسية (canonical). وتعني جودة المحتوى تقديم محتوى رئيسي يضع احتياجات الناس أولًا في كل لغة؛ أما الموثوقية فتنبع من وضوح هوية المؤسسة والمصادر المؤيدة، لا من التسويق لأدوات الترجمة. وما يعنيه ذلك للمحتوى متعدد اللغات: يجب أن يكون كل عنوان URL مخصص لسوق أو لغة قائمًا بذاته. قِس النتائج عبر تقارير التغطية وأداة فحص عنوان URL في Search Console لكل نسخة لغوية أو إقليمية. المعلوم وغير المؤكد: توثّق Google سلوك المحتوى متعدد اللغات وhreflang، لكنها لا تضمن ترتيبًا معينًا نتيجة استخدام أي نظام لإدارة المحتوى أو سير عمل للتحرير اللاحق للترجمة الآلية (MTPE).

دليل المنصة: Bing

يكتشف Bing الصفحات متعددة اللغات ذات البنية الواضحة والقابلة للزحف ويفهرسها، بما يشبه متطلبات Google لوضوح عناوين URL والمحتوى. وتشمل الأسس التقنية عناوين URL للنسخ اللغوية والإقليمية يمكن جلب محتواها، ومحتوى مفيدًا، ومتابعةً عبر Bing Webmaster Tools. أعطِ الأولوية لتوطين العناوين والادعاءات والأسئلة الشائعة بدلًا من الاقتصار على ترجمة عناصر الواجهة. وتظل مؤشرات الموثوقية معتمدة على مصادر جديرة بالثقة وكيانات متسقة. وما يعنيه ذلك للمحتوى متعدد اللغات: لا تُخفِ اللغات خلف أدوات تبديل تعمل من جانب العميل فقط. قِس الفهرسة وإحصاءات الزحف في Bing Webmaster Tools. المعلوم وغير المؤكد: تؤكد إرشادات Bing أهمية المحتوى المفيد القابل للزحف؛ فلا تختلق عوامل ترتيب خاصة بـBing لأدوات الترجمة.

دليل المنصة: ChatGPT

قد يستشهد ChatGPT بالصفحات المتاحة للعامة أو يلخّصها عندما تكون نسخها اللغوية واضحة ومهيأة لتقديم إجابات. لا يقوم اكتشاف المحتوى هنا على ترتيب نتائج زحف تقليدي؛ بل يتمثل الظهور في اختيار الصفحة مصدرًا أو الإشارة إليها في الإجابات. وتظل الأسس التقنية تبدأ بعناوين URL تتيح الوصول إلى محتوى HTML، لا بطبقات أدوات مصغّرة تخفي النصوص. ومن خصائص المحتوى المفيدة: الإجابات المباشرة، والأسئلة الشائعة، والمصطلحات الثابتة المستمدة من المسارد. وتنبع الموثوقية من الأدلة واتساق الكيانات عبر النسخ اللغوية والإقليمية. وما يعنيه ذلك للمحتوى متعدد اللغات: ينبغي أن تكون كل صفحة موطّنة مفهومة بذاتها. القياس ليس دقيقًا تمامًا؛ لذا تعامل مع فحوص الاستشهادات بوصفها فرضيات. المعلوم وغير المؤكد: لا يوجد ضمان موثّق بأن التحرير اللاحق للترجمة الآلية (MTPE) أو أي تكامل مع نظام إدارة محتوى سيؤدي إلى استشهادات في ChatGPT.

دليل المنصة: Gemini

تستفيد Gemini وتجارب الذكاء الاصطناعي ذات الصلة من Google من اتساق الكيانات، والبيانات المنظّمة الدقيقة، والصفحات الموطّنة القابلة للفهرسة. ويتمثل الظهور في الإشارة إلى المحتوى أو التعرّف عليه، لا في اختلاق عوامل ترتيب لـGemini. وتتقاطع الأسس التقنية مع متطلبات قابلية الزحف وجودة البيانات الوصفية في بحث Google. وينبغي أن يقدّم المحتوى ادعاءات وتعريفات واضحة بكل لغة. وتعتمد الموثوقية على اتساق معلومات المؤسسة وما يؤيدها من مصادر. وما يعنيه ذلك للمحتوى متعدد اللغات: ضبط أسماء المنتجات بالمسارد يقلل الالتباس بين النسخ اللغوية والإقليمية. قِس النتائج بالطرق التقليدية عبر Search Console، وافحص عينة من إجابات الذكاء الاصطناعي لتقييمها نوعيًا. المعلوم وغير المؤكد: سلوك Gemini ليس بديلًا عن إرشادات بحث Google الموثّقة بشأن hreflang والنسخ اللغوية.

دليل المنصة: Google AI Overviews

قد تتضمن Google AI Overviews روابط إلى صفحات داعمة؛ وتظل معايير الأهلية قائمة على محتوى قابل للفهرسة يضع احتياجات الناس أولًا. وهي ليست أداة لتبديل اللغة ولا تحل محل hreflang. وتبقى الأسس التقنية هي محتوى HTML قابل للزحف لكل نسخة لغوية أو إقليمية وبيانات منظّمة تعكس الواقع. وتشمل خصائص المحتوى إجابات موجزة وعناوين واضحة بكل لغة. وتعكس مؤشرات الموثوقية متطلبات المحتوى المفيد. وما يعنيه ذلك للمحتوى متعدد اللغات: إدراج أي صفحة مترجمة في هذه الملخصات غير مضمون. قِس النتائج عبر تقارير البحث التوليدي في Search Console حيثما تتوفر، وافصلها عن مقاييس الفهرسة التقليدية. المعلوم وغير المؤكد: لا يمكن لأي سير عمل للترجمة أن يَعِد بالظهور في AI Overviews.

دور 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.

المراجع