Magento Full Page Cache Not Working? The Fix Checklist 2026
Magento full page cache not working is nearly always one of a handful of causes — wrong mode, Varnish bypassed, a stray cookie or query parameter. Here is how to find which, fast.
When your Magento full page cache not working problem means every page hits PHP, your carefully provisioned server crawls under load that Varnish should have absorbed. The frustrating part is that a broken full-page cache looks identical to a working one until you measure it — the site loads, just slowly, and only under traffic does the missing cache bite. This guide walks the causes of a Magento full page cache not working issue in order of likelihood, with the one diagnostic header that tells you exactly what is happening.
Search intent: troubleshooting — Magento developers whose full-page cache is not serving hits. We cover confirming the miss with the cache-debug header, then mode and configuration, the Varnish request path, cookies and query parameters, and private-block issues. It builds on our Varnish VCL guide and cache types guide.
Magento Full Page Cache Not Working: Confirm the Miss
Before changing anything, prove the problem exists and see its shape. Magento can emit a cache-debug header that reports HIT or MISS for each page, and it is the single most useful tool for a Magento full page cache not working investigation. Enable developer mode (on staging), request a cacheable page twice, and inspect the header: the first request may MISS as the cache populates, but the second should HIT. A page that MISSes every time is the symptom you are chasing.
# request a category page twice - second should be a HIT curl -sI https://example.com/category.html | grep -i "x-magento-cache-debug|age|x-cache" curl -sI https://example.com/category.html | grep -i "x-magento-cache-debug|age|x-cache" # which FPC application is configured? (2 = Varnish, 1 = built-in) bin/magento config:show system/full_page_cache/caching_application # is the cache even enabled? bin/magento cache:status | grep full_page
Note which caching application is set. A Magento full page cache not working problem splits into two branches from here: if you are on the built-in cache, the causes are mode and cacheability; if you are on Varnish, add the request-path and purge issues covered in our Varnish guide.
Magento Full Page Cache Not Working: Mode and Configuration
The most basic cause of a Magento full page cache not working issue is that the full-page cache is disabled or the store is in developer mode. Developer mode disables several caches by design, which is correct for development and disastrous for production performance — a store accidentally left in developer mode after debugging is a classic cause. Confirm you are in production mode on live, and that the full_page cache type is enabled.
Equally, check that the cache has not been manually disabled. It is common during troubleshooting to run cache:disable full_page and forget to re-enable it. A quick cache:status shows the state of every cache type, and re-enabling is one command. These sound trivial, but a meaningful share of Magento full page cache not working tickets are exactly this — the cache switched off and never switched back on.
Magento Full Page Cache Not Working: Cookies and Query Parameters
This is the subtle, high-frequency cause that catches experienced developers. The full-page cache only serves anonymous, cacheable requests — and certain things make a request uncacheable without any obvious sign. A Magento full page cache not working problem here usually traces to one of two culprits.
Cookies. Third-party scripts, analytics, chat widgets and poorly written extensions sometimes set cookies on every request. If a request carries a cookie the cache treats as session-bearing, Varnish and the built-in cache both treat it as private and skip caching entirely. A single misbehaving extension setting a cookie site-wide can defeat the full-page cache for your whole catalogue.
Query parameters. URLs with parameters the cache does not recognise — tracking parameters, unhandled filters — can each be treated as a distinct, uncacheable URL. Marketing campaigns appending tracking parameters to every landing-page link can silently blow a hole in your hit rate. The fix is to ensure such parameters are handled correctly so the underlying page still caches. Diagnosing a Magento full page cache not working issue here means comparing a clean request against a real-world one and watching which extra cookie or parameter flips HIT to MISS.
# clean request - should HIT on the second call curl -sI https://example.com/category.html | grep -i cache-debug # same page WITH a tracking parameter - still HIT? curl -sI "https://example.com/category.html?utm_source=test" | grep -i cache-debug # what cookies is the site setting on a plain request? curl -sI https://example.com/category.html | grep -i set-cookie # a session cookie on an anonymous page = cache defeated
Magento Full Page Cache Not Working: Private Blocks and the Checklist
The last category of Magento full page cache not working problems involves blocks marked as private that should be public, or vice versa. Magento caches the shared page and loads personal content (cart, customer name) separately. If a custom block is incorrectly declared, it can either leak between customers (marked public when it should be private) or force a page uncacheable. Custom theme and extension blocks are the usual source, and the fix is correcting the block’s cacheability declaration in layout XML — our layout XML guide covers how.
| Cause | How to spot it | Fix |
|---|---|---|
| Developer mode / cache off | cache:status shows disabled | Production mode, enable full_page |
| Varnish bypassed | No X-Magento-Cache header at all | Check request path, backend port |
| Session cookie set | set-cookie on anonymous page | Fix the extension setting it |
| Tracking parameters | MISS only with ?utm= params | Handle params so page still caches |
| Block marked private | Whole page uncacheable | Correct cacheable in layout XML |
| Purge too aggressive | HIT rate low, constant repopulation | Review tag-based invalidation |
Work the checklist top to bottom and the cause of a Magento full page cache not working problem reveals itself quickly — mode, then cache path, then cookies and parameters, then blocks. The discipline is to change one thing and re-test the cache-debug header, rather than changing several and losing track of what fixed it. Our Magento team resolves caching problems as part of performance engagements.
What we have learned debugging Magento full-page cache
The cache-debug header ends most of these investigations fast. Instead of theorising, we enable it and watch HIT versus MISS while changing one variable at a time. It turns a vague “caching seems broken” into a precise “this parameter flips it to MISS” in minutes.
A single extension setting a site-wide cookie is the classic villain. We have traced whole-catalogue cache failures to one plugin setting a cookie on every request, which the cache reads as session-bearing and refuses to cache. Checking set-cookie on a plain anonymous page is a five-second test that has saved us hours.
Tracking parameters quietly wreck hit rate. A marketing campaign appending unique parameters to every ad link can make thousands of landing-page views uncacheable. It rarely shows in casual testing because a plain URL still HITs — you only see it when you test the real, parameterised URLs your visitors actually arrive on.
Frequently Asked Questions About Magento Full Page Cache Not Working
Why is my Magento full page cache not working?
The usual causes, in order: the store is in developer mode or the cache is disabled; Varnish is not in the request path; a cookie or query parameter is making requests uncacheable; or a block is incorrectly marked private. Enable the cache-debug header and check HIT versus MISS to find which applies to you.
How do I check if Magento full page cache is working?
Enable the cache-debug header in developer mode and request a cacheable page twice. The first may MISS as the cache populates; the second should HIT. A page that MISSes every time is broken. For Varnish, also check varnishstat for the cache hit ratio under real traffic.
Why does Magento cache work for some pages but not others?
Usually a cookie or query parameter specific to those pages, or a block on them marked as private. Cart, checkout and account pages are never cached by design. For catalogue pages that inconsistently MISS, compare a clean request against the real parameterised URL to find what defeats caching.
Can a cookie stop Magento full page cache working?
Yes, and it is a common cause. If an extension or third-party script sets a cookie the cache treats as session-bearing on every request, both Varnish and the built-in cache treat those requests as private and skip caching. Check set-cookie on a plain anonymous page and fix the offending extension.
Do UTM and tracking parameters break Magento caching?
They can. Unhandled query parameters may each be treated as a distinct, uncacheable URL, so a campaign appending tracking parameters to every link can silently destroy hit rate on landing pages. Ensure such parameters are handled so the underlying page still caches rather than generating a fresh uncached variant each time.
My Magento is in production mode but still not caching — why?
Check whether full_page was manually disabled with cache:disable and never re-enabled, whether Varnish is actually in the request path (no X-Magento-Cache header suggests it is bypassed), and whether a cookie or parameter is defeating cacheability. Work the checklist and re-test the cache-debug header after each change.
Full-Page Cache Not Delivering?
Our team diagnoses Magento caching — HIT/MISS analysis, cookie and parameter issues, Varnish path and purge.
