# How to Translate a Next.js Site for Search Engines | Vitra.ai > Next.js is the easy case, because it renders on the server. The work is in routing, metadata and getting hreflang emitted correctly for most banks. **Canonical URL**: https://www.vitra.ai/general/translate-a-nextjs-site **Source**: This is the Markdown rendering of https://www.vitra.ai/general/translate-a-nextjs-site, generated at build time from that page. --- 4 min read # How to Translate a Next.js Site for Search Engines Next.js is the easy case, because it renders on the server. The work is in routing, metadata and getting hreflang emitted correctly for most banks. [Samhitha J Bhatt](https://www.vitra.ai/author/samhitha) Senior Product Manager , Vitra.ai Updated Aug 17, 2026 ![How to Translate a Next.js Site for Search Engines](https://www.vitra.ai/static/images/blog/translate-a-nextjs-site.jpg) Table of contents [The hard part is already solved](#the-hard-part-is-already-solved) [Locale routing](#locale-routing) [Metadata is content, not decoration](#metadata-is-content-not-decoration) [hreflang has to reciprocate](#hreflang-has-to-reciprocate) [Static generation and the language matrix](#static-generation-and-the-language-matrix) [What is still client-side](#what-is-still-client-side) [Content versus interface](#content-versus-interface) [Middleware and locale detection](#middleware-and-locale-detection) [Images and Open Graph](#images-and-open-graph) [Where to start](#where-to-start) [FAQ](#faq) Contributors [Samhitha J Bhatt](https://www.vitra.ai/author/samhitha) Senior Product Manager Subscribe to our newsletter Subscribe > **Quick answer —** Next.js server-renders, so translated text reaches crawlers without extra work. The real tasks are locale routing, translating metadata as its own field, and emitting reciprocal hreflang — the three things that decide whether the translated pages rank. ## The hard part is already solved Client-rendered frameworks have to solve visibility to search engines before they can solve language. Next.js does not: the HTML that arrives already contains the text. That moves the whole problem to routing and metadata, which is a much better place for it to be. ## Locale routing A locale segment in the path gives each language its own crawlable URL, which is the requirement everything else depends on. Sub-path is the usual choice and the easiest to operate; domains are worth it only when markets are genuinely separate businesses. Whichever you choose, be consistent across the whole site. A mixture is worse than either. ## Metadata is content, not decoration Title tags, descriptions and Open Graph text are separate fields and they are where most Next.js localization stops short. A page whose body is French and whose title tag is English competes in search as an English page. Generate metadata per locale in the same place you generate the page, so the two cannot drift apart. ## hreflang has to reciprocate Every locale version points at every other, including itself, and a self-referencing canonical on each. A one-way declaration is ignored, and a translated page canonicalising to the English original asks Google to drop it. Emit these from a single source rather than by hand per page. Hand-written [hreflang](https://www.vitra.ai/general/multilingual-sitemaps) is where the errors live. ## Static generation and the language matrix Pre-rendering multiplies: pages times locales. That is fine at a few hundred and becomes a build-time problem at scale, which is where incremental regeneration earns its place. Decide which locales are pre-built and which are generated on demand. Building all of them because it is the default is how a two-minute build becomes forty. ## What is still client-side Anything rendered after hydration — a search widget, a filtered list, a cookie banner — carries strings that are not in the server HTML. They still need translating; they just do not need to be crawlable. ## Content versus interface Framework i18n handles interface strings. Content from a CMS or a database is a separate pipeline, and combining the two is a common source of a site that is half translated in a way nobody planned. [website translation](https://www.vitra.ai/features/website-translation) covers the rendered-output side, and [translation memory](https://www.vitra.ai/features/translation-memory) keeps the recurring cost proportional to what changed. Configuration notes are on the [Next.js integration](https://www.vitra.ai/integration/nextjs) page. ## Middleware and locale detection Middleware can redirect a first-time visitor to their likely language, which is useful and worth constraining: redirect once, remember the choice, and never override an explicit selection. An aggressive detector that sends a user to a language they did not ask for on every visit is worse than no detection at all, and it confuses crawlers, which present as a fixed locale. ## Images and Open Graph Localized Open Graph images need generating per language, and a share preview still showing English is the first thing a reader sees before they click. ## Where to start Render one page in the target language and view source. If the translated text is in the HTML, search engines can read it. If it only appears after hydration, it is a client-side render and needs the server side solved first. ## FAQ **Is Next.js good for multilingual SEO?** Yes, because it server-renders, so translated text reaches crawlers without extra work. The remaining tasks are locale routing, per-locale metadata and reciprocal hreflang. **Should Next.js locales use sub-paths or domains?** Sub-paths in most cases, because they are simpler to operate and give each language a crawlable URL. Separate domains are worth it only when the markets are genuinely separate businesses. **Why is my Next.js page ranking as English?** Usually untranslated metadata. Title tags, descriptions and Open Graph text are separate fields, so a French body with an English title tag competes in search as an English page. **Does static generation cause problems with many locales?** It can. Pre-rendering multiplies pages by locales, which turns a short build into a long one at scale, so decide which locales are pre-built and which are generated on demand. Our blog ## Lastest blog posts Tool and strategies modern teams need to help their companies grow. Automotive [Automotive Brochure Localization by Market](https://www.vitra.ai/automotive/automotive-brochure-localization) A car brochure is a spec grid, a legal footer and a photo library, all market-specific. What actually has to change, and why the layout decides the schedule. [Samhitha J Bhatt](https://www.vitra.ai/author/samhitha) Aug 18, 2026 Automotive [Automotive Campaign Localization Across Markets](https://www.vitra.ai/automotive/automotive-campaign-localization) Campaigns run through national companies and dealer networks, so one master becomes hundreds of files. Where the offer text and the disclaimers actually break. [Samhitha J Bhatt](https://www.vitra.ai/author/samhitha) Aug 18, 2026 Automotive [Car Service Manual Translation for Technicians](https://www.vitra.ai/automotive/automotive-service-manual-translation) A workshop manual is read mid-repair by someone with the car on a lift. What that demands of procedures, torque figures and fault codes, in every language. [Samhitha J Bhatt](https://www.vitra.ai/author/samhitha) Aug 18, 2026 [View all posts](https://www.vitra.ai/blog/page/1) --- ## Structured data ```json { "@context": "https://schema.org", "@type": "Article", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://www.vitra.ai/general/translate-a-nextjs-site" }, "headline": "How to Translate a Next.js Site for Search Engines", "image": [ { "@type": "ImageObject", "url": "https://www.vitra.ai/static/images/blog/translate-a-nextjs-site.jpg" } ], "datePublished": "2026-08-17T00:00:00.000Z", "dateModified": "2026-08-17T00:00:00.000Z", "author": [ { "@type": "Person", "name": "Samhitha J Bhatt" } ], "publisher": { "@type": "Organization", "name": "Vitra.ai", "logo": { "@type": "ImageObject", "url": "https://www.vitra.ai/static/images/vitra-v-logo.png" } }, "description": "Next.js is the easy case, because it renders on the server. The work is in routing, metadata and getting hreflang emitted correctly for most banks." } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://www.vitra.ai" }, { "@type": "ListItem", "position": 2, "name": "General", "item": "https://www.vitra.ai/general" }, { "@type": "ListItem", "position": 3, "name": "How to Translate a Next.js Site for Search Engines", "item": "https://www.vitra.ai/general/translate-a-nextjs-site" } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Is Next.js good for multilingual SEO?", "acceptedAnswer": { "@type": "Answer", "text": "Yes, because it server-renders, so translated text reaches crawlers without extra work. The remaining tasks are locale routing, per-locale metadata and reciprocal hreflang." } }, { "@type": "Question", "name": "Should Next.js locales use sub-paths or domains?", "acceptedAnswer": { "@type": "Answer", "text": "Sub-paths in most cases, because they are simpler to operate and give each language a crawlable URL. Separate domains are worth it only when the markets are genuinely separate businesses." } }, { "@type": "Question", "name": "Why is my Next.js page ranking as English?", "acceptedAnswer": { "@type": "Answer", "text": "Usually untranslated metadata. Title tags, descriptions and Open Graph text are separate fields, so a French body with an English title tag competes in search as an English page." } }, { "@type": "Question", "name": "Does static generation cause problems with many locales?", "acceptedAnswer": { "@type": "Answer", "text": "It can. Pre-rendering multiplies pages by locales, which turns a short build into a long one at scale, so decide which locales are pre-built and which are generated on demand." } } ] } ```