Wie me e Next.js Websiite mit 10 Sprooche boue cha (App Router Aaläitig 2026)

E mehrsprachigi Website boue isch e vo de effektivschte Investitione, wo me für SEO und Conversion cha mache. Sächsedrissg Prozent vo de Online-Iichäufer bevorzuged, Produkt mit Informatione i ihrer Muetersprach z'chaufe (CSA Research, 2020), glichzitig unterstützed aber weniger als 5% vo de aktive Websites meh als drü Spräche. Mir händ vor churzem Frida Marketing i 10 Spräche uf em Next.js 15 App Router usegäh – ohni next-intl, ohni e Übersetzigs-SaaS und ohni 10 separati Codebase. Do isch gnau, wie mir's gmacht händ.

Wichtigschti Pünkt

• 76% vo de Iichäufer bevorzuged, i ihrer Muetersprach z'chaufe; 40% wärded nie uf Site chaufe, wo das nöd aabüted (CSA Research, 2020)
• Änglisch deckt nume 49.7% vom globale Web-Inhalt ab — e mehrsprachigi Ufbou erschliesst die andere 50.3% (W3Techs, Juni 2026)
• Eis [lang] dynamischs Segment + e API-Präfix-Berechnig bedient 10 Spräche us eme einzige Satz vo Dateie
• Gemini 2.5 Flash übersetzt e komplette 3'000-Wort-HTML-Bricht pro Sprach i weniger als 90 Sekunde zu fascht null Chöschte

Warum e mehrsprachigi Ufbou günstiger isch, als du dänksch

D'Chöschte-Argument gege mehrsprachigi Sites wird fascht immer übertriibe. De Next.js 15 App Router verwaltet d'ganz Routing-Schicht dur e einzigs dynamischs Segment. D'Inhaltsschicht – Titel, Text, Metadate – chunnt vo dinere API pro Sprach. Und d'Übersetzigs-Schicht cha vollständig automatisiert werde.

Änglisch macht 49.7% vo allne Website-Inhalt nach Sprach us. Schpanisch und Dütsch händ je 6.0%, Japanisch 5.0% und Französisch 4.6% (W3Techs, Juni 2026). Nume d'Unterstützig vo de top fünf nöd-änglische Spräche deckt rund 70% vom indexierte globale Web-Inhalt ab. Next.js lauft uf 2.7% vo allne Websites weltwiit und 17.9% vo de befragte Entwickler bruuched's (Stack Overflow Developer Survey, 2024) – das heisst, d'Tools und d'Community-Unterstützig für mehrsprachigs Next.js isch so guet wie nie zuvor gsi.

D'wirkliche Chöschte sind nöd de Code – es isch de Inhalt. Sobald dis Routing iigrichtet isch, isch s'Hinzuefüege vo ere Sprach e API-Aaruef pro publizierte Post. Mir händ 7 Posts i 10 Spräche publiziert, ohni zuesätzliche Wartigsufwand pro Sprach. D'Architektur-Entscheidig isch d'Investition; d'Laufziit isch gratis.

96% vo de Firme, wo i Lokalisierig investiert händ, händ e positive ROI gmoldet, debi händ 65% mindischtens e 3-fache Ertrag erzielt (DeepL Business Survey, 2024). De Business Case isch solid. D'technischi Hürde isch viel tiefer, als die meischte Entwickler erwarte.

Wie du dis [lang] dynamischs Segment strukturiersch

De Next.js App Router macht dis Dateisystem zu dim Router. Erstell e src/app/[lang]/ Verzeichnis und jede Route drin bechunnt params.lang automatisch. De einzig Parameter isch d'ganz Basis für e 10-sprachigi Site.

`` src/app/ ├── page.tsx ← English homepage (/) ├── blog/[slug]/page.tsx ← English blog posts ├── admin/layout.tsx ← English admin └── [lang]/ ├── page.tsx ← All other language homepages (/fi, /fr, /de…) ├── blog/[slug]/page.tsx ← Language blog posts └── admin/ └── layout.tsx ← Language admin (same file, reads params.lang) ``

Änglisch isch im Root-Verzeichnis. Jedi anderi Sprach isch under [lang]. Du schriibsch e Datei und lohsch params.lang d'Logik steuere – nie sprochespezifischi Site-Kopie.

Definier dini Sprachkonfiguration i ere kanonische Datei:

```typescript // src/lib/languages.ts export const LANGUAGES = [ { code: 'fi', urlPrefix: 'fi', apiPrefix: 'fi_', name: 'Finnish' }, { code: 'fr', urlPrefix: 'fr', apiPrefix: 'fr_', name: 'French' }, { code: 'de', urlPrefix: 'de', apiPrefix: 'de_', name: 'German' }, { code: 'it', urlPrefix: 'it', apiPrefix: 'it_', name: 'Italian' }, { code: 'no', urlPrefix: 'no', apiPrefix: 'no_', name: 'Norwegian' }, { code: 'ch', urlPrefix: 'ch', apiPrefix: 'pt_', name: 'Swiss German' }, // ⚠️ API uses pt_ { code: 'sr', urlPrefix: 'sr', apiPrefix: 'sr_', name: 'Serbian' }, { code: 'es', urlPrefix: 'es', apiPrefix: 'es_', name: 'Spanish' }, { code: 'sw', urlPrefix: 'sw', apiPrefix: 'sw_', name: 'Swedish' }, // ⚠️ URL uses sv ];

export const LANG_CODES = LANGUAGES.map(l => l.code); ```

Zwei Bsunderheite, wo sofort dokumentiert werde sötted: ch (Schwiizerdütsch) bruucht pt_ als API-Präfix us historische Namensgründ, und sw (Schwedisch) bruucht sv als URL-Präfix, um em ISO-Standard z'entspräche. Die Unstimmigkeite wärded kei Fehler verursache, wenn du d'Konfiguration zentralisierisch, aber sie wärded jede Entwickler verwirre, wo zum Projekt chunnt, ohni dass das dokumentiert isch.

S'Verbinde vo Sprach-Routes mit dinere Backend-API

D'ganz mehrsprachigi API-Integration isch e einzigi Berechnig:

``typescript const prefix = params.lang ? ${params.lang}_ : ''; const posts = await fetch(${API_URL}/api/${prefix}posts); ``

Wenn params.lang 'fi' isch, wird /api/fi_posts abgruefe. Wenn's undefined isch (änglischs Root-Verzeichnis), wird /api/posts abgruefe. Jedi Site, jede Date-Aaruef, jede Admin-Operation bruucht das gliiche Muster. Es git kei pro-Sprach-Fetch-Helfer, kei Switch-Statement, kei Bsunderheit.

Mir wänded das Muster i 10 Spräche und 5 Inhaltstype – Posts, Produkt, Site, Autore und Kategorie – i de Produktion aa. De einzigi Randfall, wo mir gha händ: e paar API-Endpoints händ unterschiidlichi Strukture für Änglisch im Vergliich zu de sprochespezifische Versione. I üsem Setup, /api/{lang}_posts/by-url/{slug} existiert für jede Sprach, aber s'änglische Äquivalent isch e komplett andere Controller (/api/resolve-route?url=...). Überprüef dini änglische API-Routes immer separat – sie sind oft anders strukturiert als die sprochespezifische, bsunders bi Laravel-Backends, wo d'änglische Routes zuerst erstellt worde sind.

De Admin-Panel bruucht s'gliiche Präfix-Muster:

``typescript // src/app/[lang]/admin/posts/page.tsx export default function AdminPostsPage({ params }: { params: { lang?: string } }) { const prefix = params.lang ? ${params.lang}_ : ''; // Fetch from /api/${prefix}posts // Build edit/delete links with /${params.lang}/admin/edit-post/${id} } ``

E einzigi AdminPostsPage Komponente bedient alli 10 Sprach-Admin-Panels. De änglisch Admin isch uf /admin/posts; Finnisch isch uf /fi/admin/posts. Gliichi Datei.

Statischi Site für alli 10 Spräche generiere

Statischi Generierig isch de Punkt, wo mehrsprachigi Next.js Sites ihrne Performance-Vorteil bechömmed. Bruuch generateStaticParams, um jede Sprachvariante bi de Build-Ziit vorz'rendere:

```typescript // src/app/[lang]/page.tsx — static language homepages export async function generateStaticParams() { return LANG_CODES.map(lang => ({ lang })); // Returns: [{lang:'fi'},{lang:'fr'},{lang:'de'},...] }

// src/app/[lang]/blog/[slug]/page.tsx — static blog posts per language export async function generateStaticParams({ params }: { params: { lang: string } }) { const prefix = params.lang ? ${params.lang}_ : ''; const res = await fetch(${API_URL}/api/${prefix}posts); const data = await res.json(); return data.data.map((post: { url: string }) => ({ slug: post.url })); } ```

Statischi Site erschiined als ● im next build Output. Sie wärded bi de Deploy-Ziit zu HTML vorz'rendert, uf Vercel's Edge CDN gschobe und lade global i Millisekunde. Für e 10-sprachigi Site isch das de Unterschiid zwüsched eme 50ms TTFB und eme 800ms Origin-Hit bi jedem Aaluef.

E Regle zum Merke: kombiniere nie generateStaticParams mit { cache: 'no-store' } Fetches uf de gliiche Site. I Next.js 15 Produktions-Builds wirft das Error: Page changed from static to dynamic at runtime – e Fehler, wo nume i de Produktion uftaucht, nöd im Dev. Bruuch stattdesse ISR:

``typescript const res = await fetch(${API_URL}/api/${prefix}posts, { next: { revalidate: 3600 }, // Regenerate stale pages every hour }); export const dynamicParams = true; // Allow new slugs without a full rebuild ``

next-intl verzeichnet ab Juni 2026 2.3 Millione wöchentlichi npm-Downloads, was es zur dominante Bibliothek i dem Bereich macht. Es isch d'richtigi Wahl, wenn du lokalisierigs-sensitivi Formatierig oder hartcodierti UI-String-Verwaltig bruuchsch. Für dategsteuerti CMS-Sites isch es optional – reines App Router Routing verwaltet alles, was du würklich bruuchsch.

SEO für e 10-sprachigi Site: Hreflang und generateMetadata

Hreflang seit Google, weli Sprachversion welere Zielgruppe z'serviere isch. Ohni das konkurriered dini 10 Sprachsite gegenand um die gliiche Suechaafrage. D'App Router Implementierig isch suuber:

```typescript // src/lib/hreflang.ts const HREFLANG_CODE: Record = { fi: 'fi', fr: 'fr', de: 'de', it: 'it', no: 'no', ch: 'de-CH', // Swiss German internal code → BCP 47 de-CH sr: 'sr', es: 'es', sw: 'sv', // Internal code sw → ISO sv (Swedish) };

export function getAlternates(routeKey: string, lang?: string) { const BASE = 'https://fridamarketing.com'; const enUrl = ${BASE}/${routeKey};

const languages: Record = { 'x-default': enUrl, en: enUrl, };

for (const [code, hreflang] of Object.entries(HREFLANG_CODE)) { const urlPrefix = code === 'sw' ? 'sv' : code; languages[hreflang] = ${BASE}/${urlPrefix}/${routeKey}; }

return { canonical: lang ? ${BASE}/${lang === 'sw' ? 'sv' : lang}/${routeKey} : enUrl, languages, }; } ```

Bruuch es i generateMetadata uf jede Site:

``typescript export async function generateMetadata({ params }: Props): Promise { const post = await fetchPost(params.lang, params.slug); return { title: post.meta_title, description: post.meta_description, alternates: getAlternates(blog/${post.url}, params.lang), }; } ``

Das generiert e komplette Hreflang-Satz für jede Site – x-default, en und alli 9 Sprachvariante – mit null manuellem Wartigsufwand. Kei XML Sitemap Hreflang-Blöck zum Synchronisiere; Next.js füegt sie als Tags i de rendertä ii.

Gemäss mehrsprachiger SEO-Forschig gsehnd Firme, wo i Lokalisierig investiered, 300–500% meh organische Traffic us internationale Märkt (MotionPoint, 2025). D'Hreflang-Schicht isch das, wo de Traffic erfasst. Ohni das ignoriert Google entweder d'Sprachsignal oder zeigt die falschi Version für jede Region aa.

Übersetzig automatisiere: Gemini API i dim Publish-Pipeline

Manuelles Übersetze i 10 Spräche isch s'falsche Modell für jedes Team ohni dedizierts Lokalisierigsbudget. Mänschlichi Übersetzig choschtet $0.15–$0.30 pro Wort – e 2'500-Wort-Post choschtet $375–$750 pro Sprach, oder $3'375–$6'750 für alli 9 (Seatongue, 2025). Maschinelli Übersetzig mit Nacherbearbeitig reduziert das um 50–70%. Aber für strukturierti HTML-Inhalt us eme CMS isch e vollständig automatisierti API-Übersetzig mit eme präzise Prompt no besser.

Do isch de Kern-Übersetzigs-Aaruef, wo mir mit Gemini 2.5 Flash bruuched:

``javascript async function translatePost(content, targetLang) { const prompt = Translate the following JSON to ${targetLang}. Rules: - Translate all text values: title, intro, body, meta_title, meta_description - Preserve ALL HTML tags, attributes, and structure in body exactly as-is - Generate a URL-safe localized slug and return it as "url" - Keep brand names, code examples, and proper nouns in English - Return valid JSON only: { title, intro, body, meta_title, meta_description, url }

Content: ${JSON.stringify(content)}`;

const response = await gemini.generateContent(prompt); return JSON.parse(response.text()); } ```

Mir händ das i de Produktion für 7 publizierti Posts agwendet, jede automatisch i 9 Spräche übersetzt. D'Qualität isch publikationsbereit für Finnisch, Französisch, Dütsch, Schpanisch und Italienisch ohni manuelli Überprüefig. Norwegisch und Schwedisch bruuched ab und zue Stichprobe. Serbisch bruucht e Korrekturleser-Durchgang – Gemini isch weniger zueverlässig mit Kyrillisch i komplexe HTML-Kontext. Für e inhaltsstarchi Site reduziert die Aawendig de Übersetzigsufwand um über 90% im Vergliich zu sogar Nacherbearbeitigs-Workflows vo maschinelle Übersetzige.

De Ziitpunkt isch wichtig. E 3'000-Wort-HTML-Post bruucht mit Gemini 2.5 Flash ungefähr 60–90 Sekunde pro Sprach. Das sind 9–13 Minute für alli 9 Übersetzige. Stell immer e 150-Sekunde-Abbruch-Timeout bi jedem API-Aaruef ii und implementier e exponentielle Backoff – s'Modell blibt ab und zue bi hocher Nachfrog hänge:

``javascript const controller = new AbortController(); const timeoutId = setTimeout(() => controller.abort(), 150000); try { const res = await fetch(GEMINI_URL, { signal: controller.signal, ...opts }); clearTimeout(timeoutId); return res; } catch (err) { clearTimeout(timeoutId); if (err.name === 'AbortError') { // Retry with exponential backoff await new Promise(r => setTimeout(r, Math.pow(2, attempt) * 5000)); } } ``

84% vo de Marketer säged, dass Inhaltslokalisierig ihri Iinahme gsteigert hät, und Firme, wo i Übersetzig investiert händ, händ mit 1.5x höcherer Wahrschiinlichkeit e Iinahmestiegerig gseh (Redokun, 2025). D'Automatisierig entfernt de letscht wirkliche Blocker – d'Betriebschöschte für Übersetzige im grosse Stil.

---

Du bouisch e mehrsprachigi Next.js Site? Mir entwerfed und boued Next.js Websites für e globales Publikum – kompletti i18n-Routing, Hreflang-SEO und automatisierti Übersetzigs-Pipelines sind inbegriffe. Lueg dir üsi Next.js Entwickligsdienstleistige aa oder nimm Kontakt uf, um dis Projekt z'bspräche.

---

Häufigi Frog

Bruuch ich next-intl, um e mehrsprachigi Next.js Site z'boue?

Nei. De Next.js 15 App Router verwaltet mehrsprachigs Routing nativ dur e [lang] dynamischs Segment. Bibliotheke wie next-intl bieted Mehrwert für lokalisierigs-sensitivi Formatierig (Date, Währige, Pluralisierig) und d'Verwaltig vo hartcodierte UI-Strings. Wenn din Inhalt vo eme CMS oder ere API chunnt, bruuchsch sie nöd für Routing, statischi Generierig oder SEO.

Wie verchnüpf ich URL-Sprachpräfixe mit API-Endpoints i Next.js?

Berechn e Präfix zur Laufziit: const prefix = params.lang ? \${params.lang}_\ : '';. Bruuch es i jedem Fetch-Aaruef – zum Bischpiil, /api/${prefix}posts. Das Muster verwaltet alli 10 Spräche us ere gmeinsame Site-Datei. Kei sprochespezifischi Site, kei Switch-Statements, kei Bsunderheite.

Was isch de beschti Wäg, e Next.js Site automatisch i mehri Spräche z'übersetze?

Bruuch Gemini 2.5 Flash oder GPT-4 i dim Publish-Pipeline. Schick de änglisch Inhalt als JSON mit eme System-Prompt, um alli Textwärte z'übersetze, wärend HTML-Tags erhalte blibed und e lokalisierti URL-Slug generiert wird. Füeg e 150-Sekunde-Timeout und exponentielle Backoff hinzu. Maschinelli Übersetzig mit Nacherbearbeitig choschtet 50–70% weniger als e volli mänschlichi Übersetzig (Seatongue, 2025), und volli API-Automatisierig reduziert das no wiiter.

Wie füeg ich Hreflang-Tags zu ere Next.js 15 App Router Site hinzu?

Bou e getAlternates(routeKey, lang) Funktion, wo es Next.js alternates Objekt zrugggit. Verchnüpf interni URL-Codes mit BCP 47 Sprachcodes – sw → sv für Schwedisch, ch → de-CH für Schwiizerdütsch – und füeg x-default hinzu, wo uf de änglische kanonische Link zeigt. Gib es vo alternates.languages innerhalb vom generateMetadata Export jede Site zrugg.

Wieviel Spräche sötti mini Website unterstütze?

Fang mit 2–3 aa, wo zu dine wichtigschte Traffic-Quelle passed, und erwiitere denn. Änglisch deckt nume 49.7% vom globale Web-Inhalt ab (W3Techs, Juni 2026), drum erschliesst jede zweiti Sprach e neui erreichbari Zielgruppe mit fascht null Grenzköschte, sobald dis Routing und de Übersetzigs-Pipeline iigrichtet sind. Firme, wo i Lokalisierig investiered, melded 96% positive ROI, debi händ 65% mindischtens e 3-fache Ertrag erzielt (DeepL, 2024).

Fazit

E 10-sprachigi Next.js Site isch nöd 10x de Ufwand. Es isch eis [lang] dynamischs Segment, e API-Präfix-Berechnig, e Hreflang-Helfer und es Übersetzigs-Skript – multipliziert über din Publish-Pipeline. Mir händ das für Frida Marketing boue und es lauft i de Produktion i 10 Spräche ohni zuesätzliche Wartigsufwand pro Sprach und ohni Lokalisierigs-SaaS-Abo.

S'Routing isch e Morge-Arbeit. S'Hreflang isch e Namittag-Arbeit. De Übersetzigs-Pipeline isch es Wucheend-Projekt. Und de Ertrag – d'Erreichbarkeit vo de 50.3% vom Web, wo nöd änglisch isch – isch permanent.

Fang hüt mit em [lang] Segment aa. Füeg Hreflang die Wuche hinzu. Schliess d'Gemini Übersetzigs-API de Monet aa.