If a Polylang page changes language after clearing WP Rocket, check how language is selected before editing translations. A URL that stays the same for different languages needs the cache to distinguish those requests. The first visitor must not decide what every later visitor reads.
Which configuration does this apply to?
WP Rocket's 3.24 release notes include a Polylang cookie-cache change. The implementation targets browser-language detection together with language selected from content. In that configuration, the language cookie becomes part of the cache filename. Language carried in a directory, subdomain or domain is a different case.
Record both plugin versions, the Polylang language configuration, the affected URL and whether the problem occurs logged out. A translated page missing entirely is not the same fault as a valid translation being replaced by another cached language. Keep the original settings before testing on staging.
Build a two-language evidence sheet
Choose a harmless public page with an unmistakable heading in each language. Do not use checkout, an account page or private content as a cache fixture. Open two separate browser profiles. Set the language through the site's normal switcher and inspect the actual cookie in browser storage. Do not guess its value from the label on the switcher.
Write down the final URL, language choice, cookie name and value, visible heading, and cache response evidence. Inspect one profile at a time so the browser does not silently share the same cookie jar. Keep logged-in sessions out of this comparison because they may bypass the public cache.
| Visit |
Requested state |
Check |
| First profile |
Language A |
A heading after a reload |
| Second profile |
Language B |
B heading at the intended URL |
| First profile again |
Language A |
A remains correct after B visits |
| Reverse warm-up order |
B, then A |
Neither language contaminates the other |
Two visits to the same URL need separate language results when the language is selected by a cookie. Explanatory example, not a customer test.
Inspect the layer that serves the wrong response
Ask the host which layer owns public HTML caching. A correct WP Rocket configuration cannot repair a CDN rule that serves one shared HTML response before WordPress runs. Compare the public response with an origin check using the host's supported method. Do not expose the origin or weaken its firewall just to run this test.
On a site where WP Rocket manages the disk cache, an authorized administrator can inspect its generated configuration and cache filenames. The vendor documents the relevant cookie in the dynamic-cookie list for this Polylang mode. Keep that inspection private: generated configuration can contain unrelated site details. Seeing two files is supporting evidence, not a replacement for testing the actual browser response.
If the origin behaves correctly but the public page does not, give the CDN administrator the exact URL and two synthetic cookie states. The repair may require compatible variation or bypass behavior. Do not broadly cache all cookie-bearing responses, particularly where login or personal data is involved.
Apply the fix without changing the language architecture
Test the supported WP Rocket update on staging. Confirm the resulting configuration, clear the relevant old cache once, and repeat both visit orders. A language-mode change can alter cache names and trigger wider regeneration, so schedule it deliberately rather than toggling settings repeatedly while the server is busy.
Do not move every translated URL to a different structure just to work around this cache bug. That is a separate migration with redirects and search implications. Equally, turning off browser detection is not a neutral diagnostic if it changes the site's agreed visitor experience.
Confirm completion
Retest direct visits, language-switcher visits and a returning visitor after the normal cache cycle. Verify the heading, navigation and form labels, not just the page's language attribute. Preserve the version and configuration with the results so the next deployment has a repeatable check.
If pages are correct but repeatedly slow, continue with WP Rocket preload diagnostics. For a repair involving both host and plugin caches, HandL WP performance support can trace the layer serving the incorrect language.
Sources reviewed October 31, 2026. The suggested checks and diagrams are diagnostic aids, not claims of tests performed on your site.