Ein Kunde kam 2021 mit einer WordPress-E-Commerce-Website zu mir, die sieben Länder anzielte. Sie hatten eine Übersetzungsagentur beauftragt, alles in WPML eingepflegt und das für erledigt erklärt. Organic Traffic in fünf dieser sieben Märkte war praktisch null. Nicht niedrig. Null. Die deutschen Seiten kannibalisieren die englischen. Die arabischen Seiten hatten nirgendswo ein dir="rtl"-Attribut. Und die hreflang-Tags? Sie wiesen auf URLs, die mit 301-Redirects auf völlig andere Seiten verwiesen.dir="rtl" attribute anywhere. And the hreflang tags? Pointing at URLs that 301-redirected to completely different pages.
Das war ein dreimonatiger Reparaturauftrag. Ich habe fair abgerechnet, aber ich denke seitdem immer wieder darüber nach, denn jedes einzelne Problem auf dieser Website hätte mit einer anständigen Checkliste vor dem Launch verhindert werden können.
Also hier ist meine. Die genaue Reihenfolge, in der ich sie durchlaufe, die Tools, die ich wirklich öffne, und die Dinge, die selbst erfahrene Entwickler noch erwischen.
---
Mit der URL-Struktur beginnen (Bevor du irgendwas anderes anfängst)
Diese Entscheidung ist permanent. Oder zumindest nah genug daran, dass du sie so behandeln solltest. Ich habe schon gesehen, wie Agenturen URL-Strukturen auf aktiven mehrsprachigen Websites ändern und dann sechs Monate Link-Equity verdampfen sehen.
Du hast drei Optionen: Unterverzeichnisse (/fr/), Subdomains (fr.), oder ccTLDs (site.fr). Googles eigene Dokumentation zum internationalen Targeting ist ziemlich deutlich, dass alle drei funktionieren, aber die Kompromisse sind real./fr/), subdomains ( fr.), or ccTLDs ( site.fr). Google's own documentation on international targeting is pretty clear that all three work, but the trade-offs are real.
Bei den meisten meiner Kunden wähle ich Unterverzeichnisse. Eine Domain, ein Authority-Pool, ein Crawl-Budget zum Verwalten. Subdomains machen Sinn, wenn du wirklich separate Teams hast, die separate Operationen laufen lassen (Seahawk hatte mal einen SaaS-Kunden, wo die US- und EU-Produkte tatsächlich unterschiedliche regulatorische Produkte waren, da waren Subdomains genau richtig). ccTLDs sind für Unternehmen mit ernsthafter lokaler Brand-Präsenz und dem Budget, um Domain-Authority separat für jede aufzubauen.
Wähl eine aus. Dokumentiere es. Hole Freigabe ein, bevor jemand auch nur eine Zeile Template-Code schreibt.
Der Eine-Subfolder-Fehler, den ich immer wieder sehe
Leute packen die Standardsprache unter /en/, ohne einen ordentlichen Redirect vom Root einzurichten. Also site.com/ gibt eine 200 zurück ohne hreflang, site.com/en/ hat all den Content, und Google indexiert beide als separate Thin Pages. Stelle deinen Root so ein, dass er basierend auf Accept-Language zur richtigen Locale redirected, oder lass den Root einfach direkt die Standardlocale servieren. Lass ihn nicht hängen./en/ without setting up a proper redirect from the root. So site.com/ returns a 200 with no hreflang, site.com/en/ has all the content, and Google indexes both as separate thin pages. Set your root to redirect to the appropriate locale based on Accept-Language, or just make the root serve the default locale directly. Don't leave it dangling.
---
Hreflang: Mach es richtig oder lass es sein
Hreflang ist das Bit, das die meisten Entwickler nervös macht. Zu Recht. Es ist knifflig.
Der Hreflang-Spec von Google sagt dir, dass du language-region codes verwenden sollst (en-GB, fr-FR), die Tags selbstreferenziell machst (jede Seite referenziert sich selbst), und die Beziehung bidirektional machst (wenn /fr/ auf /en/ verweist, dann muss /en/ zurück auf /fr/ verweisen). Verpasst du eine davon, bricht das ganze Ding stillschweigend zusammen. Google wirft keine Manual Action. Es ignoriert einfach deine Tags und rät.hreflang spec from Google tells you to use language-region codes (en-GB , fr-FR ), make the tags self-referential (every page references itself), and make the relationship bidirectional (if /fr/ points to /en/, then /en/ must point back to /fr/). Miss any of those and the whole thing breaks silently. Google won't throw a manual action. It just ignores your tags and guesses.
So sieht mein eigentlicher Workflow aus:
- Erstelle zunächst die vollständige URL-Matrix in einem Tabellenkalkulationsprogramm. Jedes Locale, jede entsprechende Seiten-URL.
- Implementiere über den <head> statt über Sitemaps, wo immer möglich. Sitemaps funktionieren, aber die <head>-Implementierung lässt sich einfacher überprüfen, indem man nur die Quelle anschaut.
<head>rather than sitemaps wherever possible. Sitemaps work, but<head>implementation is easier to audit by just viewing source. - Führe Screaming Frog über die Staging-Site mit aktivierter hreflang-Überprüfung aus. Exportiere den Issues-Report.Screaming Frog over the staging site with hreflang auditing enabled. Export the issues report.
- Gleiche mit Ahrefs' Site Audit ab, um verwaiste Locale-Seiten zu finden (Seiten in einer Sprache ohne hreflang, die auf Entsprechungen in anderen Sprachen verweisen).
- Überprüfe 10–15 Seiten manuell stichprobenartig. Schau dir einfach die Quelle an. Suche nach dem Muster.
Eine Sache, bei der Menschen ständig falsch liegen: x-default. Das ist nicht „die englische Version". Es ist das Fallback für Nutzer, deren Sprache keinem deiner Locale-Tags entspricht. Wenn du gezielt en-GB und en-US anvisierst, braucht ein kanadischer Englischsprachiger irgendwo einen Landepoint. Das ist x-default. Verweise darauf auf deine relevanteste Catch-All-Seite, normalerweise die Root oder eine Language-Selector-Seite.x-default . It's not "the English version". It's the fallback for users whose language doesn't match any of your locale tags. If you're targeting en-GB and en-US specifically, a Canadian English speaker needs somewhere to land. That's x-default. Point it at your most relevant catch-all page, usually the root or a language-selector page.
---
Crawl Budget und Indexierung
Bei kleinen Sites spielt das keine große Rolle. Bei einer Site mit 50.000 Seiten über 8 Sprachen hinweg ist es absolut entscheidend.
Die Mathematik ist einfach: Hat deine englische Website 6.000 Seiten und fügst 7 Sprachen hinzu, hast du potentiell 48.000 Seiten, die alle gecrawlt und indexiert werden müssen. Die meisten Websites haben weder die Autorität noch die interne Linkstruktur, um das effizient zu unterstützen.
Das mache ich:
- Audit, welche Seiten tatsächlich eine Übersetzung rechtfertigen. Nicht alles braucht eine. Blogbeiträge von 2017, die auf Englisch 3 Besuche pro Monat bekommen, brauchen keine französische Version.
- Nutze separate locale-spezifische Sitemaps (sitemap-fr.xml, sitemap-de.xml) und referenziere sie alle in sitemap-index.xml. Google Search Console lässt dich jede einzeln einreichen und überwachen, was Debugging deutlich vereinfacht.
sitemap-fr.xml,sitemap-de.xml) and reference them all fromsitemap-index.xml. Google Search Console lets you submit and monitor each separately, which is far easier to debug. - Überprüfe Crawl-Statistiken in Search Console pro Property, falls du Subdomains oder ccTLDs nutzt. Für Unterverzeichnisse auf einer Domain nutze den Coverage Report gefiltert nach URL-Pfad.
- Markiere dünne oder maschinell übersetzte Seiten, die du noch nicht überprüft hast, mit Noindex. Ernsthaft. Eine Seite, die Google als Spam-Content indexiert, schadet der gesamten Domain.
Ein Client aus dem Reisesektor startete 2019 mit 12 Sprachversionen, alle maschinell von DeepL übersetzt ohne menschliche Überprüfung. Solider Traffic auf Englisch, zerstört innerhalb von 8 Wochen in jeder anderen Sprache. DeepL ist ein großartiges Tool (ich nutze es immer noch als Ersten Entwurf), aber ungeprüfte Ausgaben im großen Maßstab sind ein Vertrauenssignal-Albtraum.
---
Übersetzung vs. Transcreation
Diese Unterscheidung ist wichtiger, als die meisten Technical SEOs zugeben.
Übersetzung konvertiert Wörter. Transkription konvertiert Intent, Ton und kulturellen Kontext. Für Landing Pages, Produktbeschreibungen und alles, wofür du Geld ausgibst um zu ranken, willst du Transkription.
Das praktische Checklisten-Element hier: Für jeden Zielmarkt lässt du mindestens die Top 20 Seiten nach Traffic-Potenzial von einem Native Speaker überprüfen. Nicht nur auf Grammatik. Darauf, ob sich die Copy wie ein echter Mensch in dieser Sprache anfühlt oder wie eine Maschine, die die Sprache aus Bedienungsanleitungen gelernt hat.
Keyword-Recherche ist pro Locale separat. Ich nutze Ahrefs dafür. Das deutsche Keyword für ein Konzept ist nicht einfach das deutsche Wort für das englische Keyword. Suchverhalten unterscheidet sich. In manchen Märkten suchen Nutzer formaler. In anderen nutzen sie Abkürzungen oder Slang, die nie in einer direkten Übersetzung auftauchen würden. Erstelle Keyword-Maps pro Locale. Es dauert länger. Es lohnt sich.
Was man mit Märkten macht, die man nicht richtig transkribieren kann
Sei ehrlich mit dir selbst. Wenn du Deutsch jetzt nicht richtig machen kannst, starte Deutsch nicht. Eine mittelmäßige mehrsprachige Präsenz ist schlechter als keine mehrsprachige Präsenz. Googlebot gibt dir keinen Kredit dafür, dass du es versuchst.
---
Technische On-Page-Checks pro Locale
Das ist der undankbare Teil. Aber hier sind die Wins.
- `lang`-Attribut auf dem `<html>`-Element. Sollte dem Locale der Seite entsprechen. <html lang="de-DE">. Überprüfe jedes Template, nicht nur die Homepage. Should match the locale of the page.
<html lang="fr-FR">. Check every template, not just the homepage. - `dir`-Attribut für RTL-Sprachen. Arabisch, Hebräisch, Urdu, Persisch: <html dir="rtl">. Und überprüfe, dass dein CSS es tatsächlich unterstützt, nicht nur das HTML-Attribut. Arabic, Hebrew, Urdu, Persian:
<html dir="rtl">. And check that your CSS actually supports it, not just the HTML attribute. - Canonical-Tags. Jede lokalisierte Seite sollte sich selbst kanonisieren. Die französische Seite kanonisiert sich selbst, nicht zur englischen Entsprechung. Ich habe das schon öfter falsch gesehen, als ich zählen kann. Each localised page should self-canonicalise. The French page canonicalises to itself, not to the English equivalent. I've seen this wrong more times than I can count.
- Meta-Titel und Beschreibungen. Übersetzt und für jedes Sprachgebiet angepasst. Nicht auf Englisch belassen. Nicht automatisch aus einem Template mit [Seitenname] | [Website-Name] und einer maschinell übersetzten Tagline generiert. Translated and adapted per locale. Not left in English. Not auto-generated from a template with
[Page Name] | [Site Name]and a machine-translated tagline. - Strukturierte Daten. Wenn du Schema.org-Markup verwendest, sollte die inLanguage-Eigenschaft die Sprache der Seite widerspiegeln. Im E-Commerce überprüfe, dass priceCurrency der erwarteten Währung des Sprachgebiets entspricht. If you're using Schema.org markup, the
inLanguageproperty should reflect the page's language. For e-commerce, check thatpriceCurrencymatches the locale's expected currency. - Bildalternativtexte. Übersetzt. Oft übersehen, weil sie nicht sichtbar sind. Immer überprüft. Translated. Often overlooked because it's not visible. Always checked.
Ich nutze ein einfaches Google Sheet mit all diesen Elementen als Spaltenüberschriften. Eine Zeile pro Sprachgebiet. Abhaken, wenn überprüft. Mit dem Kunden teilen, damit er versteht, was kontrolliert wurde.
---
Lokale Suche und Google Business Profile
Für Kunden mit physischen Standorten über mehrere Märkte hinweg endet mehrsprachige SEO nicht bei der Website.
Google Business Profile unterstützt mehrere Sprachen für die Geschäftsbeschreibung und Service-Angebote. Stelle die primäre Sprache pro Standort richtig ein. Wenn du ein Büro in Paris hast, sollte das GBP für diesen Standort auf Französisch sein, mit einer französischsprachigen Beschreibung, nicht eins zu eins kopiert vom englischen Hauptsitz-Profil.
NAP-Konsistenz (Name, Adresse, Telefon) über lokale Branchenverzeichnisse hinweg ist pro Markt wichtig. In Deutschland bedeutet das, sicherzustellen, dass die Eintrag korrekt auf Das Örtliche und Gelbe Seiten ist, nicht nur auf Google. In Frankreich PagesJaunes. Jeder Markt hat sein eigenes Citation-Ökosystem. Ein Nachmittag damit, die Top-10-Citation-Quellen pro Zielland zu kartografieren, ist gut investierte Zeit.
---
Überwachung nach dem Launch
Der Launch ist nicht das Ende. Er ist der Anfang herauszufinden, was du übersehen hast.
Mein Setup zur Überwachung nach dem Launch für mehrsprachige Websites:
- Richte Google Search Console separat pro Sprache ein (Subdomain oder ccTLD) oder nutze die URL-Präfix-Eigenschaft pro Verzeichnispfad.
- Überprüfe den Bericht "Internationale Ausrichtung" in der Search Console unter "Legacytools". Er zeigt dir hreflang-Fehler innerhalb weniger Wochen nach dem Launch auf.
- Richte Ranking-Tracking in Ahrefs pro Sprache ein und nutze dabei die richtige Länder-/Sprachausrichtung. Ein Keyword, das in "English, US" getrackt wird, zeigt dir andere Positionen als dasselbe Keyword in "German, Germany".
- Überwache die Crawl-Abdeckung in den ersten 6 Monaten monatlich. Neue Seiten einer Sprache bleiben manchmal für Wochen in "Entdeckt, aber nicht indexiert" stecken. Meistens ist das ein Crawl-Budget- oder internes Linking-Problem.
- Überprüfe vierteljährlich auf Kannibalisierung. Zwei Seiten einer Sprache, die um dieselbe Query im selben Land konkurrieren, sind ein Zeichen, dass etwas bei der URL- oder hreflang-Einrichtung schief gelaufen ist.
Eine Sache, die ich nach einer schmerzhaften Erfahrung mit einem Fintech-Kunden auf meine Checkliste gesetzt habe: Stelle sicher, dass IP-basierte Redirects dein hreflang nicht überschreiben. Wenn dein CDN oder Server Nutzer basierend auf IP-Geolokalisierung umleitet, sieht Googlebot (das normalerweise von US-IPs aus crawlt) deine nicht-englischen Seiten möglicherweise nie. Jener Fintech-Kunde hatte CloudFront-Regeln, die aggressive Weiterleitungen für nicht-US-IPs durchführten. Es hat uns zwei Wochen gedauert, herauszufinden, warum die europäischen Seiten überhaupt nicht indexiert waren.check that IP-based redirects aren't overriding hreflang. If your CDN or server is redirecting users based on IP geolocation, Googlebot (which usually crawls from US IPs) might never see your non-English pages. That fintech client had CloudFront rules aggressively redirecting non-US IPs. Took us two weeks to diagnose why the European pages had zero indexation.
---
FAQ
Brauche ich eine separate Google Search Console Property für jede Sprache?
Nicht unbedingt. Wenn du Unterverzeichnisse auf einer Domain verwendest (wie site.com/de/), kannst du eine URL-Prefix-Property pro Unterverzeichnis nutzen oder einfach die Root-Domain-Property verwenden und nach URL-Pfad filtern. Bei Subdomains oder separaten ccTLDs lohnt sich der administrative Aufwand für separate Properties, weil du sauberere Daten pro Markt erhältst.site.com/fr/), you can use a URL-prefix property per subdirectory, or just use the root domain property and filter by URL path. If you're on subdomains or separate ccTLDs, separate properties are worth the admin overhead because you get cleaner data per market.
Ist maschinelle Übersetzung 2024 ausreichend für SEO?
Für einen ersten Entwurf ja. Zum Veröffentlichen ohne menschliche Überprüfung nein. DeepL und Google Translate sind wirklich gut geworden, aber sie erzeugen Inhalte, die grammatikalisch korrekt und tonlich flach sind. Suchmaschinen werden immer besser darin, zwischen Inhalten zu unterscheiden, die sich natürlich in einer Sprache lesen, und Inhalten, die übersetzt wurden. Nutze maschinelle Übersetzung, um schnell voranzukommen, dann lasse einen Muttersprachler die hochwertigen Seiten vor der Indexierung überprüfen.
Wie gehe ich mit einem Markt um, in dem ich nur teilweise Übersetzungsabdeckung habe?
Noindex die unübersetzten oder teilweise übersetzten Seiten, bis sie fertig sind. Veröffentliche keine halbfertigen Locale-Seiten, nur um sie live zu haben. Der Schaden an Vertrauenssignalen durch dünne Inhalte in einer Sprache ist schwerer rückgängig zu machen als die Verzögerung beim Launch.
Was ist der häufigste hreflang-Fehler?
Das fehlende Self-Referential-Tag. Jede Seite braucht ein hreflang-Tag, das auf sich selbst verweist, zusätzlich zu den Tags, die auf alle ihre Äquivalente verweisen. Entwickler implementieren die Cross-References oft korrekt und vergessen die Self-Reference. Screaming Frog findet das in etwa 30 Sekunden, führe es vor jedem Launch aus.
Sollte ich URLs übersetzen oder auf Englisch belassen?
Übersetzen Sie sie. /de/schuhe/ übertrifft /de/shoes/ bei der deutschen Suche, weil der URL-Slug zu Relevanzsignalen beiträgt. Es wirkt auch vertrauenswürdiger auf deutschsprachige Nutzer. Der zusätzliche Implementierungsaufwand (Sie benötigen lokale Routing-Regeln und Slug-Übersetzung in Ihrem CMS) lohnt sich für jeden Markt, den Sie ernsthaft anvisieren./fr/chaussures/ outperforms /fr/shoes/ in French search because the slug contributes to relevance signals. It also looks more trustworthy to French-speaking users. The extra implementation effort (you need locale-specific routing and slug translation in your CMS) is worth it for any market you're seriously targeting.
---
Mehrsprachiges SEO ist kein Kästchen, das Sie einmal abhaken. Es ist eine Disziplin. Die obige Checkliste hat mich mehr Male vor teuren Problemen nach dem Launch bewahrt, als mir lieb ist, und sie entwickelt sich immer noch weiter. Jedes neue Projekt lehrt mich etwas Neues. Kürzlich am wichtigsten: Überprüfen Sie immer, was das CDN mit Anfragen in nicht-Standard-Locales tut, bevor Sie eine Website für fertig erklären. Immer.