Hauptbereich
Agency
technisches-seo

International SEO — hreflang, Subfolder, Canonical sauber aufgesetzt

Redaktion ·

Warum International SEO den Unterschied macht

Eine mehrsprachige Site, die technisch nicht sauber ausgezeichnet ist, fällt im Suchmaschinen-Alltag auf zwei typische Arten auf die Nase. Erstens: Google rankt im deutschen Markt die englische Version, weil die englische Seite mehr Backlinks hat und die hreflang-Verknüpfung fehlt — der deutsche Nutzer landet auf einer Sprache, die er nicht erwartet hat, und springt ab. Zweitens: Beide Sprachversionen kannibalisieren sich gegenseitig im Index, weil Canonicals cross-locale verweisen und Google die deutsche Version als Duplikat der englischen einstuft. In beiden Fällen ist das Problem nicht der Content — sondern die fehlende Klarheit in den Meta-Signalen.

Dieser Artikel beschreibt, wie du die drei zentralen Bausteine — URL-Struktur, hreflang und Canonical — so kombinierst, dass jede Locale eine eigene Identität bekommt und trotzdem als Familie erkennbar bleibt. Die Beispiele orientieren sich an einer typischen DE/EN-Architektur, die Prinzipien skalieren auf beliebig viele Sprachen.

Die Grundmechanik: Drei Signale, drei Aufgaben

International SEO funktioniert über drei voneinander unabhängige technische Signale. Jedes Signal beantwortet eine andere Frage — und jedes muss isoliert korrekt gesetzt sein, damit das Gesamtsystem trägt.

URL-Struktur — wo lebt welche Sprache?

Google muss anhand der URL erkennen können, in welcher Sprache eine Seite ausgeliefert wird. Drei Modelle sind etabliert:

  • ccTLD (example.de, example.fr): stärkstes Geo-Signal, höchste Verwaltungslast (eigene Domains, eigene Authority-Pools, eigenes Hosting). Sinnvoll bei wirklich getrennten Märkten mit eigener Rechtslage und Marketing-Strategie.
  • Subdomain (de.example.com, en.example.com): mittlerer Aufwand, mittleres Signal. Wird von Google teils als eigenes Property behandelt — Authority muss separat aufgebaut werden.
  • Subfolder (example.com/de/, example.com/en/): pragmatischste Wahl für die meisten Sites. Eine Domain, ein Authority-Pool, einfache hreflang-Pflege. Standard für SaaS, Agentur-Sites und Content-Plattformen.

Subfolder gewinnen in der Praxis fast immer, sobald die Märkte nicht juristisch oder organisatorisch komplett getrennt sind. Der Artikel verwendet ab hier die Subfolder-Struktur als Referenz.

hreflang — welche Sprachversion ist für wen?

hreflang ist die explizite Auszeichnung: „diese Seite gibt es auch auf Deutsch unter URL X, auf Englisch unter URL Y, auf Französisch unter URL Z”. Drei Eigenschaften sind nicht verhandelbar:

  • Bidirektional. Wenn /de/produkt auf /en/product zeigt, muss /en/product zurück auf /de/produkt zeigen. Fehlt der Rückverweis, ignoriert Google die Auszeichnung komplett.
  • Self-Reference. Jede Seite listet auch sich selbst in den hreflang-Tags. /de/produkt enthält ein hreflang auf /de/produkt. Ohne Self-Reference ist das Set unvollständig.
  • BCP-47-Codes. Sprache (de, en) oder Sprache+Region (de-AT, en-US). Nie de-DE als Synonym für „Deutsch generisch” — das schränkt unnötig auf Deutschland ein.

Canonical — welche URL ist die offizielle?

Der Canonical Tag regelt, welche von mehreren gleichsprachigen URL-Varianten die Hauptversion ist. Bei International SEO ist die Regel einfach und unverhandelbar: Jede Locale verweist auf sich selbst. /de/produkt hat Canonical /de/produkt. Niemals cross-locale auf /en/product.

Cross-locale-Canonicals sind der häufigste Killer mehrsprachiger Sites — Google liest das als „die deutsche Seite ist nur eine Variante der englischen, die englische ist die Hauptversion” und entfernt die deutsche aus dem Index.

Stolperfallen — was in der Praxis schiefgeht

Fehlende Self-Reference und x-default

Viele Sites listen pro Seite nur die anderen Sprachen, nicht die eigene. Google verlangt aber das vollständige Set inklusive Self-Reference. Ähnlich häufig fehlt x-default — das Fallback-Signal für Sprachen, die nicht explizit abgedeckt sind. Ein Nutzer aus Spanien, der weder DE noch EN ausgewählt hat, soll auf der x-default-Version landen.

Cross-Locale-Canonicals durch CMS-Defaults

Manche CMS setzen automatisch einen Canonical auf die „Master-Sprache”. Das ist für reine Übersetzungs-Plugins gemeint, in dem International-SEO-Setup aber tödlich. Vor dem Launch immer eine Stichprobe: View-Source auf einer DE- und einer EN-Seite, beide Canonicals prüfen — sie müssen jeweils auf sich selbst zeigen.

IP-basiertes Auto-Redirect

Wer Nutzer per IP automatisch auf die „passende” Sprachversion umleitet, verliert für Crawler die Sichtbarkeit der anderen Locales. Googlebot crawlt aus US-IPs — landet beim Auto-Redirect immer auf der EN-Version, die DE-Seiten werden nie erfasst. Saubere Lösung: Sprachauswahl-Banner ohne Redirect, der Nutzer entscheidet.

Inkonsistente URLs zwischen hreflang und Canonical

Ein klassischer Bug: hreflang verweist auf /de/produkt, der Canonical auf der Seite zeigt aber auf /de/produkt/. Trailing Slash, http vs. https, www vs. non-www — alle Varianten müssen konsistent sein. Google folgt dem Canonical und ignoriert den hreflang, wenn die URLs nicht exakt übereinstimmen.

Sitemap-Verweise auf 301-Redirects

Wer hreflang in der Sitemap pflegt (statt im HTML-Head), muss darauf achten, dass keiner der gelisteten URLs auf eine Weiterleitung zeigt. Sobald Google bei einem hreflang-Ziel auf einen 301 stößt, wirft es die ganze Annotation für diese Seite weg.

Implementierung — drei Wege, wo hreflang reinkommt

Variante 1: HTML-Head (Standard)

<link rel="canonical" href="https://example.com/de/produkt/">
<link rel="alternate" hreflang="de" href="https://example.com/de/produkt/">
<link rel="alternate" hreflang="en" href="https://example.com/en/product/">
<link rel="alternate" hreflang="x-default" href="https://example.com/en/product/">

Funktioniert für jede Seite, die HTML ausliefert. Pflegeaufwand wächst linear mit der Sprachzahl, ist aber für die meisten Sites mit Template-Logik gut beherrschbar.

Variante 2: HTTP-Header

Für Nicht-HTML-Ressourcen (PDFs, Whitepapers in mehreren Sprachen) der einzige Weg:

Link: <https://example.com/de/whitepaper.pdf>; rel="alternate"; hreflang="de",
      <https://example.com/en/whitepaper.pdf>; rel="alternate"; hreflang="en"

Variante 3: XML-Sitemap

Für sehr große Sites (>10.000 URLs pro Sprache) der Performance-Sieger — die Annotation steht zentral in der Sitemap, der HTML-Head bleibt schlank:

<url>
  <loc>https://example.com/de/produkt/</loc>
  <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/produkt/"/>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/product/"/>
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/product/"/>
</url>

Wichtig: Nicht mischen. Wer hreflang im Head und in der Sitemap pflegt, riskiert Konflikte und Pflegefehler.

Vergleichstabelle: URL-Struktur und Implementierung

| Kriterium | ccTLD | Subdomain | Subfolder | |---|---|---|---| | Geo-Signal | sehr stark | mittel | schwach (wird über hreflang ausgeglichen) | | Authority-Aufbau | pro Domain getrennt | meist getrennt | gemeinsam | | Hosting | pro Domain wählbar | pro Subdomain wählbar | gemeinsam | | Pflegeaufwand hreflang | hoch | mittel | gering | | Sinnvoll bei | wirklich getrennten Märkten | mittlerer Trennung | Standardfall mehrsprachiger Site | | Beispiel | example.de / example.fr | de.example.com | example.com/de/ |

| hreflang-Ort | Vorteil | Nachteil | |---|---|---| | HTML-Head | überall sichtbar, einfach zu debuggen | bläht Head bei vielen Sprachen auf | | HTTP-Header | einziger Weg für Nicht-HTML | schwerer zu auditieren | | XML-Sitemap | skalierbar bei >10k URLs | Konflikte mit Head-Tags möglich |

Praxisbeispiel: DE/EN-Site mit Subfolder

Eine SaaS hat Inhalte auf Deutsch und Englisch, gehostet auf example.com mit Subfolder-Struktur. Die Produktseite existiert in beiden Sprachen.

HTML-Head der DE-Seite (/de/produkt/):

<link rel="canonical" href="https://example.com/de/produkt/">
<link rel="alternate" hreflang="de" href="https://example.com/de/produkt/">
<link rel="alternate" hreflang="en" href="https://example.com/en/product/">
<link rel="alternate" hreflang="x-default" href="https://example.com/en/product/">

HTML-Head der EN-Seite (/en/product/):

<link rel="canonical" href="https://example.com/en/product/">
<link rel="alternate" hreflang="de" href="https://example.com/de/produkt/">
<link rel="alternate" hreflang="en" href="https://example.com/en/product/">
<link rel="alternate" hreflang="x-default" href="https://example.com/en/product/">

Drei Dinge, die hier richtig sind:

  1. Self-Reference auf beiden Seiten (jede Seite listet sich selbst).
  2. Bidirektionalität: DE zeigt auf EN, EN zeigt zurück auf DE.
  3. Canonical pro Locale: jede Seite zeigt auf sich selbst, nie cross-locale.

x-default zeigt hier auf die EN-Version, weil das die internationale Standardversion ist. Bei einer Site mit dedizierter Sprachauswahl-Landingpage würde x-default auf diese Auswahl-Seite zeigen.

Praxisbeispiel: Fehlerhafte Auszeichnung erkennen

Eine schnelle Audit-Routine für eine bestehende Site:

  1. Browser-DevTools → View Source auf einer DE-Seite. Prüfen: Canonical zeigt auf DE-URL? Self-Reference vorhanden? hreflang-Set vollständig?
  2. Dasselbe auf der korrespondierenden EN-Seite. Prüfen: Verweist EN-hreflang auf exakt die DE-URL aus Schritt 1?
  3. Search Console → Internationale Ausrichtung: zeigt Google fehlende Rückverweise an?
  4. curl -I auf eine DE-URL: keine 301-Redirects auf der hreflang-Pfad? Trailing-Slash konsistent?

Eine typische Fundstelle: Die DE-Seite verweist im hreflang auf https://example.com/en/product, die tatsächliche EN-URL ist aber https://example.com/en/product/ (mit Slash). Beide Seiten ranken trotzdem — aber die hreflang-Verknüpfung greift nicht, und die Locales konkurrieren im Index.

FAQ

Brauche ich de-DE oder reicht de?
de reicht für Deutsch-allgemein. de-DE, de-AT, de-CH nur, wenn du wirklich länderspezifische Versionen pflegst (andere Preise, andere AGB, andere Telefonnummern). Sonst wird das Set unnötig groß und schwerer zu warten.
Was passiert bei Seiten, die nur in einer Sprache existieren?
Keine hreflang-Annotation setzen. Die Seite rankt einfach in ihrer Sprache. Sobald eine Übersetzung dazukommt, beide verknüpfen.
Brauche ich x-default, wenn alle Sprachen abgedeckt sind?
Streng genommen nein, in der Praxis fast immer empfehlenswert. Es gibt mehr Sprachen als die abgedeckten — x-default sagt Google, was es spanischsprachigen, japanischen oder portugiesischen Nutzern zeigen soll. Üblich: x-default zeigt auf die EN-Version oder die Sprachauswahl-Seite.
Wie schnell wirken hreflang-Änderungen?
Tage bis Wochen. Google muss erst alle betroffenen Seiten neu crawlen und die Bidirektionalität verifizieren. Bei größeren Sites über die Search Console eine erneute Indexierung anstoßen.
Was ist mit JavaScript-gerenderten hreflang-Tags?
Funktioniert prinzipiell, ist aber fragiler. Server-seitig im HTML-Head ist der robuste Weg. Wer ein SPA betreibt, sollte hreflang über die Sitemap pflegen.

Fazit

International SEO ist keine Magie, sondern saubere Mechanik mit drei Bausteinen: URL-Struktur, hreflang und Canonical. Wer die drei trennt — Subfolder als Default, hreflang bidirektional inkl. Self-Reference und x-default, Canonical immer auf die eigene Locale — hat 90 % der Probleme im Griff, bevor sie entstehen.

Die häufigsten Fehler sind nicht inhaltlicher, sondern struktureller Natur: cross-locale-Canonicals, fehlende Self-Reference, inkonsistente URLs. Vor jedem Launch und nach jeder Template-Änderung lohnt eine zehnminütige Audit-Routine über View-Source und Search Console — das ist der billigste SEO-Hebel im mehrsprachigen Setup.

Wer eine neue Site aufbaut: mit Subfolder starten, hreflang im HTML-Head pflegen, Canonical pro Locale festziehen. Wer eine bestehende Site übernimmt: zuerst die drei Signale auditieren, bevor irgendwer am Content schraubt. Sichtbarkeitsverluste durch falsche Auszeichnung dauern Wochen bis sie sich nach einer Korrektur erholen — Vorsicht zahlt sich mehrfach aus.

Themenuebersicht

Technisches SEOCrawling & Indexierung