“I updated the page but it still shows the old version.” That one sentence accounts for a fair share of the support emails we get, and the answer is almost always caching.
Caching means saving a ready-made copy of something so it doesn’t have to be built again from scratch. It’s the main reason a well-run WordPress site loads quickly. It’s also behind a particular family of weird bugs. Understanding the four layers makes both easier to deal with.
Why WordPress needs caching at all
Every time someone visits a page on a WordPress site without caching, the server runs PHP code, asks the database for the page content, the menu, the footer, the widgets and the settings, assembles all of it into HTML, and sends it back. On a typical Elementor page that’s a lot of work, done fresh for every single visitor, even though the page is identical for all of them.
Caching saves the finished result and hands that out instead. Done properly, the difference is very noticeable.
The four layers
Page cache
This is the big one. The first visitor to a page triggers the full build. The finished HTML is saved, and the next visitors get that saved copy straight away without touching PHP or the database.
Page caching can be done by a plugin (WP Rocket, LiteSpeed Cache, WP Super Cache and others) or by the server itself. Good managed hosting often does it at server level, which is faster than a plugin and one less thing to configure.
When you edit and save a page, the cache for that page should clear automatically. When it doesn’t, you see the old version.
Browser cache
Your visitor’s browser keeps its own copies of files that rarely change: your logo, fonts, stylesheets and scripts. On their second page view, or their next visit, it doesn’t download them again.
This is controlled by instructions your server sends with each file saying how long it can be kept. It’s why a returning visitor’s experience is faster than a first-timer’s. It’s also why you sometimes see an old logo after you’ve changed it, while everyone else sees the new one.
Object cache
This one works behind the scenes. WordPress asks the database the same questions over and over (what are the site settings, what’s in this menu). An object cache, usually Redis or Memcached on the server, remembers the answers in memory so the database doesn’t have to look them up again.
It matters most on sites that can’t use full page caching for every visitor: WooCommerce stores, membership sites, anywhere people log in. For a five-page brochure site it makes little visible difference. It’s provided by your host, not something you set up in WordPress beyond a connecting plugin.
CDN cache
A content delivery network (Cloudflare is the best known) keeps copies of your site’s files on servers around the world, including several in Australia. A visitor in Perth gets files from a nearby server rather than one in Sydney or overseas.
For a business whose customers are all within an hour’s drive of Ballina, a CDN matters less than people think, especially if your hosting is already in Australia. Its bigger benefits are often security and absorbing traffic spikes. If your host is offshore, though, a CDN can make a real difference. Our guide to website hosting covers why server location matters.
When caching breaks things
The catch: page caching works by giving everyone the same copy. Any part of the page that’s meant to be different for different people, or different every time, can go wrong.
| What you see | Likely cause | The fix |
|---|---|---|
| Edits don’t appear | Page cache, CDN or browser holding the old copy | Clear the plugin cache, then the CDN, then hard refresh (Ctrl+Shift+R) |
| Contact form fails with “invalid” or “expired” error | Cached page has an old security token in the form | Exclude the form page from cache, or shorten cache lifespan to under 10 hours |
| Cart shows someone else’s items, or empties itself | Cart, checkout or account pages are being cached | Exclude those pages and WooCommerce’s cookies from caching |
| Logged-in users see the logged-out version, or vice versa | Cache not set to bypass logged-in users | Turn on “don’t cache for logged-in users” (most plugins do by default) |
| Prices, stock levels or “only 2 left” counters are wrong | Product pages cached too long | Clear cache on stock change, or load those bits by AJAX |
| Site looks broken or unstyled after an update | Combined or minified files cached from before the update | Clear all caches, regenerate Elementor’s files (Elementor > Tools > Regenerate Files & Data) |
| Two caching plugins installed | They fight each other | Keep one. Uninstall the other properly |
The form token problem, explained
Many form plugins include a hidden security token (WordPress calls it a nonce) to prove the form was loaded recently. Those tokens expire, typically within a day. If your page cache keeps a copy of the contact page for a week, every visitor after the first day or so gets a form with a dead token, and submissions fail. Some plugins handle this cleverly, many don’t. If your forms suddenly stop arriving and nothing else has changed, test the form yourself in a private browser window before anything else.
The WooCommerce rule
WooCommerce’s own guidance is clear: the Cart, Checkout and My Account pages must never be page cached, and caching should skip visitors carrying WooCommerce’s cart and session cookies. Most caching plugins detect WooCommerce and do this automatically, but “most” isn’t “all”, and server-level caches configured by hosts sometimes miss it. Test by adding something to your cart in one browser and checking the cart is empty in another.
Clearing cache in the right order
When something isn’t updating, clear from the inside out:
- Elementor’s generated files (Elementor > Tools > Regenerate Files & Data, called Regenerate CSS in older versions) if it’s a styling issue.
- Your caching plugin or the cache button in your hosting panel.
- The CDN, if you use one (Cloudflare has a “Purge Everything” option).
- Your own browser, with a hard refresh or a private window.
Doing it the other way round means the outer layers just grab the stale copy again.
What a sensible setup looks like
For most of the small business sites we manage:
- Server-level page caching from the host, or one well-configured caching plugin. Never two.
- Browser caching set long for images, fonts and scripts.
- Object caching switched on for any WooCommerce or members site.
- A CDN where the host is overseas or the site gets traffic from all over the country.
- Forms, carts and account pages excluded and tested after every major change.
Caching won’t rescue a slow host or a page loaded with 8 MB of images. It works best on a site that’s already lean, which is why our WordPress speed fixes start with images and plugins before touching cache settings. For how speed gets measured, see Core Web Vitals in plain English.
On the sites we host, we configure caching and test it against forms and checkouts, so it’s not something clients have to think about. Our hosting and care plans page has the details.