So erstellen Sie eine 10-sprachige Next.js-Website (App Router Leitfaden 2026)

Der Aufbau einer mehrsprachigen Website ist eine der wirkungsvollsten Investitionen, die Sie in SEO und Konversion tätigen können. Sechsundsiebzig Prozent der Online-Käufer bevorzugen den Kauf von Produkten mit Informationen in ihrer Muttersprache (CSA Research, 2020), doch weniger als 5 % der aktiven Websites unterstützen mehr als drei Sprachen. Wir haben kürzlich Frida Marketing in 10 Sprachen auf dem Next.js 15 App Router ausgeliefert – ohne next-intl, ohne eine Übersetzungs-SaaS und ohne 10 separate Codebasen. Hier ist, wie wir es genau gebaut haben.

Wichtige Erkenntnisse

• 76 % der Käufer bevorzugen den Kauf in ihrer Muttersprache; 40 % werden niemals auf Websites kaufen, die dies nicht anbieten (CSA Research, 2020)
• Englisch deckt nur 49,7 % des globalen Webinhalts ab – der Aufbau von Mehrsprachigkeit erschließt die restlichen 50,3 % (W3Techs, Juni 2026)
• Ein dynamisches [lang]-Segment + eine API-Präfix-Berechnung bedient 10 Sprachen aus einem einzigen Satz von Seitendateien
• Gemini 2.5 Flash übersetzt einen vollständigen 3.000-Wörter-HTML-Beitrag pro Sprache in weniger als 90 Sekunden zu nahezu null Kosten

Warum der Aufbau von Mehrsprachigkeit günstiger ist, als Sie denken

Das Kostenargument gegen mehrsprachige Websites wird fast immer überbewertet. Der Next.js 15 App Router verwaltet die gesamte Routing-Schicht über ein einziges dynamisches Segment. Die Inhaltsebene – Titel, Text, Metadaten – kommt von Ihrer API pro Sprache. Und die Übersetzungsebene kann vollständig automatisiert werden.

Englisch repräsentiert 49,7 % aller Website-Inhalte nach Sprache. Spanisch und Deutsch halten jeweils 6,0 %, Japanisch 5,0 % und Französisch 4,6 % (W3Techs, Juni 2026). Die Unterstützung der fünf wichtigsten nicht-englischen Sprachen allein deckt grob 70 % der indizierten globalen Webinhalte ab. Next.js läuft auf 2,7 % aller Websites weltweit und 17,9 % der befragten Entwickler nutzen es (Stack Overflow Developer Survey, 2024) – was bedeutet, dass die Tools und der Community-Support für mehrsprachiges Next.js so gut sind wie nie zuvor.

Die wahren Kosten sind nicht Code – es ist Inhalt. Sobald Ihr Routing eingerichtet ist, ist das Hinzufügen einer Sprache ein API-Aufruf pro veröffentlichtem Beitrag. Wir haben 7 Beiträge in 10 Sprachen veröffentlicht, ohne sprachspezifischen Wartungsaufwand. Die Architektur-Entscheidung ist die Investition; die Laufzeit ist kostenlos.

96 % der Unternehmen, die in Lokalisierung investierten, meldeten einen positiven ROI, wobei 65 % mindestens eine 3-fache Rendite erzielten (DeepL Business Survey, 2024). Der Business Case ist solide. Die technische Hürde ist weitaus geringer, als die meisten Entwickler erwarten.

So strukturieren Sie Ihr dynamisches [lang]-Segment

Der Next.js App Router verwandelt Ihr Dateisystem in Ihren Router. Erstellen Sie ein Verzeichnis src/app/[lang]/ und jede darin enthaltene Route erhält automatisch params.lang. Dieser eine Parameter ist die gesamte Grundlage einer 10-sprachigen Website.

`` src/app/ ├── page.tsx ← Englische Startseite (/) ├── blog/[slug]/page.tsx ← Englische Blogbeiträge ├── admin/layout.tsx ← Englische Administration └── [lang]/ ├── page.tsx ← Startseiten aller anderen Sprachen (/fi, /fr, /de…) ├── blog/[slug]/page.tsx ← Sprach-Blogbeiträge └── admin/ └── layout.tsx ← Sprach-Administration (gleiche Datei, liest params.lang) ``

Englisch befindet sich im Stammverzeichnis. Jede andere Sprache befindet sich unter [lang]. Sie schreiben eine Datei und lassen params.lang die Logik steuern – niemals sprachspezifische Seitenkopien.

Definieren Sie Ihre Sprachkonfiguration in einer kanonischen Datei:

```typescript // src/lib/languages.ts export const LANGUAGES = [ { code: 'fi', urlPrefix: 'fi', apiPrefix: 'fi_', name: 'Finnisch' }, { code: 'fr', urlPrefix: 'fr', apiPrefix: 'fr_', name: 'Französisch' }, { code: 'de', urlPrefix: 'de', apiPrefix: 'de_', name: 'Deutsch' }, { code: 'it', urlPrefix: 'it', apiPrefix: 'it_', name: 'Italienisch' }, { code: 'no', urlPrefix: 'no', apiPrefix: 'no_', name: 'Norwegisch' }, { code: 'ch', urlPrefix: 'ch', apiPrefix: 'pt_', name: 'Schweizerdeutsch' }, // ⚠️ API verwendet pt_ { code: 'sr', urlPrefix: 'sr', apiPrefix: 'sr_', name: 'Serbisch' }, { code: 'es', urlPrefix: 'es', apiPrefix: 'es_', name: 'Spanisch' }, { code: 'sw', urlPrefix: 'sv', apiPrefix: 'sw_', name: 'Schwedisch' }, // ⚠️ URL verwendet sv ];

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

Zwei Besonderheiten, die sofort dokumentiert werden müssen: ch (Schweizerdeutsch) verwendet pt_ als API-Präfix aus historischen Benennungsgründen, und sw (Schwedisch) verwendet sv als URL-Präfix, um dem ISO-Standard zu entsprechen. Diese Diskrepanzen verursachen keine Fehler, wenn Sie die Konfiguration zentralisieren, aber sie werden jeden Entwickler verwirren, der dem Projekt ohne diese Dokumentation beitritt.

Sprachrouten mit Ihrer Backend-API verbinden

Die gesamte mehrsprachige API-Integration ist eine Berechnung:

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

Wenn params.lang `'fi'` ist, wird `/api/fi_posts` abgerufen. Wenn es undefined ist (englische Wurzel), wird `/api/posts` abgerufen. Jede Seite, jeder Datenaufruf, jede Admin-Operation verwendet dasselbe Muster. Es gibt keinen sprachspezifischen Fetch-Helfer, keine Switch-Anweisung, keinen Sonderfall.

Wir verwenden dieses Muster in der Produktion für 10 Sprachen und 5 Inhaltstypen – Beiträge, Produkte, Seiten, Autoren und Kategorien. Der einzige Grenzfall, auf den wir gestoßen sind: Einige API-Endpunkte haben unterschiedliche Strukturen für Englisch im Vergleich zu den sprachspezifischen Versionen. In unserem Setup existiert `/api/{lang}_posts/by-url/{slug}` für jede Sprache, aber das englische Äquivalent ist ein völlig anderer Controller (`/api/resolve-route?url=...`). Überprüfen Sie Ihre englischen API-Routen immer separat – sie sind oft anders strukturiert als die sprachspezifischen, insbesondere bei Laravel-Backends, wo die englischen Routen zuerst erstellt wurden.

Das Admin-Panel verwendet dasselbe 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}_ : ''; // Abrufen von /api/${prefix}posts // Bearbeitungs-/Löschlinks erstellen mit /${params.lang}/admin/edit-post/${id} } ``

Eine einzige AdminPostsPage-Komponente bedient alle 10 Sprach-Admin-Panels. Die englische Administration befindet sich unter /admin/posts; die finnische unter /fi/admin/posts. Gleiche Datei.

Statische Seiten für alle 10 Sprachen generieren

Die statische Generierung ist der Punkt, an dem mehrsprachige Next.js-Sites ihren Leistungsvorteil erhalten. Verwenden Sie generateStaticParams, um jede Sprachvariante zur Build-Zeit vorab zu rendern:

```typescript // src/app/[lang]/page.tsx — statische Sprach-Startseiten export async function generateStaticParams() { return LANG_CODES.map(lang => ({ lang })); // Gibt zurück: [{lang:'fi'},{lang:'fr'},{lang:'de'},...] }

// src/app/[lang]/blog/[slug]/page.tsx — statische Blogbeiträge pro Sprache 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 })); } ```

Statische Seiten erscheinen als ● in der next build-Ausgabe. Sie werden zur Bereitstellungszeit in HTML vorab gerendert, an Vercels Edge-CDN übertragen und laden weltweit in Millisekunden. Für eine 10-sprachige Website ist dies der Unterschied zwischen einer 50ms TTFB und einem 800ms Origin-Hit bei jeder Anfrage.

Eine Regel zum Merken: Kombinieren Sie niemals generateStaticParams mit `{ cache: 'no-store' }`-Abrufen auf derselben Seite. In Next.js 15 Produktions-Builds wird dies den Fehler `Error: Page changed from static to dynamic at runtime` auslösen – ein Fehler, der nur in der Produktion, nicht in der Entwicklung auftritt. Verwenden Sie stattdessen ISR:

``typescript const res = await fetch(${API_URL}/api/${prefix}posts, { next: { revalidate: 3600 }, // Veraltete Seiten stündlich neu generieren }); export const dynamicParams = true; // Neue Slugs ohne vollständigen Neuaufbau zulassen ``

next-intl verzeichnet im Juni 2026 2,3 Millionen wöchentliche npm-Downloads und ist damit die dominierende Bibliothek in diesem Bereich. Es ist die richtige Wahl, wenn Sie eine locale-sensitive Formatierung oder die Verwaltung von fest codierten UI-Strings benötigen. Für datengesteuerte CMS-Sites ist es optional – reines App Router-Routing erledigt alles, was Sie tatsächlich benötigen.

SEO für eine 10-sprachige Website: Hreflang und generateMetadata

Hreflang teilt Google mit, welche Sprachversion welchem Publikum bereitgestellt werden soll. Ohne sie konkurrieren Ihre 10 Sprachseiten um dieselben Suchanfragen. Die App Router-Implementierung ist sauber:

```typescript // src/lib/hreflang.ts const HREFLANG_CODE: Record = { fi: 'fi', fr: 'fr', de: 'de', it: 'it', no: 'no', ch: 'de-CH', // Schweizerdeutscher interner Code → BCP 47 de-CH sr: 'sr', es: 'es', sw: 'sv', // Interner Code sw → ISO sv (Schwedisch) };

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, }; } ```

Verwenden Sie es in generateMetadata auf jeder Seite:

``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), }; } ``

Dies generiert einen vollständigen Hreflang-Satz für jede Seite – x-default, en und alle 9 Sprachvarianten – ohne manuellen Wartungsaufwand. Keine XML-Sitemap-Hreflang-Blöcke, die synchron gehalten werden müssen; Next.js fügt sie als -Tags in den gerenderten ein.

Laut mehrsprachiger SEO-Forschung verzeichnen Unternehmen, die in Lokalisierung investieren, 300–500 % mehr organischen Traffic aus internationalen Märkten (MotionPoint, 2025). Die Hreflang-Schicht ist das, was diesen Traffic erfasst. Ohne sie ignoriert Google entweder die Sprachsignale oder zeigt die falsche Version für jedes Gebiet an.

Übersetzung automatisieren: Gemini API in Ihrer Veröffentlichungs-Pipeline

Manuelle Übersetzung in 10 Sprachen ist das falsche Modell für jedes Team ohne dediziertes Lokalisierungsbudget. Menschliche Übersetzung kostet 0,15–0,30 $ pro Wort – ein 2.500-Wörter-Beitrag kostet 375–750 $ pro Sprache, oder 3.375–6.750 $ für alle 9 (Seatongue, 2025). Die Nachbearbeitung maschineller Übersetzungen reduziert dies um 50–70 %. Aber für strukturierte HTML-Inhalte aus einem CMS ist eine vollständig automatisierte API-Übersetzung mit einem präzisen Prompt noch besser.

Hier ist der zentrale Übersetzungsaufruf, den wir mit Gemini 2.5 Flash verwenden:

``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()); } ```

Wir haben dies in der Produktion für 7 veröffentlichte Beiträge eingesetzt, die jeweils automatisch in 9 Sprachen übersetzt wurden. Die Qualität ist für Finnisch, Französisch, Deutsch, Spanisch und Italienisch ohne manuelle Überprüfung publikationsreif. Norwegisch und Schwedisch benötigen gelegentliche Stichproben. Serbisch benötigt einen Korrekturleser – Gemini ist weniger zuverlässig mit Kyrillisch in komplexen HTML-Kontexten. Für eine inhaltsreiche Website reduziert dieser Ansatz den Übersetzungsaufwand um über 90 % im Vergleich zu Workflows mit Nachbearbeitung maschineller Übersetzungen.

Timing ist wichtig. Ein 3.000-Wörter-HTML-Beitrag benötigt mit Gemini 2.5 Flash etwa 60–90 Sekunden pro Sprache. Das sind 9–13 Minuten für alle 9 Übersetzungen. Setzen Sie immer ein Abbruch-Timeout von 150 Sekunden für jeden API-Aufruf und implementieren Sie exponentielles Backoff – das Modell hängt gelegentlich bei hoher Nachfrage:

``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') { // Wiederholen mit exponentiellem Backoff await new Promise(r => setTimeout(r, Math.pow(2, attempt) * 5000)); } } ``

84 % der Vermarkter geben an, dass die Inhaltslokalisierung zur Steigerung ihres Umsatzes beigetragen hat, und Unternehmen, die in Übersetzung investierten, hatten eine 1,5-fach höhere Wahrscheinlichkeit, einen Umsatzanstieg zu verzeichnen (Redokun, 2025). Die Automatisierung beseitigt den letzten echten Blocker – die Betriebskosten für die Durchführung von Übersetzungen in großem Maßstab.

---

Eine mehrsprachige Next.js-Website erstellen? Wir entwerfen und entwickeln Next.js-Websites für ein globales Publikum – inklusive vollständigem i18n-Routing, hreflang-SEO und automatisierten Übersetzungs-Pipelines. Unsere Next.js-Entwicklungsdienstleistungen ansehen oder kontaktieren Sie uns, um Ihr Projekt zu besprechen.

---

Häufig gestellte Fragen

Benötige ich next-intl, um eine mehrsprachige Next.js-Website zu erstellen?

Nein. Der Next.js 15 App Router verwaltet mehrsprachiges Routing nativ über ein dynamisches [lang]-Segment. Bibliotheken wie next-intl bieten Mehrwert für locale-sensitive Formatierung (Datumsangaben, Währungen, Pluralisierung) und die Verwaltung von fest codierten UI-Strings. Wenn Ihre Inhalte von einem CMS oder einer API stammen, benötigen Sie diese nicht für Routing, statische Generierung oder SEO.

Wie ordne ich URL-Sprachpräfixe API-Endpunkten in Next.js zu?

Berechnen Sie ein Präfix zur Laufzeit: const prefix = params.lang ? \`${params.lang}_\` : '';. Verwenden Sie es in jedem Fetch-Aufruf – zum Beispiel, /api/${prefix}posts. Dieses Muster verarbeitet alle 10 Sprachen aus einer gemeinsamen Seitendatei. Keine sprachspezifischen Seiten, keine Switch-Anweisungen, keine Sonderfälle.

Was ist der beste Weg, eine Next.js-Website automatisch in mehrere Sprachen zu übersetzen?

Verwenden Sie Gemini 2.5 Flash oder GPT-4 in Ihrer Veröffentlichungs-Pipeline. Senden Sie den englischen Inhalt als JSON mit einem System-Prompt, um alle Textwerte zu übersetzen, während HTML-Tags beibehalten und ein lokalisierter URL-Slug generiert wird. Fügen Sie ein 150-Sekunden-Timeout und exponentielles Backoff hinzu. Die Nachbearbeitung maschineller Übersetzungen kostet 50–70 % weniger als eine vollständige menschliche Übersetzung (Seatongue, 2025), und die vollständige API-Automatisierung reduziert dies weiter.

Wie füge ich hreflang-Tags zu einer Next.js 15 App Router-Website hinzu?

Erstellen Sie eine Funktion getAlternates(routeKey, lang), die ein Next.js alternates-Objekt zurückgibt. Ordnen Sie interne URL-Codes BCP 47-Sprachcodes zu – sw → sv für Schwedisch, ch → de-CH für Schweizerdeutsch – und fügen Sie x-default hinzu, das auf die englische kanonische URL verweist. Geben Sie es von alternates.languages innerhalb des generateMetadata-Exports jeder Seite zurück.

Wie viele Sprachen sollte meine Website unterstützen?

Beginnen Sie mit 2–3, die Ihren wichtigsten Traffic-Quellen entsprechen, und erweitern Sie dann. Englisch deckt nur 49,7 % des globalen Webinhalts ab (W3Techs, Juni 2026), daher erschließt jede zweite Sprache ein neues adressierbares Publikum mit nahezu null Grenzkosten, sobald Ihre Routing- und Übersetzungs-Pipeline eingerichtet ist. Unternehmen, die in Lokalisierung investieren, melden einen positiven ROI von 96 %, wobei 65 % mindestens eine 3-fache Rendite erzielen (DeepL, 2024).

Fazit

Eine 10-sprachige Next.js-Website ist nicht der 10-fache Aufwand. Es ist ein dynamisches [lang]-Segment, eine API-Präfix-Berechnung, ein Hreflang-Helfer und ein Übersetzungsskript – multipliziert über Ihre Veröffentlichungs-Pipeline. Wir haben dies für Frida Marketing entwickelt und es läuft in Produktion in 10 Sprachen ohne sprachspezifischen Wartungsaufwand und ohne Lokalisierungs-SaaS-Abonnement.

Das Routing ist die Arbeit eines Vormittags. Das Hreflang ist die Arbeit eines Nachmittags. Die Übersetzungs-Pipeline ist ein Wochenendprojekt. Und der Ertrag – das Erreichen der 50,3 % des Webs, die nicht Englisch sind – ist dauerhaft.

Beginnen Sie noch heute mit dem [lang]-Segment. Fügen Sie diese Woche hreflang hinzu. Verbinden Sie diesen Monat die Gemini-Übersetzungs-API.