Open for new projects · sublimearts.io
← Blog
Web Design28. Mai 2026·8 Min. Lesezeit

Warum ich für jeden Auftrag standardmäßig native mehrsprachige Next.js-Routen (IT/EN/ES) entwerfe.

Die Planung internationaler SEO-Routen in Next.js/Astro verhindert Rendering-Verzögerungen und beseitigt die Schwächen, die bei langsamen automatischen Übersetzern auftreten. Das ist exakt die Architektur, die diese Website gerade jetzt in 9 Sprachen betreibt.

Gefällt's dir? Am Ende wartet ein ❤️ auf dich.

Warum Mehrsprachigkeit wichtiger ist, als es aussieht

Ein lokales Unternehmen denkt in einer Sprache. Ein Unternehmen, das internationale Kunden will — Tourismus, Gastgewerbe, professionelle Dienstleistungen, E-Commerce — braucht eine Website, die nativ in den Sprachen existiert, in denen seine tatsächlichen Kunden suchen. Nicht als nachträglicher Anbau. Jeder Kunde, für den ich baue und der über sein Heimatland hinaus Reichweite will, bekommt von Anfang an mehrsprachiges Routing, denn es später auf eine einsprachige Seite nachzurüsten bedeutet, Metadaten, URL-Struktur und oft die Content-Strategie komplett neu zu machen.

Warum die beiden naheliegenden Abkürzungen scheitern

Es gibt zwei Abkürzungen, zu denen alle zuerst greifen, und beide scheitern bei echtem SEO. Die erste ist ein schwebendes Übersetzungs-Widget (Google-Translate-Einbettung o. Ä.): Es läuft clientseitig, nachdem die Seite bereits in der Originalsprache geladen wurde, sodass Suchmaschinen den Originaltext indexieren — deine spanischen Besucher, die auf Spanisch suchen, finden nie eine Seite, die für Google spanisch ist. Die zweite ist eine einzelne URL mit Query-Parameter, etwa ?lang=es. Suchmaschinen behandeln Query-Parameter-Varianten nicht zuverlässig als separate, eigenständig rankbare Seiten — oft werden sie als Duplicate Content derselben URL gewertet, sodass dein spanischer Inhalt mit deinem englischen konkurriert, statt eigenständig für spanische Suchen zu ranken.

Die Lösung: echte Routen, eine pro Sprache

Jede Sprache bekommt ihren eigenen crawlbaren Pfad — /it/, /en/, /es/ —, jeweils serverseitig gerendert mit vollständig übersetztem Inhalt, eigenem <html lang>-Attribut und eigenen Metadaten. In Next.js liefert next-intl mit localePrefix auf „always“ genau das out of the box: Statt einer Seite, die Text per JavaScript austauscht, erhältst du wirklich getrennte Seiten, die Suchmaschinen crawlen, indexieren und eigenständig ranken können — jede davon eine echte, vollständige Seite in dieser Sprache, keine übersetzte Oberfläche über demselben Inhalt.

So ist das auf dieser Website tatsächlich verdrahtet

1Definiere die unterstützten Locales und setze localePrefix: „always“ in der next-intl-Routing-Konfiguration, damit jede URL — auch die der Standardsprache — ein explizites /it/, /en/, /es/-Präfix trägt, ohne mehrdeutige Root-Route
2Lege übersetzte Strings in einer JSON-Datei pro Sprache ab (messages/en.json, messages/it.json usw.), damit jeder UI-String und jeder Seitentext pro Locale ein Zuhause hat und nicht über Komponenten verstreut ist
3Setze in generateMetadata() alternates.canonical auf die URL der aktuellen Locale und alternates.languages auf eine vollständige Map der entsprechenden URL jeder Locale — damit werden die hreflang-Tags ausgegeben, mit denen Suchmaschinen die Sprachvarianten derselben Seite verknüpfen
4Setze openGraph.locale und ein passendes og:image pro Seite, damit geteilte Links korrekt angezeigt werden, egal welche Sprachvariante geteilt wird
5Übersetze niemals maschinell zur Anfragezeit. Einmal übersetzen, speichern, pro Locale statisch ausliefern — das hält die Time to First Byte niedrig und bedeutet, dass keine Übersetzungs-API im kritischen Rendering-Pfad liegt

Was dir das tatsächlich bringt

Jede Sprachvariante rankt für sich — eine italienische Suche liefert die italienische Seite, eine spanische Suche die spanische Seite, und keine konkurriert mit der anderen oder verwässert sie in Googles Augen. Für die Conversion ebenso wichtig: Besucher landen auf einer Seite, die sich anfühlt, als wäre sie wirklich in ihrer Sprache geschrieben, nicht auf einer mit sichtbarem Übersetzungs-Widget in der Ecke. Für ein Restaurant, ein Hotel oder einen Dienstleister, der auf ein internationales Publikum glaubwürdig wirken will, ist dieser Unterschied oft der zwischen einem Absprung und einem Kunden.

Möchtest du diese Architektur auf deiner Website laufen haben?

Lass uns sprechen →

About

Patrick Chen — unabhängiger Entwickler und Webdesigner hinter Sublimearts.io. Genau dieses Routing-Setup — next-intl, localePrefix always, Metadaten pro Sprache — rendert die Seite, die du gerade liest, in genau der der 9 Sprachen, in der du sie gerade ansiehst.

Did you find this helpful?