Caching stores a reusable result so WordPress, the server or the browser does not have to repeat the same work for every request. It can improve speed significantly, but different cache layers solve different problems and can serve incorrect content if configured carelessly.
The main cache layers
| Layer | What it stores | Main risk |
|---|---|---|
| Browser cache | Static files on the visitor’s device | Visitors keep an outdated file after a change |
| Page cache | Generated HTML for repeated public requests | Personalised or transactional pages are cached |
| Object cache | Results of database queries and computed objects | Stale data or unsuitable server configuration |
| Opcode cache | Compiled PHP instructions on the server | Usually managed at server level; resets may be needed after deployments |
| CDN or edge cache | Copies of assets or pages near visitors | Purge, location and personalisation rules are misunderstood |
Who may already provide caching
The host, a reverse proxy, a CDN, the theme and a WordPress plugin can all add caching. Before installing another tool, map the existing layers and decide which one controls page caching and purging.
Pages that need caution
- Basket and checkout
- Customer account and logged-in pages
- Booking availability
- Personalised pricing or membership content
- Form confirmation pages
- Preview and staging environments
Cache invalidation
A cache must be cleared or versioned when content, styles, scripts, inventory or configuration changes. “Clear all caches” is a useful diagnostic step, but frequent unexplained purging can hide a broken invalidation process.
Safe setup sequence
- Record the current cache layers.
- Back up the site and configure on staging where possible.
- Enable one layer at a time.
- Exclude dynamic and authenticated journeys.
- Test anonymous, logged-in and transactional states.
- Publish a visible change and confirm it reaches visitors.
- Document purge and emergency-disable procedures.
Caching does not fix everything
It cannot make an oversized image small, remove a blocking third-party script or repair an inefficient process that still runs on every uncached request. Diagnose cold and warm requests separately.
Verification checklist
- No customer sees another customer’s content
- Prices, stock and booking availability update correctly
- Forms and payment callbacks bypass inappropriate caching
- Editors know how to purge after a release
- The site still works when the cache is temporarily disabled
Practical next step
Draw a simple diagram of the current browser, CDN, server and WordPress cache layers. Remove unexplained duplication before tuning individual settings.
Common cache symptoms
- An editor publishes a change but visitors see the old version.
- A logged-in toolbar or personalised price appears to the wrong user.
- A basket empties or shows stale contents.
- Styles update only after a hard refresh.
- A redirect or error remains after the underlying setting is fixed.
Record which layer was purged when resolving these problems. Clearing several layers at once may restore the page but leaves the cause unknown.
Emergency disable procedure
Document how to bypass or disable the page cache without deleting configuration. Confirm the site remains functional, even if slower. This matters when an incident requires immediate fresh content, corrected pricing or a checkout fix.
Sources and date checked
This guide was checked on 21 July 2026. WordPress, hosting environments and extensions change, so recheck the relevant official documentation before making a major change.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.