SEO

Mehrsprachiges SEO in Next.js: Was next-intl löst und was du selbst bauen musst

Eine Seite zu übersetzen ist nicht dasselbe, wie sie mehrsprachig zu machen. Notizen aus dem Betrieb von drei Sprachen auf einer Domain mit next-intl — und den vier Stellen, an denen Google wirklich streng ist.

Mehran Hatami13. August 20263 Min. LesezeitNext.jsnext-intlSEO

Diese Seite läuft in drei Sprachen: Persisch, Englisch und Deutsch. Die Übersetzungen einzurichten dauerte einen Nachmittag. Google davon zu überzeugen, dass es sich um Versionen einer Seite handelt und nicht um drei Duplikate, dauerte Wochen. Dieser Beitrag handelt vom zweiten Teil.

Erstens: die URL-Struktur früh festlegen

Kernaussage

next-intl löst Routing und Texte. Hreflang, Canonicals und Sitemap bleiben deine Aufgabe — und genau sie entscheiden über das Ranking.

Es gibt drei Optionen: eine eigene Domain je Sprache, Subdomains oder ein Pfadpräfix wie /fa und /en. Für eine Produkt- oder Portfolioseite ist das Pfadpräfix fast immer richtig — die Domain-Autorität bleibt an einem Ort und die Pflege kostet nichts. Wichtiger als die Wahl ist, sie später nicht zu ändern; ein Umbau nach der Indexierung bedeutet Monate voller Redirects und Ranking-Unruhe.

Zweitens: hreflang, wo die meisten Seiten scheitern

Hreflang sagt Google, dass diese Seiten Übersetzungen voneinander sind. Drei Regeln müssen gleichzeitig gelten: Jede Seite verweist auf alle Versionen einschließlich sich selbst, die Verweise sind wechselseitig, und ein x-default muss existieren, damit Besuchende ohne passende Sprache irgendwo landen. Im App Router kommt all das aus generateMetadata.

export async function generateMetadata({ params }) {
  const { locale } = await params;
  return {
    alternates: {
      canonical: `https://example.com/${locale}`,
      languages: {
        fa: "https://example.com/fa",
        en: "https://example.com/en",
        de: "https://example.com/de",
        "x-default": "https://example.com/en",
      },
    },
  };
}

Drittens: das Canonical zeigt auf die eigene Sprache

Das ist der häufigste Fehler, den ich sehe: Alle Versionen kanonisieren auf die englische Seite. Die Folge ist, dass Google die persische Version aus dem Index nimmt, weil die Seite selbst erklärt hat, das Original liege woanders. Das Canonical jeder Seite ist diese Seite. Die Beziehung zwischen den Sprachen wird ausschließlich über hreflang ausgedrückt.

Der zweite verbreitete Fehler ist www gegen non-www. Antworten beide, hat jede Seite zwei Adressen, und die Search Console meldet das als „Duplikat, Google hat ein anderes Canonical gewählt“. Ein einziger 301 in der Middleware beendet die Sache.

Viertens: auch die Sitemap ist dreisprachig

Die Sitemap sollte alle drei Versionen separat auflisten und je Eintrag die Sprachalternativen tragen. In Next.js erzeugt die sitemap-Funktion mit einem alternates-Feld genau das — ganz ohne handgeschriebenes XML.

export default function sitemap() {
  const locales = ["fa", "en", "de"];
  return locales.map((locale) => ({
    url: `https://example.com/${locale}`,
    alternates: {
      languages: Object.fromEntries(
        locales.map((l) => [l, `https://example.com/${l}`])
      ),
    },
  }));
}

Und eine Sache, die dir kein Tool sagt

Maschinelle Übersetzung macht Seiten nicht mehrsprachig. Wer auf Persisch sucht, tippt eine andere Formulierung als jemand, der auf Englisch sucht — selbst wenn beide dasselbe wollen. Titel und Beschreibungen jeder Sprache müssen aus dem Vokabular des jeweiligen Marktes geschrieben werden, nicht Wort für Wort aus dem Original übersetzt. Korrektes hreflang sagt Google, für welche Sprache eine Seite gedacht ist. Korrekter Inhalt entscheidet, ob sie überhaupt gefunden wird.