International SEO: hreflang, ccTLD oder Subdomain

Wenn Ihre Website mehrere Länder oder Sprachräume ansprechen soll, fallen die wichtigsten Entscheidungen lange vor dem ersten hreflang-Tag - nämlich bei der URL-Architektur. Die kurze Antwort: Wer auf ein bestimmtes Land mit eigener Marke abzielt, fährt mit einer ccTLD wie .de oder .fr am besten. Wer dagegen seine Domain-Autorität bündeln und schnell skalieren will, wählt ein Subdirectory wie domain.com/de/. Subdomains liegen dazwischen und lohnen sich vor allem bei technischer Trennung.

Diese Entscheidung ist nach dem Launch nur mit großem Aufwand und Ranking-Risiko reversibel. Deshalb behandeln wir hier zuerst die Architektur, dann das korrekte hreflang-Setup mit Code-Beispielen, die häufigsten Fehler und eine Audit-Checkliste. Studien von Suchmaschinen-Analysten zeigen, dass rund 75 % aller hreflang-Implementierungen mindestens einen kritischen Fehler enthalten - die Auswahl der richtigen Struktur halbiert dieses Risiko bereits.

Welche Architektur passt zu welchem Geschäftsmodell

Die Wahl der URL-Struktur hängt weniger von technischen Vorlieben ab als von Ihrem Geschäftsmodell. Drei Fragen entscheiden: Wie wichtig ist lokales Vertrauen pro Land? Wie schnell wollen Sie expandieren? Und wie viele technische Ressourcen haben Sie?

Ein lokales Unternehmen mit echten Niederlassungen in Deutschland, Österreich und der Schweiz profitiert von landesspezifischen Domains, weil Nutzer einer .de-Adresse mehr vertrauen. Ein SaaS-Anbieter, der in 15 Sprachen verkauft, sollte dagegen jede Sprachversion auf einer Domain bündeln, damit Backlinks und Autorität nicht auf Dutzende schwache Einzeldomains verteilt werden.

Ein häufiger Denkfehler vorab: Sprache und Land sind nicht dasselbe. Spanisch wird in Spanien, Mexiko und Argentinien gesprochen, oft aber mit unterschiedlichen Begriffen, Preisen und Währungen. Bevor Sie über die Domain-Struktur entscheiden, klären Sie, ob Sie reine Sprachversionen brauchen oder echte Länderversionen mit lokalisiertem Angebot. Diese Antwort bestimmt, ob ein einfaches de ausreicht oder ob Sie bis auf die Ebene de-CH heruntergehen müssen.

Wer ganz am Anfang steht und erst die strategischen Grundlagen sucht, findet in unserem Beitrag zu den Grundlagen mehrsprachiger Websites eine umfassende Einführung in Lokalisierung und Geotargeting.

ccTLD: Maximales lokales Vertrauen

Eine Country Code Top-Level Domain signalisiert sofort, für welches Land die Inhalte gedacht sind:

example.de  - Deutschland
example.at  - Oesterreich
example.fr  - Frankreich
example.co.uk - Grossbritannien

Vorteile: Das stärkste Geotargeting-Signal überhaupt, hohes Nutzervertrauen im Zielland und eine klare rechtliche Trennung. Lokale Konkurrenten haben es schwerer, weil Google die Domain eindeutig dem Land zuordnet.

Nachteile: Jede ccTLD startet bei null Autorität. Sie brauchen pro Land eigene Backlinks, eigenes Hosting und oft eigene Verwaltung. Bei zehn Märkten verwalten Sie zehn Domains - das ist teuer und langsam.

Die ccTLD lohnt sich, wenn lokales Vertrauen direkt Umsatz bedeutet: E-Commerce mit landesspezifischem Versand, regulierte Branchen oder Marken, die pro Land ein eigenes Gesicht zeigen wollen. Rechnen Sie aber ehrlich: Drei ccTLDs bedeuten dreimal Linkbuilding, dreimal Content-Pflege und dreimal technische Wartung. Viele Unternehmen unterschätzen, wie lange eine neue Landesdomain braucht, um aus dem Stand Rankings aufzubauen - in umkämpften Märkten oft ein Jahr und mehr.

Subdirectory: Autorität bündeln und schnell skalieren

Beim Subdirectory (auch Unterverzeichnis genannt) liegen alle Sprachversionen unter einer einzigen Domain:

example.com/de/
example.com/en/
example.com/fr/

Vorteile: Die gesamte Domain-Autorität fließt in eine Domain. Ein Backlink auf die englische Seite stärkt auch die deutsche. Das Setup ist günstig, schnell erweiterbar und braucht nur ein Hosting. Für neue Märkte legen Sie einfach ein weiteres Verzeichnis an.

Nachteile: Das Geotargeting-Signal ist schwächer als bei ccTLDs und muss über hreflang plus Search-Console-Einstellungen erfolgen. Die Trennung wirkt für Nutzer weniger landesspezifisch.

Für die meisten Unternehmen mit begrenzten SEO-Ressourcen ist das Subdirectory die pragmatischste Wahl. Genau deshalb betreiben große internationale Marken ihre Märkte fast durchgängig in dieser Struktur - die gebündelte Autorität wiegt das schwächere Geo-Signal mehr als auf.

Ein weiterer Vorteil zeigt sich beim Reporting und der Pflege: Ein Crawl, ein Hosting, ein technisches Setup. Updates an Layout, Tracking oder Schema-Markup spielen Sie einmal aus und sie greifen in allen Sprachen. Wer schon einmal dieselbe technische Änderung über fünf ccTLDs hinweg ausrollen musste, weiß, wie viel Zeit diese Bündelung im Alltag spart.

Subdomain: Der technische Mittelweg

Subdomains trennen die Sprachversionen auf Drittebene:

de.example.com
en.example.com
fr.example.com

Vorteile: Saubere technische Trennung, etwa wenn verschiedene Server, Content-Management-Systeme oder Teams pro Sprache zuständig sind. Geotargeting lässt sich pro Subdomain einstellen.

Nachteile: Google behandelt Subdomains teilweise als eigenständige Einheiten, sodass die Autorität nicht so stark bündelt wie beim Subdirectory. In der Praxis liegen Subdomains beim Linkjuice-Transfer zwischen ccTLD und Verzeichnis.

Subdomains sind dann sinnvoll, wenn technische Gründe für eine Trennung sprechen - nicht aber als Standardlösung für reine Sprachvarianten.

hreflang-Setup mit konkreten Code-Beispielen

Egal welche Architektur Sie wählen: Ohne korrektes hreflang erkennt Google nicht, welche Version für welchen Nutzer gedacht ist. Das Attribut verknüpft alle Sprachversionen miteinander und verhindert, dass ähnliche Seiten als Duplicate Content gewertet werden.

Im einfachsten Fall setzen Sie die Tags im <head> jeder Seite. Wichtig ist die Selbstreferenz - jede Seite verlinkt auch auf sich selbst - und ein x-default für Nutzer, die keiner Sprache eindeutig zugeordnet werden:

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

Der Sprachcode folgt dem ISO-639-1-Standard, optional ergänzt um einen Ländercode nach ISO 3166-1 Alpha-2. So unterscheiden Sie etwa Deutsch für Deutschland von Deutsch für die Schweiz:

<link rel="alternate" hreflang="de-DE" href="https://example.com/de/" />
<link rel="alternate" hreflang="de-CH" href="https://example.com/ch/" />
<link rel="alternate" hreflang="de-AT" href="https://example.com/at/" />

Eine zentrale Regel macht die Implementierung fehlerresistent: hreflang muss bidirektional sein. Wenn die deutsche Seite auf die englische zeigt, muss die englische Seite zurück auf die deutsche zeigen. Fehlt diese Rückverknüpfung, ignoriert Google das gesamte Tag-Set. Bei vielen Sprachen wird die Pflege aufwendig - alternativ liefern Sie die Verknüpfungen über eine XML-Sitemap aus, was bei großen Seiten oft wartbarer ist. Die vollständige Syntax mit allen Sonderfällen erklären wir Schritt für Schritt im Beitrag zur korrekten Implementierung von hreflang-Tags.

Häufige hreflang-Fehler und wie Sie sie vermeiden

hreflang ist technisch unforgiving - kleine Schreibfehler entwerten ganze Sets. Diese Fehler sehen wir im Agenturalltag am häufigsten:

• Fehlende Rückverknüpfung. Die häufigste Ursache für ignorierte Tags. Jede Verknüpfung muss in beide Richtungen bestehen.
• Falsche Sprachcodes. en-UK ist ungültig, korrekt ist en-GB. Auch de-DE als reiner Sprachcode ohne Land funktioniert oft besser, wenn kein Landesbezug nötig ist.
• Fehlende Selbstreferenz. Jede Seite muss sich auch selbst im Set aufführen, sonst bricht die Logik.
• Relative statt absolute URLs. hreflang braucht immer die vollständige URL inklusive Protokoll und Domain.
• Verweise auf Noindex- oder Redirect-Seiten. Ziel-URLs müssen indexierbar sein und mit Status 200 antworten, nicht weiterleiten.

Allein der erste Punkt erklärt einen Großteil der defekten hreflang-Setups, die wir in Audits finden. Wer eine statische Website ohne CMS-Plugin betreibt, findet die manuelle Umsetzung samt Build-Automatisierung in unserem Beitrag zu hreflang auf statischen Websites.

Geo-Targeting in der Google Search Console

hreflang regelt die Sprache, nicht zwingend das Land. Für ein klares Ländersignal nutzen Sie zusätzliche Hebel - je nach Architektur unterschiedlich.

Bei ccTLDs ist das Geotargeting automatisch gesetzt: .de zielt auf Deutschland, da kann und sollten Sie nichts ändern. Bei generischen Domains (.com, .net, .org) mit Subdomains oder Verzeichnissen war früher die manuelle Länderausrichtung in der Search Console möglich. Diese Funktion wurde abgeschafft - heute steuert Google die geografische Ausrichtung primär über hreflang, Serverstandort, lokale Backlinks und die Sprache der Inhalte.

Praktisch bedeutet das: Legen Sie pro Sprachversion eine eigene Property in der Search Console an. So sehen Sie getrennt, wie domain.com/de/ und domain.com/en/ in den jeweiligen Märkten ranken, und erkennen früh, wenn die falsche Version im falschen Land auftaucht - ein typisches Symptom kaputter hreflang-Tags.

Nutzen Sie zusätzlich den Bericht zur internationalen Ausrichtung, den die Search Console liefert. Er meldet fehlende Rückverknüpfungen und ungültige Sprachcodes direkt, sodass Sie Probleme finden, bevor sie sich auf die Rankings auswirken. Ergänzend hilft der Leistungsbericht, gefiltert nach Land: Steigt der Traffic aus einem Zielmarkt, ist Ihre Ausrichtung dort angekommen. Bleibt er aus, obwohl Sie Inhalte für das Land erstellt haben, ist das ein klares Warnsignal für ein Geotargeting-Problem.

Sprach-Switcher SEO-konform umsetzen

Der Sprachumschalter auf der Website ist oft die unterschätzte Fehlerquelle. Drei Regeln halten ihn sauber:

Erstens: Kein automatischer Redirect anhand der Browser-Sprache oder IP-Adresse. Wenn der Googlebot aus den USA crawlt und automatisch auf die englische Version umgeleitet wird, sieht er Ihre deutschen Seiten nie. Bieten Sie stattdessen einen sichtbaren, manuellen Umschalter an.

Zweitens: Jede Sprachversion braucht eine eigene, crawlbare URL. Sprachwechsel über JavaScript ohne URL-Änderung ist für Suchmaschinen unsichtbar.

Drittens: Verlinken Sie auf die jeweils entsprechende Seite, nicht pauschal auf die Startseite. Wer auf der englischen Produktseite die Sprache wechselt, will die deutsche Produktseite sehen - nicht die deutsche Homepage. Diese Konsistenz ist exakt das, was auch hreflang erwartet, weshalb Switcher und hreflang-Set idealerweise aus derselben Datenquelle generiert werden.

Ein praktischer Nebeneffekt: Wenn Switcher und hreflang aus einer gemeinsamen Konfiguration kommen, können die beiden nicht auseinanderlaufen. Pflegen Sie eine Liste aller Seiten-Entsprechungen je Sprache - etwa in einer zentralen Datendatei oder im CMS - und generieren Sie daraus sowohl die sichtbaren Switcher-Links als auch die hreflang-Tags im Head. Das verhindert genau die Inkonsistenzen, die manuell gepflegte Sets so fehleranfällig machen, und skaliert auch dann noch sauber, wenn weitere Sprachen dazukommen.

Audit-Checkliste für Ihre internationale Website

Bevor Sie eine mehrsprachige Website launchen oder eine bestehende prüfen, gehen Sie diese Punkte durch:

• Architektur passt zum Modell. ccTLD bei starkem Länderbezug, Subdirectory zum Bündeln, Subdomain nur bei technischen Gründen.
• hreflang bidirektional. Jede Verknüpfung besteht in beide Richtungen, inklusive Selbstreferenz.
• x-default gesetzt. Eine Fallback-Version für nicht zugeordnete Nutzer ist definiert.
• Absolute URLs. Alle hreflang-Verweise nutzen vollständige URLs mit Protokoll.
• Indexierbare Ziele. Keine hreflang-Verweise auf Noindex-, 404- oder Redirect-Seiten.
• Eigene Search-Console-Property pro Sprache. Getrenntes Monitoring der Märkte.
• Switcher ohne Auto-Redirect. Manueller Umschalter mit URL-Änderung und seitengenauer Verlinkung.
• Lokalisierter Content. Echte Übersetzung statt automatischer Maschinenübersetzung, inklusive lokaler Währung und Maßeinheiten.

Diese Checkliste deckt die technischen Pflichtpunkte ab. Für ein vollständiges Bild lohnt es sich, regelmäßig einen Crawl mit einem hreflang-fähigen Tool durchzuführen und die Fehlerberichte der Search Console zu prüfen.

Fazit: Erst die Struktur, dann die Technik

Internationale SEO scheitert selten an einzelnen hreflang-Tags und meist an der falschen Grundentscheidung. Wer die Architektur an seinem Geschäftsmodell ausrichtet - ccTLD für lokales Vertrauen, Subdirectory zum Skalieren, Subdomain bei technischer Trennung - baut auf einem stabilen Fundament. Erst darauf folgt die saubere hreflang-Implementierung mit Selbstreferenz, x-default und bidirektionalen Verknüpfungen.

Der Aufwand zahlt sich aus: Eine korrekt aufgesetzte mehrsprachige Website rankt in jedem Zielmarkt mit der richtigen Version, vermeidet Duplicate-Content-Probleme und erschließt Märkte, die monolinguale Wettbewerber nicht erreichen. Wer hier von Anfang an sauber arbeitet, spart sich teure Migrationen später.