Fehlerbehebung
Polylang und LiteSpeed Cache bei der Erkennung der Browsersprache
Polylang kann die Startseite je nach bevorzugter Sprache des Browsers weiterleiten. Wenn Sie dieses Verhalten mit einem Seiten-Cache kombinieren, müssen Sie zuerst prüfen, ob die verschiedenen Antworten getrennt gespeichert werden; ein einzelner Test mit aktivierter Option beweist nicht, dass LiteSpeed Cache deaktiviert wurde.
Das Verhalten bestätigen
- Notieren Sie die URL der Startseite und die konfigurierten Sprachen.
- Testen Sie mit zwei sauberen Profilen, die unterschiedliche bevorzugte Sprachen haben und kein Sprach-Cookie von Polylang behalten.
- Prüfen Sie bei jeder Antwort die Header von LiteSpeed Cache und die endgültige URL. Wiederholen Sie den Aufruf, um einen ersten
missvon einer Antwort aus dem Cache zu unterscheiden. - Deaktivieren Sie die Erkennung vorübergehend im Staging und wiederholen Sie genau dieselben Anfragen.
Ändern sich die Header oder das Ergebnis reproduzierbar, haben Sie einen brauchbaren Vergleich. Ändern sie sich nicht, prüfen Sie zuerst Cache-Ausnahmen, Cookies und andere Weiterleitungsregeln.
Die Lösung wählen
- Wenn Sie die Browsersprache nicht erkennen müssen, deaktivieren Sie unter Sprachen > Einstellungen die Option Detect the browser language für die Sprache neuer Besucher. Die Nutzer können die Sprache weiterhin über den Sprachumschalter wählen.
- Wenn Sie die Erkennung brauchen, behalten Sie die Funktion von Polylang bei und konfigurieren Sie eine Cache-Variation oder -Ausnahme, die zum Cookie und zu den Sprach-URLs Ihrer Website passt. In LiteSpeed lässt sich, nachdem Sie bestätigt haben, dass Polylang das Cookie
pll_languageverwendet, eine Variation nach Cookie mitRewriteRule .* - [E=Cache-Vary:pll_language]festlegen; tun Sie das zuerst im Staging und lesen Sie die offizielle Dokumentation zu Cache Vary.
Ersetzen Sie Polylang nicht durch eine generische Weiterleitung auf Basis von Accept-Language. Das Verhalten ist nicht gleichwertig: Sie kann die bereits gewählte Präferenz des Besuchers ignorieren und ohne eine geprüfte Variationsstrategie eine falsche Sprache im Cache speichern oder ausliefern.
Die Funktion prüfen
Leeren Sie den Cache einmal, nachdem Sie die Konfiguration geändert haben. Wiederholen Sie die Tests mit sauberen Profilen, prüfen Sie, dass die manuelle Sprachwahl erhalten bleibt, und stellen Sie sicher, dass niemals Inhalte einer Sprache unter der URL einer anderen ausgeliefert werden. Die Header können je nach Server abweichen; vergleichen Sie sie mit denen, die Ihre Installation vor der Änderung zeigte.
Auch den ersten Besuch testen
Ein Besuch ohne Cookie und einer mit bereits gewähltem pll_language sind nicht derselbe Fall. Testen Sie beide sowie eine explizite URL jeder Sprache. Die Variation nach Cookie trennt für sich allein nicht zwei erste Besuche ohne Cookie, die unterschiedliche Accept-Language senden.
Prüfen Sie auch die Cache-Ebenen des CDN, falls vorhanden. Behalten Sie crawlbare Sprachlinks und stabile URLs bei; eine Weiterleitung nach Browser ersetzt weder diese Seiten noch ihre SEO-Konfiguration. Werten Sie einen Geschwindigkeitsgewinn nicht als Erfolg, wenn er einem Besucher die Antwort einer anderen Sprache zeigt.
Das könnte Ihnen auch helfen
- 404-Fehler bei statischen Dateien verlangsamen die Website Erkennen Sie fehlende statische Ressourcen, die PHP starten und CPU verbrauchen, liefern Sie sie als...
- WordPress 6.7, die Übersetzungen funktionieren nicht richtig Dokumentiert den historischen Übersetzungsfehler von WordPress 6.7 und führt aktuelle Fälle zu siche...
- Einen WordPress-Fehler debuggen lernen Zeigt, wie Sie einen fatalen WordPress-Fehler lesen, unterscheiden, was er beweist und was nur mögli...
- Elementor 3.6.x, historische Kompatibilitätsprobleme Historische Anleitung zur Diagnose von Fehlern nach dem Update auf Elementor 3.6, ohne sie alle ders...
Stimmt etwas nicht oder hat sich etwas geändert? Erzählen Sie es uns, und wir prüfen es.