Troubleshooting
Polylang and LiteSpeed Cache when detecting the browser language
Polylang can redirect the home page according to the browser's preferred language. When you combine that behaviour with a page cache, you first need to check whether the different responses are stored separately; a single test with the option enabled does not prove that LiteSpeed Cache has been disabled.
Confirm the behaviour
- Note the home page URL and the configured languages.
- Test with two clean profiles that have different preferred languages and do not keep the Polylang language cookie.
- In each response, check the LiteSpeed Cache headers and the final URL. Repeat the visit to tell a first
missapart from a cached response. - Temporarily disable detection on staging and repeat exactly the same requests.
If the headers or the result change consistently, you have a useful comparison. If they do not change, check cache exclusions, cookies and other redirect rules first.
Choose the solution
- If you do not need to detect the browser language, disable Detect browser language (Detectar el idioma del navegador para el idioma de las nuevas visitas) in Languages > Settings. Users will still be able to choose a language with the switcher.
- If you need detection, keep the Polylang feature and set up a cache vary or exclusion compatible with the cookie and language URLs your site uses. In LiteSpeed, once you have confirmed that Polylang uses the
pll_languagecookie, a cookie vary can be declared withRewriteRule .* - [E=Cache-Vary:pll_language]; do it on staging first and see the official Cache Vary documentation.
Do not replace Polylang with a generic redirect based on Accept-Language. It does not behave the same way: it can ignore the preference the visitor has already chosen and, without a validated vary strategy, store or serve the wrong language from cache.
Check that it works
Clear the cache once after changing the configuration. Repeat the tests with clean profiles, check that the manual language choice is kept and confirm that content in one language is never served under another language's URL. Headers can vary depending on the server; compare them with the ones your installation showed before the change.
Test the first visit too
A visit without a cookie and another with pll_language already set are not the same case. Test both, plus an explicit URL for each language. A cookie vary alone does not separate two first visits without a cookie that send different Accept-Language headers.
Also check the CDN cache layers, if there are any. Keep crawlable language links and stable URLs; a browser-based redirect does not replace those pages or their SEO configuration. Do not accept a speed improvement if it shows a visitor the response for another language.
You may also find useful
- 404 errors on static files slow down browsing Detect missing static resources that trigger PHP and use CPU, serve them as lightweight 404s and gui...
- WordPress 6.7, translations do not work correctly Documents the historical WordPress 6.7 translations bug and points current cases towards secure vers...
- Debug errors in WordPress Find WordPress blank screens and internal failures by sending WP_DEBUG to a private log, without sho...
- Diagnose "Missed schedule" Check why a scheduled post was not published before replacing WP-Cron with a server task.
Something wrong or out of date? Tell us and we will review it.