Universally Dokumentation

Schritt-für-Schritt-Anleitungen, mehrsprachige SEO-Tipps und Best Practices, die Ihnen helfen, Ihre WordPress-Website zu übersetzen und zu skalieren.

Vorhandene URLs und Weiterleitungen

Ihre bestehenden URLs bleiben unverändert. Übersetzte Versionen werden daneben hinzugefügt, sodass nichts, was Sie bereits veröffentlicht haben, verschoben oder beschädigt wird.

Nichts ändert sich an Ihren Originalseiten

example.com/pricing/ funktioniert weiterhin genau wie zuvor, unter derselben URL, in derselben Sprache. Universally fügt example.com/es/pricing/ daneben hinzu.

Das bedeutet:

  • Kein bestehender Link, weder intern noch extern, wird unterbrochen
  • Kein bestehendes Suchranking wird gestört, da sich die Seite nicht verschoben hat
  • Ihre Quellsprache bleibt im Stammverzeichnis, ohne Präfix

Auf einer übersetzten Seite werden interne Links so umgeschrieben, dass der Besucher in seiner Sprache bleibt. Von /es/pricing/ wird ein Link zu /features/ zu /es/features/, sodass das Surfen nicht stillschweigend in die Quellsprache zurückfällt.

Einige Pfade sollten nicht umgeschrieben werden, wie z. B. Asset-URLs, API-Endpunkte und Feeds. Diese sind unter Link-Lokalisierung ausschließen aufgeführt. Siehe Link-Lokalisierung ausschließen.

Wie Besucher eine übersetzte Seite erreichen

Über den Sprachumschalter, einen Link zur übersetzten URL oder aus Suchergebnissen, da übersetzte Seiten eigenständig indiziert werden.

Es gibt keine automatische Weiterleitung basierend auf der Browsersprache. Nichts liest die Spracheinstellung des Browsers, sodass ein Erstbesucher, der Ihre Stamm-URL aufruft, Ihre Quellsprache erhält, unabhängig davon, was sein Browser anfordert. Wenn Sie eine sprachbasierte Weiterleitung wünschen, muss diese auf Ihrer eigenen Edge- oder Server-Ebene implementiert werden.

Dies ist beabsichtigt und kein Fehler: Eine automatische Sprachweiterleitung ist eine häufige Fehlerquelle, da sie eine explizite Wahl überschreibt und Such-Crawler etwas anderes sehen als Benutzer.

Die vom Besucher gewählte Sprache wird gespeichert

Die eigene Wahl eines Besuchers ist eine andere Sache, und dies ist das Verhalten, das Sie kennen sollten, bevor Sie einen Cache konfigurieren.

Das Aufrufen einer übersetzten URL speichert diese Sprache für 30 Tage in einem universally_lang-Cookie. Solange es gesetzt ist, wird eine Anfrage an eine URL ohne Sprachpräfix zur selben Seite in der gespeicherten Sprache weitergeleitet. Ein wiederkehrender Besucher Ihrer Stamm-URL erhält also nicht die Quellsprache, sondern seine eigene.

Der Weg zurück ist der Link zur Quellsprache des Umschalters, der ?universally_switch=source trägt. Dies löscht das Cookie und leitet den Besucher zur ungeprägten URL zurück. Ein einfacher Link zur Quell-URL löscht es nicht, sodass die Weiterleitung erneut erfolgt.

Die Weiterleitung wird für WordPress-Systempfade (/wp-admin/, /wp-json/, wp-login.php und andere), für alles, was wie eine Datei aussieht (sitemap.xml, robots.txt, favicon.ico) und für Pfade unter Seiten ausschließen übersprungen.

Da die Antwort an einer ungeprägten URL nun vom Besucher abhängt, ist dies das einzige Universally-Verhalten, das ein Vollseiten-Cache tatsächlich unterbricht. Siehe Caching und CDNs.

Weiterleitungen, die Universally durchführt

Fünf, und es ist gut zu wissen, wann Sie einen unerwarteten 301 oder 302 beheben:

Weiterleitung Status
Ein ausgeschlossener Pfad, der unter seiner übersetzten URL angefordert wird, an die Originalseite gesendet, Query-String beibehalten 301
/es ohne den abschließenden Schrägstrich, gesendet an /es/ 301
Eine URL ohne Präfix für einen Besucher mit gespeicherter Sprache, gesendet an diese Sprache 302
?universally_switch=source, gesendet an die bereinigte URL nach dem Löschen der gespeicherten Sprache 302
Jede WordPress-Weiterleitung auf einer übersetzten Seite behält das Sprachpräfix bei ihrem Ziel bei unverändert

Siehe Seiten ausschließen für die erste.

Wenn Sie eine URL auf Ihrer Website ändern

Auf WordPress wird dies größtenteils für Sie erledigt. Das Sprachpräfix wird entfernt, bevor WordPress die Anfrage weiterleitet. Daher wird eine bestehende Weiterleitung von /old-page/ zu /new-page/ auch für /es/old-page/ ausgelöst, und das Präfix wird wieder am Ziel angefügt: Der Besucher landet auf /es/new-page/, immer noch auf Spanisch. Das deckt Weiterleitungs-Plugins und alles andere ab, das über WordPress weiterleitet.

Zwei Fälle benötigen für den mit Präfix versehenen Pfad immer noch eine eigene Regel:

  • Weiterleitungen in Ihrer Webserver- oder CDN-Konfiguration, die /es/old-page/ sehen, wenn sie ankommen
  • Weiterleitungen, die in PHP mit einem rohen header()-Aufruf und nicht über WordPress geschrieben wurden
War das hilfreich?