Give each job to one tool: one page cache, one tool for combining and shrinking files, one place for browser caching rules. Then test every change as a logged-out visitor, never only as the logged-in owner.

Three tools doing one job

A WordPress site normally builds each page from its database every time someone asks for it. Caching saves a finished copy and hands that out instead, which is far faster.

On many sites that job is done three times over: a caching plugin installed years ago, a cache the host later switched on at the server, and an optimisation plugin with a cache of its own.

Each works alone. Stacked, they disagree about which copy of a page is current.

The symptoms are odd enough that nobody connects them to speed at all.

The layers, one by one

The first is where most of the fighting happens. Two page caches stacked on each other each keep their own copy, and clearing one leaves the other serving the old page.

The symptoms

Hours or prices updated in the morning still show the old figures to customers in the afternoon.

A contact form fails now and then with a security message. WordPress forms often carry a security code that expires within a day, and a page cached for longer hands visitors a code that has already expired.

A layout breaks after a plugin update, because combined files were built from the old version and never rebuilt.

A cart shows the wrong count, or a page looks right on one visit and broken on the next, depending on which copy answered.

Why the owner never sees it

Caching plugins and most host caches skip anyone logged in to WordPress, since an editor needs to see changes immediately.

So the owner, logged in, sees the live page, correct and current. Customers see whichever copy the caches hold.

That makes "it looks fine to me" the normal state of a caching problem, not evidence against one.

One layer for each job

The fix is a decision rather than a new tool. Give each job to exactly one layer, and switch it off everywhere else.

If the host runs a page cache, use it and turn off page caching in any plugin. Some hosts forbid caching plugins for exactly this reason.

Let one tool combine and shrink files. Most caching plugins can do it too, and two tools doing it to the same files produce broken pages.

Set browser caching rules in one place, and make sure any content delivery network follows them rather than inventing its own.

Pages that should never be cached

Some pages are different for every visitor, and a shared copy of them is wrong by definition.

The cart, the checkout and account pages belong on that list, along with anything that shows a visitor's own details.

Pages with forms need care: either excluded, or cached for less time than the form's security code lasts.

Most caching plugins know the usual shop pages and skip them. A second cache layered on top may not, which is how a cart count or a greeting meant for one visitor can appear in a copy served to others.

A worked example

A bead shop with a storefront in a small city also sells online, through a WordPress store listing a few thousand beads, findings, wires and tools.

Its site had a caching plugin from the original build, an optimisation plugin added last year for a better speed score and, since a server move this spring, a page cache run by the host.

Product pages went on showing beads as in stock for hours after they sold out at the counter, and orders arrived online for stock that was gone.

Sale prices lingered after sales ended, and the contact form failed every few days.

The owner, always logged in, saw none of it. The plugin cleared its own copy whenever a product changed, but the host's cache in front of it kept serving the older one until it expired.

The form failures had the same root: pages kept for longer than the form's security code lasted.

The host's cache is now the only page cache, set to clear a product's page when the product changes. The old plugin's page caching is off, and the optimisation plugin handles files alone.

Cart, checkout, account and contact pages are excluded, and every change is checked in a private window and on a phone.

Testing as a logged-out visitor

After any change, look at the page the way a customer does. Open it in a private browsing window, which arrives without your login or stored files.

Check it on a phone using mobile data, which shows what a visitor elsewhere receives.

Many caching tools add a note at the very bottom of the page's source code saying when the copy was made. Browser developer tools also show response headers, which often say whether a copy came from a cache.

If the copy is older than your change, a layer has not been cleared.

Clearing caches in order

When a change will not show, clear from the inside out.

First the optimisation plugin's combined files, then the page cache, then the host's cache, then the content delivery network, and finally check again in a fresh private window.

Clearing in the wrong order can rebuild a fresh page from stale files, which then gets cached again for another day.

The counter-case

A small brochure site on a host with a good server cache may need no caching plugin at all, and adding one is where the trouble starts.

A site that changes once a month can live with longer cache times and fewer exclusions than a shop.

A busy store, on the other hand, needs more careful setup, not less, and is worth having someone configure and document properly.

Either way the principle holds: one tool for each job, and every change tested logged out.

Before the next change

  1. List every tool that caches or optimises.
  2. Ask the host what its server cache does.
  3. Choose one page cache and turn off the rest.
  4. Let one tool combine and shrink files.
  5. Exclude cart, checkout and account pages from caching.
  6. Write down which tool does which job.
  7. Test logged out after every change.

Step seven is the one that catches everything else. A caching problem is almost invisible to a logged-in owner and obvious to the first customer who meets it.

Weight that plugins add to every page, whatever the cache does, is the subject of a page builder loading every feature on every page.

Frequently asked questions

Why do caching tools conflict?

Each keeps its own copy of the page. When two page caches are stacked, clearing one leaves the other serving the old version until it expires.

What are the signs of a caching conflict?

Updated hours or prices that customers cannot see, forms failing with security errors, layouts breaking after updates, and pages that differ from one visit to the next.

Why does the site look fine to me?

Caching plugins and most host caches skip logged-in users, so the owner sees the live page while customers see whatever copy the caches are holding.

Should I use the host's cache or a plugin?

One, not both. If the host runs a page cache, use it and turn off page caching in any plugin. Some hosts forbid caching plugins for that reason.

Which pages should never be cached?

The cart, the checkout, account pages and anything showing a visitor's own details. Pages with forms should be excluded or cached for less time than their security codes last.

How do I test a caching change?

Open the page in a private window and on a phone using mobile data, check when the cached copy was made, and clear layers from the inside out.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Changes that only you can see?

Send us your site address. We will map every cache it runs and tell you which ones to switch off.

Start a Conversation