Next.js-Website übersetzen: crawlbare Sprachrouten und SEO

Erfahren Sie, wie Sie eine Next.js-Website mit pfadbasierten Sprach-URLs, lokalisierten Metadaten, hreflang und einem gut pflegbaren Glossar-Workflow übersetzen – ohne eine rein cookiebasierte Sprachumschaltung.

Grant DaviesAktualisiert

Next.js-Website übersetzen: ein Next.js-App-Router-Verzeichnisbaum mit einem [locale]-Knoten, der zu einer Seite führt, auf einem weißen Raster

Eine Next.js-Website zu übersetzen bedeutet mehr, als nur eine i18n-Bibliothek einzusetzen. Suchmaschinen benötigen für jede Sprachversion eine eigene, crawlbare URL, bei der Metadaten und Seiteninhalte bereits in der ersten HTML-Antwort enthalten sind. Bei cookiebasierten Sprachwechseln oder rein clientseitigen Umschaltern unter einer einzigen URL fehlen Google separate Seiten zum Indexieren.

Wenn Sie sich vor dem Einstieg in die App-Router-Segmente nur eine Regel merken möchten: Geben Sie jeder Sprache eine eigene, crawlbare URL. Google empfiehlt unterschiedliche URLs pro Sprache oder Region, statt sich allein auf Cookies oder die Browsersprache zu verlassen. Pfadpräfixe wie /en/ und /de/, eigene Subdomains oder separate Domains schaffen jeweils indexierbare Adressen. Rein cookiebasierte Umschalter unter einer einzigen URL tun das nicht.

Eine cookiebasierte Sprachauswahl kann während der Entwicklung bequem erscheinen, weil Sie keine Routen duplizieren müssen. Im SEO-Produktivbetrieb verbirgt dieses Muster die Sprachvarianten jedoch vor Crawlern. Pfadbasierte Sprachversionen bieten stabile Adressen, die Sie in Sitemaps aufführen, mit hreflang kennzeichnen und in der Search Console überwachen können. Eine ausführlichere Einordnung von Markt- und Sprachstrategien finden Sie in unserem Leitfaden zu internationaler SEO im Vergleich zu mehrsprachiger SEO.

Ein URL-Muster für Sprachen in Next.js wählen

Next.js-Teams entscheiden sich in der Regel für eines von drei crawlbaren Mustern:

  1. Unterverzeichnisse – example.com/en/docs, example.com/fr/docs. Einfach auf einem einzigen Host bereitzustellen; klare Hierarchie für hreflang.
  2. Subdomains – en.example.com, fr.example.com. Sinnvoll, wenn regionale Teams weitgehend eigenständig arbeiten; gegenseitige hreflang-Verweise sind dennoch erforderlich.
  3. ccTLDs oder eigene Domains – das stärkste geografische Signal, wenn Sie tatsächlich getrennte Webauftritte betreiben; zugleich der höchste Betriebsaufwand.

Google ermittelt die Sprache einer Seite hauptsächlich anhand der sichtbaren Inhalte. Unabhängig vom gewählten Muster sollten die Inhalte unter jeder URL überwiegend in einer Sprache gehalten sein – einschließlich Navigation, Footer-Links und Fehlerseiten. Vermeiden Sie es, innerhalb derselben Vorlage Sprachen zu mischen, wenn es dafür keinen klaren Grund aus Nutzersicht gibt.

Leiten Sie Besucher nicht automatisch anhand einer vermuteten Sprache oder eines vermuteten Standorts weiter. Google rät davon ab, weil dies Crawler blockieren und Nutzer frustrieren kann. Bieten Sie stattdessen eine sichtbare Sprachauswahl an, die auf die URL der jeweiligen Sprachversion verlinkt.

App Router und Aufbau der Sprachsegmente

Im App Router ist ein dynamisches [locale]-Segment das übliche Muster: app/[locale]/layout.tsx bildet den übergeordneten Rahmen für lokalisierte Seiten. Definieren Sie die unterstützten Sprach- und Regionsvarianten in einem zentralen Konfigurationsobjekt und validieren Sie params.locale in Layouts oder Middleware. Ungültige Sprach- und Regionsangaben sollten einen 404-Fehler auslösen, statt unter derselben URL stillschweigend auf Englisch zurückzufallen.

Middleware kann die reine /-Adresse auf ein Standard-Sprachverzeichnis wie /en/ umleiten. Die alternativen Sprachversionen müssen aber weiterhin verlinkbar bleiben. Kombinieren Sie Middleware mit generateStaticParams, wenn Sie Marketingseiten statisch generieren, damit jede Sprachversion im Voraus erstellt wird.

Cookiebasierte gegenüber pfadbasierten Sprachversionen: Eine Sprachermittlung per Cookie oder Header unter einer einzigen URL ändert den Inhalt, ohne die Adresse zu ändern. Crawler rufen eine URL in der Regel einmal ab; sie sehen daher nicht jede Sprachvariante. Pfadbasierte Sprachversionen oder entsprechende Subdomain-/Domain-Lösungen entsprechen Googles Empfehlung für unterschiedliche URLs. Cookies dürfen weiterhin die Nutzereinstellung speichern, nachdem eine Sprache gewählt wurde, solange die öffentlichen URLs voneinander getrennt bleiben.

Verwenden Sie next-intl, next-i18next oder ähnliche Bibliotheken zum Laden von Übersetzungstexten. Die öffentlichen URLs sollten jedoch durch das Routing bestimmt werden – nicht allein durch Cookies.

Metadaten, Open Graph und strukturierte Daten lokalisieren

Jede Sprachroute benötigt ein eigenes <title>, eine eigene Meta-Beschreibung, eine Canonical-URL und Open-Graph-Tags im serverseitig gerenderten HTML. Verwenden Sie im App Router generateMetadata für jede Seite und lesen Sie die übersetzten Texte aus Ihren Übersetzungsdateien aus. Lokalisierte Titel und Meta-Beschreibungen dürfen nicht von einem clientseitigen Sprachwechsel nach der Hydration abhängen.

Gehen Sie bei JSON-LD genauso konsequent vor: Die Blöcke WebPage, Organization und FAQ sollten übersetzte Texte und zur jeweiligen Sprach- und Regionsversion passende inLanguage-Werte verwenden. Wenn Sie hreflang-Link-Elemente ausgeben, generieren Sie im Layout oder in der Hilfsfunktion für Seitenmetadaten den vollständigen Satz gegenseitiger Verweise – fehlende Rückverweise machen hreflang-Cluster ungültig.

Hreflang, Canonicals und Sitemaps für Next.js

Hreflang informiert Google über alternative Sprach- oder Regions-URLs. Jede URL in einem Cluster muss mit passenden Codes auf alle anderen Mitglieder und auf sich selbst verweisen. Implementieren Sie hreflang in <head>, in HTTP-Headern oder über xhtml:link-Einträge in XML-Sitemaps – wählen Sie pro Website eine einheitliche Methode.

Jede Sprach-URL benötigt außerdem einen Canonical-Verweis auf die bevorzugte URL dieser Sprache, wenn Duplikate vorhanden sind, etwa durch Tracking-Parameter oder Druckansichten. Verweisen Sie mit dem Canonical einer französischen Seite nicht auf deren englisches Pendant; Canonicals führen Duplikate innerhalb derselben Sprache zusammen.

Generieren Sie Sitemaps pro Sprachversion oder einen Sitemap-Index, der alle Sprach-URLs auflistet. Sitemaps erleichtern das Auffinden von Seiten und können hreflang-Annotationen enthalten. Prüfen Sie nach der Bereitstellung stichprobenartig URLs mit der URL-Prüfung in der Search Console und einem Workflow zum Testen von hreflang. Unser Überblick zur Plattform für mehrsprachige SEO erklärt, wie SEO-Teams diese Signale über verschiedene Sprach- und Regionsversionen hinweg prüfen.

Rein clientseitigen Sprachaustausch vermeiden

Ein häufiger Fallstrick in Next.js besteht darin, zunächst ein englisches HTML-Grundgerüst zu rendern und anschließend die Texte in useEffect auszutauschen. Crawler führen diesen Austausch möglicherweise nicht zuverlässig aus; Nutzer sehen kurzzeitig die falsche Sprache. Server Components, statische Generierung oder SSR sollten die übersetzten Inhalte bereits in der ersten Antwort rendern. Client Components können interaktive Elemente hydrieren, doch Marketingtexte und Überschriften gehören in den serverseitigen Komponentenbaum.

Pfad- oder subdomainbasierte Sprachrouten schaffen eigenständige, crawlbare URLs; rein cookiebasierte Sprachumschalter erfüllen Googles Empfehlung nicht. Wenn Sie für die Vorschau einen Übersetzungsproxy verwenden, stellen Sie sicher, dass die Produktivumgebung weiterhin vollständiges HTML für jede Sprach-URL ausliefert.

Content-Workflow: Glossar, TM und Prüfung

Technische Lösungen verfehlen im Zielmarkt ihre Wirkung, wenn Übersetzungen von der Produktterminologie abweichen. Ergänzen Sie die i18n-Dateien von Next.js durch ein Glossar, einen Übersetzungsspeicher (Translation Memory, TM) und eine menschliche Prüfung. Googles Leitlinien zu hilfreichen Inhalten stellen Seiten für Menschen in den Mittelpunkt; Sprachversionen mit wenig Substanz oder ausschließlich Standardtexten sind sowohl für SEO als auch als Antwortquellen schwach.

Workflow im Überblick:

  • Extrahieren Sie Texte aus JSON- oder PO-Dateien und überführen Sie sie in einen Workflow, der mit CAT-Tools kompatibel ist.
  • Stellen Sie die Einhaltung der Glossarbegriffe für Produktnamen und UI-Beschriftungen sicher.
  • Führen Sie die sprachliche Qualitätssicherung anhand von Staging-URLs durch, statt nur Quelldateien zu vergleichen.
  • Synchronisieren Sie die Übersetzungen erneut, wenn sich die englische Quelle ändert; veraltete Sprachversionen untergraben das Vertrauen.

Checkliste für die Implementierung

Prüfen Sie vor dem Launch die Crawling-Pfade, Metadaten und Annotationen:

Auch die Bing-Webmasterrichtlinien betonen die Bedeutung crawlbarer, nützlicher Inhalte und einer klaren Struktur – Maßnahmen, die Google helfen, unterstützen in der Regel auch die Indexierung durch Bing.

Häufige Fehler

Sprach- und Regionsauswahl nur per Cookie unter einer einzigen URL – verbirgt Varianten vor Crawlern.

Fehlende hreflang-Rückverweise – unterbrechen die wechselseitige Verknüpfung und erschweren die Gruppierung zusammengehöriger Seiten.

Canonical-Verweis auf die englische Version bei übersetzten Seiten – sendet das falsche Signal zur Zusammenführung der Seiten.

Metadaten nur auf der Clientseite – Titel und Beschreibungen fehlen im initialen HTML.

Automatische Weiterleitung anhand von IP-Adresse oder Accept-Language – blockiert Crawler und ignoriert die Auswahl der Nutzer.

Nicht übersetzte Bedienelemente – eine gemischtsprachige Navigation erschwert die Spracherkennung.

Oberflächliche maschinelle Übersetzung ohne Prüfung – erfüllt die Anforderungen an hilfreiche Inhalte nicht.

Grundlagen für klassische Suche und Antwortmaschinen

Die gemeinsamen Grundlagen für sprach- und regionsspezifische Next.js-Routen und serverseitig gerendertes HTML sind für Google, Bing und KI-Antwortsysteme gleichermaßen wichtig: crawlbare Sprachversionen, klar definierte Entitäten, belegte Aussagen, strukturierte Daten, die den Tatsachen entsprechen, und echte Lokalisierung statt rein englischsprachiger Seitengerüste. Die folgenden Leitfäden beleuchten dieselben Anforderungen an die mehrsprachige Bereitstellung aus plattformspezifischer Sicht.

Damit die Google-Suche Inhalte finden kann, braucht sie crawlbare URLs für die jeweiligen Sprach- und Marktversionen mit sprachlich passendem HTML, korrekten Seitentiteln und Überschriften sowie gegenseitigen Hreflang-Verweisen, sofern alternative Versionen existieren. Zu den technischen Grundlagen gehören indexierbare Inhalte statt rein Cookie-basierter Sprachumschalter, lokalisierte Metadaten, Sitemaps und ein konsequenter Einsatz von Canonical-Tags. Inhaltliche Qualität bedeutet, in jeder Sprache Hauptinhalte bereitzustellen, die den Menschen in den Mittelpunkt stellen. Autorität entsteht durch eine klar erkennbare Organisationsidentität und bestätigende Quellen – nicht durch Marketing für Übersetzungstools. Für mehrsprachige Websites heißt das: Jede markt- oder sprachspezifische URL muss für sich bestehen können. Zur Erfolgskontrolle dienen die Indexabdeckung in der Search Console und die URL-Prüfung je Sprach- oder Marktversion. Gesichert und ungewiss: Google dokumentiert den Umgang mit Mehrsprachigkeit und Hreflang, garantiert aber keine Rankings durch ein bestimmtes CMS oder einen MTPE-Workflow.

Plattform-Leitfaden: Bing

Bing findet und indexiert crawlbare mehrsprachige Seiten mit klarer Struktur. Die Anforderungen an eindeutige URLs und verständliche Inhalte ähneln denen von Google. Zu den technischen Grundlagen gehören abrufbare URLs für die jeweiligen Sprach- und Regionalversionen, nützliche Inhalte und die Überwachung mit Bing Webmaster Tools. Lokalisieren Sie Überschriften, Aussagen und FAQs, statt nur die Benutzeroberfläche zu übersetzen. Autoritätssignale hängen auch hier von vertrauenswürdigen Quellen und konsistent dargestellten Entitäten ab. Für mehrsprachige Websites heißt das: Verbergen Sie Sprachversionen nicht hinter einer rein clientseitigen Umschaltung. Messen Sie die Indexierung und Crawl-Statistiken in Bing Webmaster Tools. Gesichert und ungewiss: Die Bing-Richtlinien betonen crawlbare, nützliche Inhalte. Erfinden Sie keine Bing-spezifischen Rankingfaktoren für Übersetzungstools.

Plattform-Leitfaden: ChatGPT

ChatGPT kann öffentlich zugängliche Seiten zitieren oder zusammenfassen, wenn die Sprachversionen eindeutig sind und die Inhalte sich unmittelbar für Antworten eignen. Die Auffindbarkeit folgt keinem herkömmlichen, crawlbasierten Ranking; Sichtbarkeit zeigt sich darin, dass eine Seite als Quelle ausgewählt oder in Antworten referenziert wird. Die technische Grundlage bilden weiterhin zugängliche HTML-URLs – keine Widget-Overlays, die Texte verbergen. Hilfreich sind direkte Antworten, FAQs und eine durch Glossare vereinheitlichte Terminologie. Autorität entsteht durch Belege und konsistente Entitäten über alle Sprach- und Marktversionen hinweg. Für mehrsprachige Websites heißt das: Jede lokalisierte Seite sollte für sich verständlich sein. Die Messbarkeit ist begrenzt – Prüfungen auf Quellenverweise sollten als Hypothesentests betrachtet werden. Gesichert und ungewiss: Es gibt keine dokumentierte Garantie dafür, dass MTPE oder eine bestimmte CMS-Integration zu Quellenverweisen in ChatGPT führt.

Plattform-Leitfaden: Gemini

Für Gemini und verwandte KI-Angebote von Google sind konsistent dargestellte Entitäten, sachlich korrekte strukturierte Daten und indexierbare lokalisierte Seiten hilfreich. Bei Sichtbarkeit geht es darum, als Quelle herangezogen oder erkannt zu werden – nicht darum, Rankingfaktoren für Gemini zu erfinden. Die technischen Grundlagen überschneiden sich mit denen der Google Suche: Crawlbarkeit und hochwertige Metadaten. Inhalte sollten in jeder Sprache klare Aussagen und Definitionen liefern. Autorität hängt von einer konsistenten Darstellung der Organisation und bestätigenden Quellen ab. Für mehrsprachige Websites heißt das: Durch Glossare vereinheitlichte Produktnamen reduzieren Verwechslungen zwischen Sprach- und Regionalversionen. Nutzen Sie für die klassische Messung die Search Console und prüfen Sie ergänzend Stichproben von KI-Antworten qualitativ. Gesichert und ungewiss: Das Verhalten von Gemini ersetzt nicht die dokumentierten Empfehlungen der Google Suche zu hreflang und Sprachversionen.

Plattform-Leitfaden: Google AI Overviews

Google AI Overviews können auf Seiten verlinken, die ihre Aussagen stützen. Die Grundlage für eine mögliche Berücksichtigung bilden weiterhin indexierbare Inhalte, die Menschen in den Mittelpunkt stellen. Sie sind keine Sprachumschaltung und ersetzen hreflang nicht. Zu den technischen Grundlagen gehören weiterhin crawlbare HTML-Seiten für jede Sprach- und Regionalversion sowie wahrheitsgemäße strukturierte Daten. Wichtige inhaltliche Merkmale sind prägnante Antworten und klare Überschriften in jeder Sprache. Die Autoritätssignale entsprechen den Erwartungen an hilfreiche Inhalte. Für mehrsprachige Websites heißt das: Für keine übersetzte Seite ist die Aufnahme in AI Overviews garantiert. Nutzen Sie, sofern verfügbar, Berichte zu generativen Suchfunktionen in der Search Console und erfassen Sie klassische Indexierungskennzahlen separat. Gesichert und ungewiss: Kein Übersetzungsworkflow kann eine Platzierung in AI Overviews versprechen.

Wie GlotEO unterstützt

Eine selbst entwickelte i18n-Lösung für Next.js funktioniert bei kleinen Websites. Mit wachsendem Umfang werden Glossarverwaltung, Prüfwarteschlangen und SEO-Validierung über alle Sprach- und Regionsversionen hinweg nötig. GlotEO lässt sich in moderne Technologie-Stacks integrieren, sodass Marketingteams Übersetzungen verwalten können, während Entwickler die App-Router-Struktur beibehalten.

Teams, die Lokalisierung als Aufgabe für Routing und Inhaltsqualität verstehen – nicht nur als Austausch von Zeichenfolgen –, setzen Verbesserungen schneller um, ohne Crawling-Pfade zu unterbrechen. Stellen Sie ein Glossar bereit, bevor die Übersetzung beginnt, prüfen Sie Seiten im Kontext der Staging-Umgebung und kontrollieren Sie hreflang erneut, sobald Sie Routen hinzufügen. Messen Sie die Indexierung in der Search Console für jedes Sprach- und Regionsverzeichnis oder jede Subdomain einzeln, statt sich auf einen Gesamtwert für die Website zu verlassen.

Entdecken Sie die Plattform zur Website-Lokalisierung unter Website-Lokalisierung mit GlotEO und vergleichen Sie Preise und Tarife von GlotEO, wenn Sie den Umfang der Einführung planen.

Quellen