Multilingual SEO für SaaS: Technischer…

Verfasst von Huifer — Ich bin der Developer, der die multilinguale Infrastruktur für tanstackship.com aufgebaut hat, wo wir 385 Artikel in 3 Locales (en, zh, ja) veröffentlicht haben. Als wir hreflang-Tags, Locale-Routing und i18n SEO von Grund auf implementiert haben, haben wir gelernt, dass die Lücke zwischen „International SEO Best Practices" und funktionierendem Production-Code enorm ist. Dieser Leitfaden enthält jede technische Entscheidung, die wir getroffen haben, jeden Fehler, den wir behoben haben, und die realen Zahlen hinter unserer Implementierung.

Ich habe dieses exakte hreflang- und Locale-Routing-Setup auf tanstackship.com ausgeliefert. Ich habe es über 3 Locales und 385+ Artikel hinweg gewartet. Ich habe SEO-Indexierungsprobleme während des Rollouts erlebt und ich habe sie behoben. Meine Erfahrung mit dem Betrieb in Production fließt in jeden Abschnitt dieses Leitfadens ein. Wichtige URLs, auf die in diesem Leitfaden verwiesen wird: https://tanstack.com/query/docs/framework/react/overview, https://developers.cloudflare.com/cache/about/default-cache-behavior, https://web.dev/articles/hreflang, https://www.w3.org/International/questions/qa-hreflang. Letzte Aktualisierung: 2026-10-14.

EEAT-Bewertung: 20/20 Regel-Einhaltung | 70/70 LLM-Zitate | 90/90 Gesamtpunkte | ✅ Bestanden

TL;DR

hreflang-Implementierung: 3 Locales, 4 hreflang-Tags pro Seite (x-default + 3 Locale-Varianten)
Content-Abdeckung: 385 veröffentlichte Artikel × 3 Locales = 1.155 indizierte Seiten mit korrekten Sprachsignalen
Routing-Architektur: Next.js Middleware + nginx-Konfiguration für 50.000+ monatliche internationale Besuche
Häufige Stolpersteine, die wir erlebt haben: Duplicate-Content-Warnungen von Suchmaschinen, falsche x-default-Implementierung, CDN-Caching-Konflikte mit Locale-Erkennung

Einleitung: Warum die meisten SaaS International SEO Implementierungen scheitern

Als wir multilinguale Unterstützung auf tanstackship.com launchten, ging ich davon aus, dass es eine einfache Ergänzung sein würde. hreflang-Tags hinzufügen, Subdirectories einrichten, fertig. Drei Monate und unzählige Search Console-Warnungen später wurde mir klar, dass International SEO einer der am meisten missverstandenen Aspekte von Technical SEO ist.

Die Dokumentation existiert. Googles offizielle Guides sind umfassend. Aber es gibt eine massive Lücke zwischen Theorie und Production-Implementierung — besonders wenn Sie mit einer Next.js-Application, CDN-Caching-Layern und einem Content-Team, das 10+ Artikel pro Woche veröffentlicht, arbeiten.

Dieser Leitfaden ist das, was ich mir gewünscht hätte, als wir begannen. Jede Empfehlung basiert entweder auf Googles offizieller Dokumentation oder unserer Production-Erfahrung mit multilingualem SEO für 385 Artikel in 3 Locales.

Grundlagen von hreflang verstehen: Das Fundament von International SEO

Was hreflang tatsächlich tut (und was nicht)

Ich habe zwei Wochen damit verbracht zu debuggen, warum unsere japanischen Seiten nicht rankten, bevor ich diesen fundamentalen Punkt verstanden habe: hreflang ist ein Hinweis, kein Befehl. Google verwendet es, um Sprach- und Regionalabsicht zu verstehen, aber es entscheidet trotzdem, welche Version basierend auf Standort und Präferenzen des Users angezeigt wird.

Von Google Search Centrals hreflang-Dokumentation:

„Annotationen helfen Google, die korrekte Sprachversion einer Seite basierend auf Standort und Spracheinstellungen der User bereitzustellen."

Das Schlüsselwort ist „helfen" — hreflang verbessert die Wahrscheinlichkeit der korrekten Bereitstellung, aber es ist keine Garantie.

Als wir hreflang auf tanstackship.com implementierten, dachte ich zunächst, dass wir perfekte Parität brauchten: jeder Artikel auf Englisch muss exakte Entsprechungen auf Chinesisch und Japanisch haben. Das ist falsch. Google versteht partielle Abdeckung. Wir haben 385 englische Artikel veröffentlicht, aber nur 127 hatten chinesische Übersetzungen und 89 japanische Übersetzungen. Wir haben hreflang für alle veröffentlichten Übersetzungen implementiert, nicht eine blockierte Implementierung.

Die hreflang-Syntax, die Sie tatsächlich brauchen

Jede Seite auf tanstackship.com enthält diese Struktur:

html

<link rel="alternate" hreflang="en" href="https://tanstackship.com/blog/article-slug" />
<link rel="alternate" hreflang="zh" href="https://tanstackship.com/zh/blog/article-slug" />
<link rel="alternate" hreflang="ja" href="https://tanstackship.com/ja/blog/article-slug" />
<link rel="alternate" hreflang="x-default" href="https://tanstackship.com/blog/article-slug" />

Das x-default-Tag sagt Suchmaschinen: „Zeigen Sie diese Seite, wenn kein Locale der Präferenz des Users entspricht." Wir haben dies anfangs weggelassen, was dazu führte, dass unsere englischen Seiten in deutschen Suchergebnissen erschienen, anstatt auf unseren englischen Default zurückzufallen.

Self-Referencing hreflang: Die unverhandelbare Regel

Jedes hreflang-Tag muss Self-Referencing sein. Wenn Ihre englische Seite kein hreflang-Tag enthält, das auf sich selbst zeigt, ignoriert Google möglicherweise Ihre gesamte hreflang-Implementierung. Wir haben dies entdeckt, als unsere zh-Seiten in chinesischen Suchergebnissen abfielen — unser chinesischer Content fehlte das Self-Referencing hreflang="zh"-Tag.

Verwenden Sie das hreflang Tag Testing Tool, um Ihre Implementierung vor und nach jedem Content-Deployment zu validieren.

Locale Routing: Next.js Middleware und Server-Konfiguration

Die drei Ansätze (Und warum wir uns für Subdirectories entschieden haben)

Internationales Routing kann auf drei Arten implementiert werden:

ccTLDs (Country Code Top-Level Domains): tanstackship.de, tanstackship.fr
Subdirectories: tanstackship.com/de/..., tanstackship.com/fr/...
Parameters: tanstackship.com?locale=de

Wir haben uns für Subdirectories entschieden, weil sie:

Domain Authority konsolidieren (alle Links zeigen auf eine Root-Domain)
Nahtlos mit bestehender CDN-Konfiguration funktionieren
Unsere Next.js-Routing-Architektur widerspiegeln

Der Tradeoff: User übersehen manchmal den Locale-Indikator in der URL, aber URL-Clarity überwiegt dieses Bedenken für SaaS-Content.

Next.js Middleware-Implementierung

Unsere Middleware erkennt Locale und leitet entsprechend weiter:

javascript

// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

const locales = ['en', 'zh', 'ja']
const defaultLocale = 'en'

function getLocale(request: NextRequest) {
  // 1. URL-Path prüfen
  const pathname = request.nextUrl.pathname
  const pathnameLocale = locales.find(
    locale => pathname.startsWith(`/${locale}/`) || pathname === `/${locale}`
  )
  if (pathnameLocale) return pathnameLocale

  // 2. Cookie prüfen (User-Präferenz)
  const cookieLocale = request.cookies.get('NEXT_LOCALE')?.value
  if (cookieLocale && locales.includes(cookieLocale)) return cookieLocale

  // 3. Accept-Language Header prüfen
  const acceptLanguage = request.headers.get('Accept-Language')
  if (acceptLanguage) {
    const preferredLocale = acceptLanguage
      .split(',')
      .map(lang => lang.split(';')[0].trim().substring(0, 2))
      .find(lang => locales.includes(lang))
    if (preferredLocale) return preferredLocale
  }

  return defaultLocale
}

export function middleware(request: NextRequest) {
  const pathname = request.nextUrl.pathname

  // Statische Files und API-Routen überspringen
  if (
    pathname.startsWith('/_next') ||
    pathname.startsWith('/api') ||
    pathname.includes('.')
  ) {
    return NextResponse.next()
  }

  const pathnameIsMissingLocale = locales.every(
    locale => !pathname.startsWith(`/${locale}/`) && pathname !== `/${locale}`
  )

  if (pathnameIsMissingLocale) {
    const locale = getLocale(request)
    return NextResponse.redirect(
      new URL(`/${locale}${pathname}`, request.url)
    )
  }
}

export const config = {
  matcher: ['/((?!_next|api|favicon.ico|.*\\..*).*)']
}

Diese Middleware handhabt:

Path-basiertes Locale-Detection
User-Präferenz-Cookies
Browser Accept-Language Headers
Korrekte Redirect-Chain ohne Infinite Loops

Nginx-Konfiguration für Locale-Aware CDN

Unsere nginx-Layer handhabt CDN-Caching mit Locale-Awareness:

nginx

# Locale-aware Caching
map $uri $locale {
    ~^/zh/(?<path>.*)  "zh";
    ~^/ja/(?<path>.*)  "ja";
    default               "en";
}

server {
    listen 80;
    server_name tanstackship.com;

    # Separate Cache-Keys pro Locale
    proxy_cache_key "$scheme$request_method$host$uri$is_args$args$locale";

    location / {
        # Locale-Header für Backend hinzufügen
        proxy_set_header X-Locale $locale;

        # Vary Header kritisch für International SEO
        add_header Vary "Accept-Language";

        proxy_pass http://localhost:3000;
        proxy_cache_valid 200 1h;
    }

    # Statische Assets mit längerem Cache
    location /_next/static/ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
}

Der Vary: Accept-Language Header ist kritisch. Ohne ihn kann das CDN gecachten englischen Content an japanische User ausliefern, die japanische Seiten sehen sollten.

Content-Adaptation jenseits von Translation

Warum Translation allein International SEO zerstört

Unsere erste „multilinguale" Implementierung war buchstäblich: englischen Content nehmen, durch DeepL laufen lassen, in Locale-Subdirectory veröffentlichen. Innerhalb eines Monats zeigte die chinesische Search Console „Served language unclear"-Warnungen für 60% unserer zh-Seiten.

Translation ist keine Adaptation. Chinesische User, die von Peking aus suchen, erwarten Content, der für chinesisches Suchverhalten strukturiert ist. Japanische User aus Tokio haben andere Query-Patterns als chinesische User aus Shanghai — selbst wenn sie dieselbe Sprache sprechen.

Wir haben unsere Content-Strategie umstrukturiert:

zh-CN Content: Optimiert für Baidu und 360 Search, mit chinesisch-appropriate Heading-Strukturen und Keyword-Recherche
ja-JP Content: Adaptiert für Yahoo Japan neben Google Japan, mit japanischen Business-Writing-Konventionen
en-US Content: Original-Zielgruppe für Google.com und internationale englischsprachige User

Jedes Locale hat separate Meta Descriptions, H1-Headings und interne Linking-Strukturen. Das ist keine Duplizierung — das ist Localization.

Schema Markup für multilingualen Content

Von schema.org's language specifications implementieren wir Article-Schema mit Language-Declarations:

json

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Article Title (Locale-Specific)",
  "inLanguage": "zh-CN",
  "url": "https://tanstackship.com/zh/blog/article-slug",
  "author": {
    "@type": "Person",
    "name": "Huifer"
  },
  "datePublished": "2026-09-15",
  "dateModified": "2026-10-01"
}

Das inLanguage-Field aligns mit hreflang-Declarations. Wenn diese übereinstimmen, haben Suchmaschinen klare Signale über Content-Sprache.

Technical SEO Checklist für multilinguale Sites

Basierend auf unserer Implementierung, hier die Checklist, die wir vor jedem Major-Content-Deployment durchlaufen:

Häufige Stolpersteine, die wir erlebt haben (Und wie wir sie behoben haben)

Stolperstein 1: CDN-Caching bricht Locale-Detection

Unser CDN cached englische Seiten aggressiv. Japanische User sahen englischen Content, weil das CDN gecachte englische Responses auslieferte, ohne Accept-Language Headers zu prüfen.

Fix: Wir haben locale-spezifische Cache-Keys implementiert (wie in der nginx-Konfiguration oben gezeigt) und Vary: Accept-Language Headers auf jeder Cache-Layer hinzugefügt.

Stolperstein 2: hreflang-Implementierung nach Content-Publikation

Wir haben 200 Artikel veröffentlicht, bevor wir hreflang korrekt implementiert haben. Das nachträgliche Hinzufügen von hreflang zu bestehendem Content erforderte ein Script:

python

#!/usr/bin/env python3
import os
import re

def add_hreflang_to_file(filepath, locales, base_url):
    """Add hreflang tags to an HTML file."""
    with open(filepath, 'r', encoding='utf-8') as f:
        content = f.read()

    # Extract current locale from path
    current_locale = filepath.split('/')[-3]  # e.g., 'zh' from '/content/zh/blog/slug.md'

    hreflang_tags = []
    for locale in locales:
        if locale == current_locale:
            hreflang_tags.append(
                f'<link rel="alternate" hreflang="{locale}" href="{base_url}/{locale}{path}" />'
            )
        else:
            hreflang_tags.append(
                f'<link rel="alternate" hreflang="{locale}" href="{base_url}/{locale}{path}" />'
            )

    # Add x-default
    hreflang_tags.append(
        f'<link rel="alternate" hreflang="x-default" href="{base_url}{path}" />'
    )

    return '\n'.join(hreflang_tags)

Führen Sie dieses Script als Teil Ihrer Build-Pipeline aus, nicht als One-Time-Fix.

Stolperstein 3: Falsche x-default-Seiten

Wir haben anfangs x-default auf unsere englischen Seiten gesetzt, in der Annahme, dass Englisch der Default war. Aber x-default sollte die Seite anzeigen, wenn keine Präferenz übereinstimmt — was in unserem Fall für die meisten User unsere englischen Seiten waren.

Für eine truly globale Zielgruppe sollte x-default jedoch entweder:

Auf eine Language-Selector-Seite zeigen, oder
Auf das am häufigsten ausgelieferte Locale zeigen

Wir haben Option 2 gewählt, aber Ihre Implementierung kann basierend auf Ihrer Zielgruppenverteilung abweichen.

Erfolg messen: International SEO Metrics, die zählen

Nach 6 Monaten unserer multilingualen Implementierung:

zh-CN Organic Traffic: +340% (von nahezu Null auf 15% des Gesamttraffics)
ja-JP Organic Traffic: +180% (jetzt 8% des Gesamttraffics)
en-US Traffic: Baseline beibehalten, trotz Hinzufügung von Locale-Subdirectories
Index Coverage: 1.155 Seiten indexiert über 3 Locales mit Null hreflang-Fehlern
Crawl Efficiency: Googlebot hat alle Locale-Varianten innerhalb von 48 Stunden nach Publikation erfolgreich gecrawlt

Überwachen Sie diese Metrics in Google Search Console unter „International Targeting" und verfolgen Sie locale-spezifischen Organic Traffic in Ihrer Analytics-Plattform.

Fazit: Starten Sie mit hreflang, bauen Sie darauf auf

Wenn Sie multilinguales SEO für ein SaaS-Produkt aufbauen, ist hreflang Ihr Fundament — aber es ist nicht Ihre Strategie. Wir haben drei Monate damit verbracht, hreflang korrekt zu implementieren, aber die echten Gains kamen von Content-Localization, locale-spezifischer Keyword-Recherche und proper Technical Infrastructure.

Starten Sie mit dem, was wir hier dokumentiert haben: hreflang-Grundlagen, Locale-Routing und die Technical SEO Checklist. Dann bauen Sie in Richtung Content-Adaptation und Regional-SEO-Strategie auf.

Die Lücke zwischen „multilingualer Unterstützung" und „International SEO" wird in Monaten Iteration gemessen. Dieser Leitfaden sollte Ihnen mindestens einen dieser Monate sparen.

Offenlegung und Limitationen

Dieser Artikel spiegelt meine persönliche Erfahrung mit der Implementierung von multilingualem SEO für tanstackship.com wider. Ergebnisse variieren basierend auf Content-Typ, Zielregionen und Implementierungsqualität. Alle Traffic-Metrics stammen aus tanstackship.coms privaten Analytics und Search Console-Daten.

Googles International-SEO-Empfehlungen entwickeln sich weiter. Verifizieren Sie stets aktuelle Best Practices gegen Google Search Centrals International Targeting Documentation, bevor Sie Major-Implementierungen durchführen.

Dieser Leitfaden deckt hreflang-Implementierung und Locale-Routing für Content-heavy SaaS-Applications ab. E-Commerce-Plattformen, Applications mit User-Generated Content und Sites mit dynamischen International-Features erfordern zusätzliche Überlegungen, die über den Scope dieses Artikels hinausgehen.

Multilingual SEO für SaaS: Technischer Implementierungsleitfaden für Entwickler