← Alle Ressourcen

SEO-Architektur für mehrsprachige B2B-Websites, richtig gemacht.

Hreflang ist zwei Zeilen Markup und das häufigste, was mehrsprachige Seiten falsch machen. Hier ist die Architektur, die wirklich hält, und was Googles eigene Dokumentation sagt gegenüber dem, was die meisten Agentur-Ratschläge annehmen.

Die meisten Probleme mit mehrsprachigem SEO sind keine Übersetzungsprobleme. Es sind Architekturentscheidungen, die einmal, früh, von wem auch immer das CMS eingerichtet hat, getroffen und nie wieder überprüft wurden — bis die Seite bei zehn Sprachen, drei Regionen und einer Rechtsabteilung in jedem Markt angekommen ist, die ihre eigene Version derselben fünf Seiten verlangt. Googles eigene Dokumentation zu Hreflang und internationaler Struktur ist kürzer und großzügiger, als die meisten Online-Ratschläge vermuten lassen: Sie bevorzugt keine URL-Struktur gegenüber einer anderen, und sie ist ausdrücklich darüber, was tatsächlich kaputtgeht. Das ist diese Dokumentation, angewendet auf eine B2B-Seite mit echten, über Sprachen verteilten Einkaufsgremien, nicht auf einen Consumer-Shop.

Die vier URL-Strukturen im Vergleich

StrukturBeispielGoogles HaltungWähle sie, wenn
ccTLDbeispiel.deDas stärkste automatische Geotargeting-Signal, und die meiste Infrastruktur zu betreibenDu betreibst bereits separate juristische Einheiten oder Hosting pro Markt
Subdomainde.beispiel.comFunktioniert, wird aber oft als halb-eigenständige Seite behandelt, was Autorität aufteilen kannDNS oder Hosting erzwingen die Trennung und du akzeptierst den Kompromiss
Unterverzeichnisbeispiel.com/de/Kein Ranking-Nachteil, und jede Seite erbt die bereits bestehende Autorität der DomainDie Standardwahl für die meisten mehrsprachigen B2B-Seiten
URL-Parameterbeispiel.com?lang=deGoogles eigene Dokumentation nennt das „nicht empfohlen“Nie als bewusste Wahl — nur je aus einem alten CMS geerbt

Google sagt klar, dass keine dieser Strukturen einen Ranking-Vorteil gegenüber den anderen hat — die Entscheidung betrifft Kosten, Hosting und Wartung, nicht SEO. Was nicht optional ist: Google überhaupt über die Varianten zu informieren, per Hreflang, Sitemaps oder expliziten Links.

Hreflang: die zwei Regeln, die alles andere kaputtmachen

Zwei Anforderungen verursachen fast jeden Hreflang-Fehler. Erstens die Rückverlinkungs-Regel: Wenn Seite A auf Seite B als deutsche Alternative verweist, muss Seite B zurück auf Seite A verweisen, sonst verwirft Google die gesamte Annotation. Das ist bei zehn Seiten trivial und bricht regelmäßig nach ein paar Hundert, sobald neue Sprachseiten hinzugefügt werden, ohne die Tag-Liste jeder bestehenden Seite neu zu erzeugen. Zweitens: nur gültige Codes — ein Sprachcode aus ISO 639-1, optional kombiniert mit einer Region aus ISO 3166-1 Alpha-2, und nie ein reiner Regionscode allein. „EU“, „UK“ und „UN“ sind verbreitete, auf den ersten Blick plausible Fehler, die Googles Dokumentation ausdrücklich benennt; der Code muss zuerst eine Sprache benennen.

Der x-default-Wert, gerichtet an Besucher, deren Sprache zu keiner Variante passt, braucht keinen eigenen Sprachcode — er braucht nur eine URL, meist eine Sprachauswahlseite oder einen sinnvollen Fallback wie die englische oder die Version des Hauptmarkts. Und jede Seite im Cluster muss sich selbst unter ihren eigenen Hreflang-Tags auflisten, selbstreferenzierend — das Detail, das Teams am häufigsten überspringen, weil es redundant wirkt. Es lohnt sich auch, direkt zu sagen, was Hreflang nicht ist: Googles Dokumentation beschreibt es strikt als Serving-Signal, das den richtigen Besucher zur richtigen Variante leitet. Für sich genommen ist es kein Ranking-Signal.

Duplicate Content über Sprachen hinweg ist nicht das Risiko, das die meisten vermuten

Inhalt, der auf Deutsch und auf Englisch dasselbe sagt, ist in keinem Sinn, der Rankings kostet, Duplicate Content — Google behandelt jede Sprache als eigenes Publikum und indexiert jede Version nach eigenem Verdienst. Das eigentliche Duplicate-Content-Risiko bei mehrsprachigem B2B liegt an einer weniger offensichtlichen Stelle: nahezu identische Seiten in derselben Sprache für unterschiedliche Regionen. Eine en-GB-Seite und eine en-US-Seite, die sich nur bei Währung und einem Absatz Rechtstext unterscheiden, konkurrieren tatsächlich um dieselbe Suchanfrage im selben Index — auf eine Art, wie es eine englische und eine deutsche Seite nie tun werden.

Die Lösung ist entweder Konsolidierung — eine englische Seite mit einem Canonical statt drei nahezu-Duplikaten — oder den regionalen Unterschied echt zu machen: eigene Preise, eigene Case Studies, eigene Compliance-Texte, nicht nur ein ausgetauschtes Währungssymbol in einem Template. Und wo Hreflang und Canonical auf derselben Seite existieren, müssen sie übereinstimmen — ein Canonical, der auf eine andere URL zeigt als die, die Hreflang bereits als maßgeblich für diese Sprache erklärt hat, ist ein Widerspruch, den Google an deiner Stelle auflösen muss, und nicht immer so, wie du es wählen würdest.

Was hier bei B2B-Käufern tatsächlich anders ist

Eine B2B-Kaufentscheidung ist selten die einer einzigen Person, und sie läuft selten vollständig in einer Sprache ab, selbst innerhalb desselben Unternehmens — Gartners Forschung zur B2B-Buying-Journey findet typischerweise sechs bis zehn Stakeholder, die eine einzelne Kaufentscheidung prägen, jeder sammelt unabhängig Informationen, bevor überhaupt jemand mit einem Anbieter spricht, und verbringt nur etwa 17% der gesamten Kaufreise in Meetings mit Anbietern. Ein Einkaufsverantwortlicher, der in seiner Arbeitssprache recherchiert, ein technischer Bewerter, der Dokumentation unabhängig vom Markt auf Englisch liest, und ein regionaler Entscheider, der die Seite in seiner eigenen Sprache will, sind häufig drei verschiedene Personen im selben Deal — und alle drei brauchen eine Seite, die in welcher Sprache auch immer sie landen, trägt.

Hier zeigt sich auch eine rein mechanische Übersetzung. Eine Seite, die grammatikalisch korrekt ist, sich aber erkennbar übersetzt liest, untergräbt genau die Glaubwürdigkeit, auf die ein technischer Käufer dich prüft. Die globale Verbraucherstudie von CSA Research fand, dass 76% der Befragten bevorzugt dort kaufen, wo Informationen in ihrer eigenen Sprache präsentiert werden, und dass Unternehmen dafür eher noch empfindlicher sind als einzelne Konsumenten — weil ein B2B-Käufer implizit auch beurteilt, ob deine Organisation sein lokales Team nach Vertragsabschluss unterstützen kann, und dünne, offensichtlich maschinell übersetzte Seiten eine sichtbare Antwort auf diese Frage sind, noch bevor sie jemand direkt stellt.

Wo mehrsprachige B2B-Seiten tatsächlich Rankings verlieren

Über kaputtes Hreflang hinaus sind die wiederkehrenden Fehler strukturell, nicht sprachlich. Eine Sitemap, die nur die URLs der Standardsprache listet, sodass neu hinzugefügte Sprachvarianten nie von selbst gefunden werden. Strukturierte Daten, die nicht lokalisiert bleiben — ein inLanguage-Feld, das auf jeder Seite „en“ sagt, unabhängig davon, welche Sprache es tatsächlich ist, was genau das maschinenlesbare Signal leise schwächt, das eigentlich helfen soll. Maschinell übersetzter Inhalt, veröffentlicht ohne jede menschliche Prüfung, der beim flüchtigen Lesen akzeptabel wirkt, aber der Prüfung nicht standhält, die sowohl ein echter Käufer als auch ein qualitätsorientierter Crawler anwenden.

Und, weniger offensichtlich: Währung, Datumsformate und rechtliche Hinweise, die in jedem Locale in der Konvention des Ursprungsmarkts bleiben, weil ein einmal für den Heimatmarkt gebautes Template kopiert statt wirklich angepasst wird. Nichts davon ist eine Ranking-Strafe im algorithmischen Sinn. Alles davon sind Vertrauenssignale, die ein aufmerksamer Käufer — Mensch oder automatisiert — als Beleg dafür liest, dass die „lokalisierte“ Version übersetzt, nicht gebaut wurde.

Wie wir das in der Praxis angehen

Ein Mehrsprachige Website-Projekt beginnt mit den strukturellen Entscheidungen aus diesem Leitfaden — Unterverzeichnis versus Subdomain, die Hreflang-Karte, Sitemap- und Canonical-Strategie — bevor auch nur eine Seite übersetzt wird, denn die Architektur nachträglich zu reparieren, nachdem Inhalt bereits in fünf Sprachen existiert, ist eine deutlich größere Aufgabe, als sie vorab zu entscheiden.

Wenn du Sprachen zu einer Seite hinzufügst, die in ihrem ursprünglichen Markt bereits gut rankt, ist ein Technisches Audit der richtige Startpunkt, statt direkt zur Übersetzung zu springen — es sagt dir, was die bestehende Architektur trägt und was nicht, bevor du Inhalt darauf festlegst. Und sobald die Struktur stimmt, muss die SEO Starter-Arbeit — Titel, Meta, interne Verlinkung, Schema — pro Locale erledigt werden, nicht einmal und kopiert, aus demselben Grund, aus dem sich ein unangepasst kopiertes Template dünn liest.

Quellen

Die Hreflang-Regeln, die Empfehlungen zur URL-Struktur und die Zahlen zum Käuferverhalten oben stammen aus diesen Quellen, geprüft im August 2026.

Häufig gestellte Fragen

Expandierst du in neue Märkte und bist unsicher, ob die aktuelle Seite das trägt?

Wir prüfen die bestehende Architektur und sagen dir genau, was sich ändern muss, bevor du eine weitere Sprache hinzufügst.