How to Clear the PrestaShop Cache (All Three Layers)

You changed a template, saved it, and the store still shows the old version. You clear the cache. It still shows the old version. This happens because PrestaShop has three caches, not one, and most guides mention only the first.

This guide covers all three in the order you should clear them, plus the fourth one that sits in front of the server and catches people out.

The three caches, and what each one holds

Cache	Holds	Cleared from
Back office	Compiled templates, module configuration, class index	Advanced Parameters → Performance
Browser	The HTML, CSS and JavaScript of pages you already visited	The browser
Server	Compiled Twig templates and class maps in var/cache/	Filesystem or the hosting panel

A change can be live in one and stale in another. That is why clearing the back office cache and reloading often shows no change.

Layer 1 — Back office

Advanced Parameters → Performance, then the Clear cache button in the page header toolbar (top right, bin icon).

The button clears the compiled template cache and the class index. Use it after:

• Editing a template file
• Installing or updating a module
• Changing a position in Design → Positions
• Editing translations

Important: the button only clears what PrestaShop knows about. If you edited a file directly on the server, this button often does not help. Go to layer 3.

Separately, inside the Smarty card on the same page there is a Cache dropdown with two choices: Never clear cache files and Clear cache everytime something has been modified. That is not the button — it is a rule for whether PrestaShop clears by itself. Clear cache everytime something has been modified is the safe setting for a store you are actively editing.

Layer 2 — Browser

Two ways, and they are not equivalent:

• Normal reload — reuses the cached CSS and JavaScript. Usually not enough.
• Hard reload (Ctrl+Shift+R, or Cmd+Shift+R on Mac) — ignores the cache for the current page. Use this one.
• Private window — the cleanest test. No cache, no cookies, no extensions modifying the page.

Test in a private window before you conclude the cache is the problem. Half the time, the problem is an ad blocker or an extension, not the cache.

Layer 3 — Server file cache

On PrestaShop 1.7 and later, compiled templates live under var/cache/ in the store root. There are two safe ways to clear them:

1. Delete the folder contents — var/cache/dev/ and var/cache/prod/. Not the folders themselves, only what is inside. PrestaShop rebuilds them on the next request.
2. From the hosting panel — most panels have a "clear cache" action per site that does the same thing.

Check the file permissions afterwards. If var/ is writable by the web server this is safe; if it is not, PrestaShop cannot rebuild the cache and you get a blank page instead. Note the permissions before you delete anything.

On PrestaShop 1.6 and earlier the folder was cache/smarty/compile/ and cache/smarty/cache/ instead.

Layer 4 — The CDN or proxy cache

If your store sits behind Cloudflare, a reverse proxy, or your host's own "page cache", there is a cache in front of your server that none of the three layers above touches.

Symptoms that this is your problem:

• The server returns the new content, but the public URL returns the old content
• It affects all browsers at once, including private windows
• It resolves by itself after 20 minutes to a few hours

Purge it from the CDN dashboard. On Cloudflare this is Caching → Configuration → Purge Everything.

This layer is the one that makes a URL test lie to you. If you are checking whether a redirect or a new page works, purge the CDN first — otherwise you are reading a cached response and drawing the wrong conclusion.

How to tell which layer is lying to you, in 30 seconds

You do not have to guess. Every response carries its cache decisions in the headers. Ask for them directly:

curl -I https://yourstore.com/some-page

Run on a real store, the important lines look like this — HTML page first, then a stylesheet:

=== HTML page ===
HTTP/2 200
cache-control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
x-turbo-charged-by: LiteSpeed
server: cloudflare
cf-cache-status: DYNAMIC

=== static asset (css) ===
HTTP/2 200
cache-control: public, max-age=16070400
expires: Thu, 24 Sep 2026 06:55:54 GMT
x-turbo-charged-by: LiteSpeed
server: cloudflare
cf-cache-status: MISS

Read it in this order:

1. server: cloudflare and x-turbo-charged-by: LiteSpeed together — you have two layers in front of the application, and the same URL may answer from either one. That is the fourth cache this guide is about.
2. cf-cache-status — DYNAMIC means the edge decided not to cache this response at all; MISS means it looked and did not find it; HIT means you are reading a stored copy, not the server. If a change is live on the server and HIT here, purge the CDN.
3. cache-control — no-store, no-cache on HTML means the page is never cached by anyone, which is correct for a store and wrong for a brochure page you want fast. public, max-age=... on a stylesheet means it is meant to be cached, and the number is how many seconds.
4. expires — the human-readable version of that same number. If expires is in the past while max-age is large, distrust whichever one is older.

One more header worth knowing: a 301 that moves store.com to www.store.com gets its own cache-control: no-cache response. Every non-www request pays for a redirect that the browser is told not to remember. If you see that, and your site is fully on www, the redirect is doing its job — but it is extra latency on every entry point, and it is worth checking your canonical setup rather than assuming.

The value of this check is that it turns "the cache" into a specific layer with a name. Do it before you clear anything.

Which cache do you actually need to clear?

Symptom	Cache to clear
Template change not showing	Back office, then server
Change shows for you but not for customers	Browser (yours)
Change shows for nobody	Server, then CDN
CSS or JavaScript change not applying	Browser hard reload, then server
Module install not taking effect	Back office, then server
Everything correct but the public URL is stale	CDN

Do not do this

• Do not delete the whole var/ folder. It contains logs, sessions and configuration generated at runtime. Delete var/cache/ contents only.
• Do not clear the cache while customers are checking out. Rebuilding the template cache under load slows the server and can time out a payment step. Do it during low traffic.
• Do not enable "force compilation" and leave it on. It recompiles templates on every request, which is the opposite of a speed improvement.

After clearing

Do this in order, or you will not know whether the change worked:

1. Clear the back office cache
2. Clear the server cache
3. Purge the CDN
4. Open a private window and load the page
5. Check the page source for your change, not just the visible rendering

Checking the source matters. A change can be present in the HTML and hidden by CSS, which looks identical to a change that never deployed.

Related guides

• How to speed up a PrestaShop store — cache settings that make the store faster, not just fresher
• Boost PrestaShop speed without breaking it — the order that cannot break checkout
• How to fix slow product pages in PrestaShop
• PageSpeed module — clears all four layers from one screen

Checklist

• ☐ Back office cache cleared
• ☐ Browser hard reload done in a private window
• ☐ var/cache/ contents deleted (not the folder)
• ☐ var/ permissions noted before deleting
• ☐ CDN purged if the store sits behind one
• ☐ curl -I run on the affected URL, cf-cache-status read
• ☐ Page source checked, not just the visible page

FAQ

Where is the clear cache button in PrestaShop 8? Advanced Parameters → Performance → Clear cache. It is in the same place in PrestaShop 1.7. In 1.6 it was Advanced Parameters → Performance too, but it cleared a different set of folders.

Can I set the cache to clear automatically? Yes — template compilation set to "recompile if files have been updated" makes PrestaShop rebuild on change. That is not the same as clearing: it detects file changes, not database changes.

Does clearing the cache delete my data? No. The cache holds compiled copies of your templates and configuration. Your products, orders and customers live in the database and are never touched.

My change still does not show after all four layers. What now? Check the file permissions on var/, then check that you edited the template the theme is actually using. A child theme or a template override means your edit is in a file nobody renders.