Locales aus realem Inhalt und Betriebsverpflichtungen wählen
Ein Locale ist die Sprache und – nur wenn es relevant ist – das regionale Publikum einer Seite. Führen Sie eine Matrix mit Seitentyp, Sprache, Region, Owner, Inhaltsunterschieden, URL‑Muster und Fallback. Fügen Sie eine regionale Version nur hinzu, wenn sich der Hauptinhalt oder kommerzielle Bedingungen tatsächlich unterscheiden und jemand sie aktuell halten kann; eine generische Sprachseite ist oft die bessere Wahl.
Übersetzen Sie nicht nur Header und Footer um unveränderten Hauptinhalt und nennen Sie es lokal. Google warnt, dass nur Boilerplate‑Übersetzung zu einer schlechten Erfahrung und wiederholten Ergebnissen führen kann. Prüfen Sie prioritären Text, Preise, Verfügbarkeit, Richtlinien, Support und transaktionale Meldungen. Wenn eine Seite noch nicht unterstützt werden kann, lassen Sie sie weg, statt eine irreführende Hülle zu veröffentlichen.
Halten Sie den vorgesehenen Code, das öffentliche URL‑Muster, den Owner, das Canonical‑Ziel, den Fallback und den Launch‑Status in einer gesteuerten Tabelle fest.
Stabile URLs verwenden und Menschen wählen lassen
Geben Sie jeder Sprachversion eine direkte URL, die ein Browser und ein Crawler anfragen können. Google empfiehlt unterschiedliche URLs statt der Veränderung der Sprache über Cookies oder Browsereinstellungen. Länderdomains, Subdomains und Unterverzeichnisse können funktionieren; wählen Sie das Muster, das Ihr Team konsistent verwalten kann. Google zählt URL‑Parameter zu den nicht empfohlenen Methoden für URL‑basierte Segmentierung.
Zeigen Sie eine Sprach‑ oder Region‑Auswahl und halten Sie einen Besucher auf der gewählten Version. Google rät von automatischen Redirects aufgrund vermuteter Sprache ab und weist darauf hin, dass dynamische Änderungen die Entdeckung von Varianten verhindern können. Verwenden Sie nicht die IP‑Location als Entscheidungsmechanismus; Google nennt sie schwierig, allgemein unzuverlässig und potenziell crawler‑limitierend. Erhalten Sie direkte URLs und eine einfache Möglichkeit, zurückzuschalten.
Öffnen Sie jede Locale‑URL in einer sauberen Session und bestätigen Sie, dass sie diese Version ohne standortbasierte Umleitung ausliefert.
Vollständige, gültige hreflang‑Cluster aufbauen
Ein hreflang‑Cluster verbindet äquivalente Locale‑URLs. Google unterstützt HTML link‑Elemente, HTTP Link‑Header für Nicht‑HTML‑Antworten oder Einträge in XML‑Sitemaps und behandelt die Methoden als gleichwertig. Wählen Sie die Methode, die Ihr Release‑Prozess generieren und prüfen kann. Jede Alternativ‑URL muss vollständig qualifiziert sein, einschließlich https, und auf die beabsichtigte öffentliche Seite auflösen.
Veröffentlichen Sie auf jeder äquivalenten Seite denselben Satz: eine Selbstreferenz und jede unterstützte Alternative. Google sagt, Tags können ignoriert werden, wenn Seiten nicht zueinander verweisen, und identifiziert fehlende Rückverweise als einen häufigen Fehler. Generieren Sie Cluster aus gemeinsamen Quelldaten, nicht aus manuell bearbeiteten Templates. Wenn eine Seite in einer Locale nicht verfügbar ist, erfinden Sie keinen näheren Treffer, nur um das Gitter zu füllen.
Überprüfen Sie für jedes gelistete Paar, dass beide Seiten dieselbe Alternativmenge ausliefern, einschließlich ihrer eigenen URL.
Verwenden Sie die HTTP Link‑Header‑Methode für lokalisierte PDFs, wenn HTML‑Head‑Markup nicht verfügbar ist.
Sprach‑Tags mit Blick auf die Such‑Implementierung wählen
Sprach‑Tags sind Kennungen wie en, en-GB oder zh-Hant. BCP 47 ist der IETF‑Best‑Current‑Practice‑Rahmen, und das IANA Language Subtag Registry ist das Referenzregister, auf das W3C Autoren verweist. Beginnen Sie mit einer primären Sprache und fügen Sie Script oder Region nur hinzu, wenn sie den Inhalt unterscheidet. W3C rät, Tags so kurz wie nötig zu halten.
Für Google hreflang folgen Sie Googles unterstützten Codes, nicht jedem syntaktisch gültigen BCP‑47‑Tag. Google verlangt eine Sprache zuerst, niemals nur eine Region, und dokumentiert ISO 639‑1 Sprachcodes mit optionalen ISO 3166‑1 Alpha‑2 Regionen. Es sagt ausdrücklich, dass es es-419 für hreflang nicht unterstützt. Prüfen Sie Codes während der Implementierung und lehnen Sie improvisierte Werte in Deployment‑Checks ab.
Verwenden Sie en-GB nur, wenn die UK‑Version sich bedeutsam unterscheidet; andernfalls ist eine generische en‑Version einfacher.
Canonical, Fallback und Inhalts‑Signale kompatibel halten
Canonicalisierung wählt eine bevorzugte URL unter doppelten oder sehr ähnlichen URLs; hreflang identifiziert beabsichtigte Alternativen. Für unabhängige Locale‑Seiten verwenden Sie ein selbstreferenzielles Canonical oder ein Canonical in derselben Sprache. Google empfiehlt ein Canonical in derselben Sprache oder die bestmögliche verfügbare Alternative. Ein sprachenübergreifendes Canonical kann die Alternative, die Sie präsentieren wollten, wegkonsolidieren.
Verwenden Sie x-default für Personen, deren Browser‑Sprache nicht mit einer gelisteten Version übereinstimmt, insbesondere in Kombination mit einem Sprach‑ oder Länderauswahl‑Selector. Es ist ein Fallback, kein Ersatz für echte Alternativen. Entscheiden Sie, ob es ein neutraler Selector oder eine Standard‑Sprache ist, machen Sie es nutzbar und vermeiden Sie automatische Redirect‑Schleifen. Halten Sie die sichtbaren Hauptinhalte jeder Seite klar in einer Sprache.
Vergleichen Sie angeforderte URL, finale URL, Canonical, Indexierbarkeit, hreflang‑Ziele und Sitemap‑Eintrag bei jeder Stichprobe.
Release als Routing‑ und Inhaltsänderung testen
Testen Sie vor dem Deployment jeden Template‑Typ stichprobenartig: Startseite, Kategorie, Commerce, Redaktionell, Hilfe und lokalisierte Dateien. Untersuchen Sie den gelieferten Head, Header oder die Sitemap je nach gewählter Methode. Bestätigen Sie öffentliche Antworten, finale HTTPS‑URLs, Selbst‑ und reziproke Alternativen, Canonical‑Ziele, sichtbaren lokalen Inhalt, einen funktionierenden Switcher und keine versehentlichen noindex‑ oder robots‑Blockaden.
Nach dem Release prüfen Sie repräsentative Seiten in der Search Console. Ihr Live‑Test prüft, ob Google eine aktuelle Seite erreichen kann; der Indexbericht kann das ausgewählte Canonical zeigen. Der Live‑Test kann jedoch das gewählte Canonical nicht vorhersagen oder die Indexierung garantieren. Führen Sie ein datiertes Release‑Log mit getesteten Clustern, Ausnahmen, Ownern und Retest‑Nachweisen.
Blockieren Sie den Release, wenn eine prioritäre Seite falsch weiterleitet, ein reziprokes Paar defekt ist, ein Konflikt mit dem Canonical besteht oder die Seite nicht auswählbar ist.
Versionieren Sie Locale‑Konfigurationen und behalten Sie die vorherige URL‑ und Annotierungs‑Map für eine sichere Rückrolle bei gemeinsamen Templates.