Mehrsprachige SEO in Next.js: hreflang, Sitemaps und Locale-Fallbacks
Ein praxisnahes Setup für hreflang-Alternativen, x-default, lokalisierte Sitemaps, übersetzte Slugs und Locale-Fallback-Ketten in einer mehrsprachigen Next.js-Website.
View as MarkdownIhre Inhalte zu übersetzen, ist nur die halbe Miete für mehrsprachige SEO. Die andere Hälfte besteht darin, Suchmaschinen mitzuteilen, was Sie getan haben: welche URL welche Sprache bedient, welche die Standard-URL ist und was ausgespielt wird, wenn es für eine Region noch keine Übersetzung gibt. Machen Sie hier Fehler, indexiert Google Ihre französischen Seiten für englische Suchanfragen oder betrachtet zehn Übersetzungen als Duplicate Content.
Hier ist die Checkliste, die wir umsetzen, und wie Scribe den Großteil davon aus bereits bekannten Inhalten generiert.
hreflang-Alternativen auf jeder Seite
Jede lokalisierte Seite sollte jedes Geschwisterchen deklarieren, einschließlich sich selbst, plus ein x-default, das auf die Version für nicht zugeordnete Sprachen verweist. In Next.js ist dies das Feld alternates.languages der Seiten-Metadaten.
Der lästige Teil sind übersetzte Slugs. Wenn aus /docs/getting-started auf Französisch /fr/docs/premiers-pas wird, müssen Ihre alternativen Links den lokalisierten Slug verwenden und nicht den englischen mit einem Sprachpräfix. Scribe speichert den übersetzten Slug mit jeder Übersetzung, und der alternates()-Helfer der Runtime liefert die vollständige Map pro Dokument. So wird der Metadaten-Code zu einer Schleife statt zu einer Lookup-Tabelle, die Sie manuell pflegen müssen.
Zwei Regeln, die häufige Fehler verhindern:
- hreflang muss reziprok sein. Wenn die französische Seite die deutsche auflistet, muss die deutsche Seite die französische auflisten. Wenn beide Seiten aus demselben Store generiert werden, ist dies garantiert.
- Kanonische URLs müssen pro Locale auf sich selbst verweisen. Die kanonische URL der französischen Seite ist die französische URL. Wenn die kanonische URL jedes Locales auf Englisch verweist, wird Google angewiesen, Ihre Übersetzungen aus dem Index zu entfernen.
Eine Sitemap, die Locales kennt
Jeder URL-Eintrag in der Sitemap sollte dieselben alternativen Links enthalten, plus x-default. sitemapEntries() von Scribe liefert einen Eintrag pro Dokument mit allen Locale-URLs und einem lastmod, das aus den integrierten Feldern publishedAt und updatedAt abgeleitet wird. So bleibt die Sitemap ohne manuelle Daten ehrlich.
Dokumente, die Sie in den Ruhestand schicken, sollten nicht einfach verschwinden. Scribe speichert Weiterleitungen in einer typspezifischen _redirects.json, und ausgemusterte URLs leiten in jedem Locale per 301 auf ihren Ersatz weiter, wodurch die gewonnene Link-Autorität erhalten bleibt.
Locale-Fallbacks statt 404-Fehler
Was sollte /fr-CA/guide ausspielen, wenn Sie die Seite ins Französische, aber nicht ins kanadische Französisch übersetzt haben? Ein 404-Fehler verschwendet die vorhandene Übersetzung, stillschweigend Englisch auszuspielen, verwirrt die Leser.
Scribe löst dies automatisch über eine Fallback-Kette: Ein regionales Locale greift auf seine Basissprache zurück, bevor es Englisch verwendet. fr-CA versucht fr, dann en. zh-Hant-TW versucht zh-Hant, dann zh, dann en. Die Runtime meldet in actualLocale, welches Locale tatsächlich ausgespielt wurde, sodass Ihr Layout die Seite ehrlich kennzeichnen kann und vorgerenderte Parameter die Fallback-URLs enthalten, damit die Seiten beim Build-Prozess existieren.
Metadaten sind auch Inhalte
Titel und Meta-Descriptions sind Ranking-Faktoren und sollten daher mit der gleichen Sorgfalt übersetzt werden wie der Textkörper. In Scribe sind dies gewöhnliche übersetzbare Frontmatter-Felder, die wie alles andere gehasht und validiert werden. Der Übersetzungs-Prompt ist eher auf Transkreation als auf eine Wort-für-Wort-Übersetzung ausgelegt. Das ist bei den 60 Zeichen eines Title-Tags wichtiger als irgendwo sonst.
Das Fazit
Nichts davon ist exotisch. Es ist Buchhaltung: Alternativen, kanonische URLs, Sitemaps, Weiterleitungen und Fallbacks leiten sich alle von der einen Frage ab: „Welches Dokument existiert in welchem Locale unter welcher URL?“ Ein CMS, das Übersetzungen als First-Class-Daten speichert, kann diese Frage an einem zentralen Ort beantworten. Die manuelle Verknüpfung über ein gehostetes CMS, eine Übersetzungsplattform und Ihren Router hinweg ist der Punkt, an dem mehrsprachige SEO in der Regel scheitert.
Sehen Sie im Runtime API Guide, wie die einzelnen Teile zusammenpassen, oder beginnen Sie bei Getting Started.