Fix: LiteSpeed Cache “Page is cached but the ESI block failed to render”

Here’s a pragmatic, copy-paste friendly playbook that resolves the vast majority of ESI failures with LiteSpeed Cache for WordPress (LSCWP).

What the error means

ESI (Edge Side Includes) lets LiteSpeed serve a cached page while pulling fresh HTML for specific blocks (e.g., cart count, login state) via a separate subrequest. If that subrequest can’t run or its URL gets mangled, LiteSpeed serves the cached shell and your ESI block “fails to render.”

Quick fixes

1. Confirm the environment supports ESI: Your site should run on LiteSpeed/OpenLiteSpeed with LSCache enabled (or use QUIC.cloud for caching). If you’re on plain Apache/Nginx without LSCache support, disable ESI features.
2. Turn ESI ON in LSCWP: WP Admin → LiteSpeed Cache → Cache → ESI → Enable ESI = ON. For WooCommerce sites, also toggle the Cart/Admin Bar ESI options as needed.
3. Undo HTML/URL rewrites that break ESI links: Temporarily disable HTML minify/combines (LSCWP Page Optimization) and any plugin that rewrites URLs/content (or WAF rules) to see if the ESI block starts rendering.
4. Purge all caches: LiteSpeed Cache → Toolbox → Purge → Purge All (and clear any CDN/proxy cache).

Step-by-step diagnosis & fixes

1) Verify server support & cache headers

• Load a page and inspect response headers. You should see X-LiteSpeed-Cache with values like hit/miss. If you never see LSCache headers, you’re likely not using a LiteSpeed/OLS+LSCache stack. In that case, disable ESI features or move to a supported stack.
• If you’re using QUIC.cloud CDN, make sure it’s properly connected to LSCWP so ESI/caching work end-to-end.

2) Enable ESI correctly (and select the right blocks)

• Enable ESI: LiteSpeed Cache → Cache → ESI → Enable ESI = ON.
• WooCommerce: Toggle Cart and (optionally) Admin Bar ESI to suit your site. Use Private ESI where content varies per user (cart, account), and Public ESI where it doesn’t.
• If you use custom ESI content via shortcodes or theme areas, keep them minimal (no heavy queries) and avoid functions that require a full WordPress environment not available in subrequests.

3) Stop HTML/URL rewriting that breaks ESI requests

The most common real-world cause is an optimizer, security plugin, proxy, or WAF “tidying” the ESI subrequest URL and breaking its query string, especially turning & into & in the link itself. When that happens, LiteSpeed can’t fetch the block, so it fails.

• Temporarily disable LSCWP Page Optimization (HTML/CSS/JS minify/combine, JS defers), and any third-party HTML optimizer. Retest the page.
• Check page HTML source for ESI URLs that contain & instead of raw &. If you see this, exclude the ESI markup/selector from the optimizer or turn off the feature that rewrites these URLs.
• If you use a WAF (host or plugin), allowlist the ESI query parameters so they’re not re-encoded, filtered, or cached incorrectly.

4) Check for PHP fatals/notices inside the ESI block

If the subrequest hits a fatal error, the block can’t render. Use LSCWP’s tools and your PHP error log to catch this quickly:

1. Go to LiteSpeed Cache → Toolbox → Debug Settings and enable logging temporarily. Reproduce the issue.
2. Check LiteSpeed Cache → Toolbox → Log View and your PHP error log for errors associated with the ESI subrequest.
3. Fix the offending plugin/theme code (often a strict type error or a function that assumes a full page context). Update outdated plugins first; then selectively deactivate to find the culprit.

5) Proxy/CDN compatibility

• Ensure proxies (e.g., Cloudflare) are not caching or altering ESI subrequests. Disable “HTML minify”/“Rocket Loader”/similar features and test again.
• Add a rule to bypass transformation on ESI subrequest URLs if needed (match the ESI control/query params you see in page source).

6) Safe fallbacks if a specific block refuses to cooperate

• Disable ESI just for that block (e.g., set WooCommerce Cart ESI = OFF) and let it render in the normal page output, or use the plugin’s AJAX mode if provided.
• Don’t cache the few pages where the dynamic block appears (e.g., cart/checkout/account) via LiteSpeed Cache → Cache → Excludes → Do Not Cache URLs.

How to verify the fix

1. Hard refresh the page (and/or open in a private window) after purging caches.
2. Confirm the page shows X-LiteSpeed-Cache: hit on repeat loads and the dynamic piece (cart count/login state/nonce fields) displays correctly.
3. If needed, use LiteSpeed’s Admin IP “no-cache” commands to compare a fully uncached view vs. cached+ESI behavior.

FAQ

Do I need ESI at all? Use it when you want most of a page cached but still need a small, dynamic fragment per user/session. If your site has few dynamic bits, you can disable ESI entirely and rely on normal uncached pages for those specific routes.

Why does this only happen on some pages? Only pages that include ESI fragments are affected. The rest of your site can cache normally.

Is this a security problem? No, it’s a rendering/routing problem. But misconfigured WAFs and optimizers often cause it.

Recap

• Confirm LiteSpeed/OLS + LSCache support (or QUIC.cloud).
• Enable ESI and choose the right block scope (public vs. private).
• Stop HTML/URL rewriting: exclude ESI URLs from optimizers/WAFs.
• Fix PHP errors in the ESI subrequest (check logs).
• Use block-level fallbacks if a specific component won’t play nice.