International SEO: hreflang, ccTLD oder Subdomain

Wenn Ihre Website mehrere Laender oder Sprachraeume ansprechen soll, fallen die wichtigsten Entscheidungen lange vor dem ersten hreflang-Tag - naemlich bei der URL-Architektur. Die kurze Antwort: Wer auf ein bestimmtes Land mit eigener Marke abzielt, faehrt mit einer ccTLD wie .de oder .fr am besten. Wer dagegen seine Domain-Autoritaet buendeln und schnell skalieren will, waehlt 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 grossem Aufwand und Ranking-Risiko reversibel. Deshalb behandeln wir hier zuerst die Architektur, dann das korrekte hreflang-Setup mit Code-Beispielen, die haeufigsten 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 Geschaeftsmodell

Die Wahl der URL-Struktur haengt weniger von technischen Vorlieben ab als von Ihrem Geschaeftsmodell. 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, Oesterreich 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 buendeln, damit Backlinks und Autoritaet nicht auf Dutzende schwache Einzeldomains verteilt werden.

Ein haeufiger Denkfehler vorab: Sprache und Land sind nicht dasselbe. Spanisch wird in Spanien, Mexiko und Argentinien gesprochen, oft aber mit unterschiedlichen Begriffen, Preisen und Waehrungen. Bevor Sie ueber die Domain-Struktur entscheiden, klaeren Sie, ob Sie reine Sprachversionen brauchen oder echte Laenderversionen mit lokalisiertem Angebot. Diese Antwort bestimmt, ob ein einfaches de ausreicht oder ob Sie bis auf die Ebene de-CH heruntergehen muessen.

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

ccTLD: Maximales lokales Vertrauen

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

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

Vorteile: Das staerkste Geotargeting-Signal ueberhaupt, 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 Autoritaet. Sie brauchen pro Land eigene Backlinks, eigenes Hosting und oft eigene Verwaltung. Bei zehn Maerkten 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 unterschaetzen, wie lange eine neue Landesdomain braucht, um aus dem Stand Rankings aufzubauen - in umkaempften Maerkten oft ein Jahr und mehr.

Subdirectory: Autoritaet buendeln 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-Autoritaet fliesst in eine Domain. Ein Backlink auf die englische Seite staerkt auch die deutsche. Das Setup ist guenstig, schnell erweiterbar und braucht nur ein Hosting. Fuer neue Maerkte legen Sie einfach ein weiteres Verzeichnis an.

Nachteile: Das Geotargeting-Signal ist schwaecher als bei ccTLDs und muss ueber hreflang plus Search-Console-Einstellungen erfolgen. Die Trennung wirkt fuer Nutzer weniger landesspezifisch.

Fuer die meisten Unternehmen mit begrenzten SEO-Ressourcen ist das Subdirectory die pragmatischste Wahl. Genau deshalb betreiben grosse internationale Marken ihre Maerkte fast durchgaengig in dieser Struktur - die gebuendelte Autoritaet wiegt das schwaechere 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 Aenderung ueber fuenf ccTLDs hinweg ausrollen musste, weiss, wie viel Zeit diese Buendelung 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 zustaendig sind. Geotargeting laesst sich pro Subdomain einstellen.

Nachteile: Google behandelt Subdomains teilweise als eigenstaendige Einheiten, sodass die Autoritaet nicht so stark buendelt wie beim Subdirectory. In der Praxis liegen Subdomains beim Linkjuice-Transfer zwischen ccTLD und Verzeichnis.

Subdomains sind dann sinnvoll, wenn technische Gruende fuer eine Trennung sprechen - nicht aber als Standardloesung fuer reine Sprachvarianten.

hreflang-Setup mit konkreten Code-Beispielen

Egal welche Architektur Sie waehlen: Ohne korrektes hreflang erkennt Google nicht, welche Version fuer welchen Nutzer gedacht ist. Das Attribut verknuepft alle Sprachversionen miteinander und verhindert, dass aehnliche 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 fuer 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 ergaenzt um einen Laendercode nach ISO 3166-1 Alpha-2. So unterscheiden Sie etwa Deutsch fuer Deutschland von Deutsch fuer 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 zurueck auf die deutsche zeigen. Fehlt diese Rueckverknuepfung, ignoriert Google das gesamte Tag-Set. Bei vielen Sprachen wird die Pflege aufwendig - alternativ liefern Sie die Verknuepfungen ueber eine XML-Sitemap aus, was bei grossen Seiten oft wartbarer ist. Die vollstaendige Syntax mit allen Sonderfaellen erklaeren wir Schritt fuer Schritt im Beitrag zur korrekten Implementierung von hreflang-Tags.

Haeufige hreflang-Fehler und wie Sie sie vermeiden

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

• Fehlende Rueckverknuepfung. Die haeufigste Ursache fuer ignorierte Tags. Jede Verknuepfung muss in beide Richtungen bestehen.
• Falsche Sprachcodes. en-UK ist ungueltig, korrekt ist en-GB. Auch de-DE als reiner Sprachcode ohne Land funktioniert oft besser, wenn kein Landesbezug noetig ist.
• Fehlende Selbstreferenz. Jede Seite muss sich auch selbst im Set auffuehren, sonst bricht die Logik.
• Relative statt absolute URLs. hreflang braucht immer die vollstaendige URL inklusive Protokoll und Domain.
• Verweise auf Noindex- oder Redirect-Seiten. Ziel-URLs muessen indexierbar sein und mit Status 200 antworten, nicht weiterleiten.

Allein der erste Punkt erklaert einen Grossteil 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. Fuer ein klares Laendersignal nutzen Sie zusaetzliche Hebel - je nach Architektur unterschiedlich.

Bei ccTLDs ist das Geotargeting automatisch gesetzt: .de zielt auf Deutschland, da kann und sollten Sie nichts aendern. Bei generischen Domains (.com, .net, .org) mit Subdomains oder Verzeichnissen war frueher die manuelle Laenderausrichtung in der Search Console moeglich. Diese Funktion wurde abgeschafft - heute steuert Google die geografische Ausrichtung primaer ueber 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 Maerkten ranken, und erkennen frueh, wenn die falsche Version im falschen Land auftaucht - ein typisches Symptom kaputter hreflang-Tags.

Nutzen Sie zusaetzlich den Bericht zur internationalen Ausrichtung, den die Search Console liefert. Er meldet fehlende Rueckverknuepfungen und ungueltige Sprachcodes direkt, sodass Sie Probleme finden, bevor sie sich auf die Rankings auswirken. Ergaenzend hilft der Leistungsbericht, gefiltert nach Land: Steigt der Traffic aus einem Zielmarkt, ist Ihre Ausrichtung dort angekommen. Bleibt er aus, obwohl Sie Inhalte fuer das Land erstellt haben, ist das ein klares Warnsignal fuer ein Geotargeting-Problem.

Sprach-Switcher SEO-konform umsetzen

Der Sprachumschalter auf der Website ist oft die unterschaetzte 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 ueber JavaScript ohne URL-Aenderung ist fuer 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, koennen 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 fehleranfaellig machen, und skaliert auch dann noch sauber, wenn weitere Sprachen dazukommen.

Audit-Checkliste fuer Ihre internationale Website

Bevor Sie eine mehrsprachige Website launchen oder eine bestehende pruefen, gehen Sie diese Punkte durch:

• Architektur passt zum Modell. ccTLD bei starkem Laenderbezug, Subdirectory zum Buendeln, Subdomain nur bei technischen Gruenden.
• hreflang bidirektional. Jede Verknuepfung besteht in beide Richtungen, inklusive Selbstreferenz.
• x-default gesetzt. Eine Fallback-Version fuer nicht zugeordnete Nutzer ist definiert.
• Absolute URLs. Alle hreflang-Verweise nutzen vollstaendige URLs mit Protokoll.
• Indexierbare Ziele. Keine hreflang-Verweise auf Noindex-, 404- oder Redirect-Seiten.
• Eigene Search-Console-Property pro Sprache. Getrenntes Monitoring der Maerkte.
• Switcher ohne Auto-Redirect. Manueller Umschalter mit URL-Aenderung und seitengenauer Verlinkung.
• Lokalisierter Content. Echte Uebersetzung statt automatischer Maschinenuebersetzung, inklusive lokaler Waehrung und Masseinheiten.

Diese Checkliste deckt die technischen Pflichtpunkte ab. Fuer ein vollstaendiges Bild lohnt es sich, regelmaessig einen Crawl mit einem hreflang-faehigen Tool durchzufuehren und die Fehlerberichte der Search Console zu pruefen.

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 Geschaeftsmodell ausrichtet - ccTLD fuer 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 Verknuepfungen.

Der Aufwand zahlt sich aus: Eine korrekt aufgesetzte mehrsprachige Website rankt in jedem Zielmarkt mit der richtigen Version, vermeidet Duplicate-Content-Probleme und erschliesst Maerkte, die monolinguale Wettbewerber nicht erreichen. Wer hier von Anfang an sauber arbeitet, spart sich teure Migrationen spaeter.