Server-level caching serves a fully-built page directly from the web server or a caching layer in front of it, before PHP or WordPress ever runs — faster than plugin-based page caching, and configured wrong, prone to serving one visitor’s cart or account page to somebody else entirely.
Why this has to be coordinated with WordPress-level caching, not layered blindly on top
A caching plugin and server-level caching solve overlapping problems, and running both without coordinating their rules is a common way dynamic pages — cart, checkout, account — end up cached when they absolutely should not be.
Getting this right means deciding which layer is responsible for what, not enabling both and hoping they cooperate on their own.
It’s also worth knowing that server-level caching typically needs configuration outside WordPress entirely, at the hosting or server layer, which is part of why it’s often left unconfigured even on hosts that technically support it.
Exclusion rules are the part most worth getting right the first time, since they’re invisible when correct and only noticed when wrong — usually as a support ticket from a confused customer rather than anything showing up in your own testing beforehand.
Purge behaviour deserves the same care. A server-level cache that doesn’t clear when it should shows old prices or old stock long after they’ve changed, which looks like a data problem to a customer even though the underlying record was updated correctly the whole time, and is genuinely one of the more confusing support tickets to correctly trace back to its actual root cause.
We’d rather set purge rules conservatively at first and tighten them once we’ve watched the site behave correctly for a few real content updates, than start aggressive and risk a customer seeing something stale in the meantime.
Server response caching (Varnish/LiteSpeed) setup
Your host offers Varnish or LiteSpeed server-level caching, but it isn't set up, or isn't coordinated safely with your existing caching plugin. We configure both to work together.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
What we need from you
- Confirmation of what caching, if any, is currently active at the plugin level
- Hosting or server access, since Varnish and LiteSpeed are configured outside WordPress itself
- Any pages that must never be cached under any circumstances
- Whether your host provides this natively or it needs setting up from scratch, if you know
This or something else?
| Varnish or LiteSpeed available on your host but not yet configured | This fix covers it |
| Server-level caching active but serving stale or incorrect content | This fix covers it |
| Server-level and plugin-level caching conflicting with each other | This fix covers it |
| No caching in place at all, plugin or server level | Caching setup & configuration |
| CDN not yet set up | CDN & image CDN integration |
What we do
- Confirm what server-level caching your host actually provides and its current state
- Coordinate exclusion rules so cart, checkout, account and other dynamic pages are never served from cache
- Configure cache purge rules so content updates appear promptly
- Align server-level and plugin-level caching so they don’t duplicate or contradict each other
- Test as a logged-out visitor and a logged-in user to confirm each sees the correct version
- Confirm performance actually improves under the new configuration, not just in theory
What is included
- Server-level caching configured and verified safe for dynamic pages
- Coordination between server-level and plugin-level caching
- Purge rules matched to how often your content changes
- The pre-change backup, kept for 30 days
Not included
- Upgrading your hosting plan to one that supports Varnish or LiteSpeed, if it doesn’t already
- CDN setup, which is a separate, complementary fix
- Fixing content that’s slow to generate even once cached correctly
- Ongoing cache management as new page types are added
Questions about this fix
Is server-level caching better than a caching plugin?
Generally faster, since it can serve a page before PHP runs at all, but it's also less flexible and easier to misconfigure for dynamic content. Many sites benefit from both, correctly coordinated, rather than choosing one over the other.
How do I know if my host even offers this?
It depends entirely on your hosting stack — some hosts include Varnish or LiteSpeed by default, others don't offer it at all. We confirm what's actually available before planning around it.
Could this show one customer another customer's cart?
That's exactly the risk of doing this without careful exclusion rules, which is why dynamic pages are explicitly excluded and tested as part of this, not left to a default configuration.
Will I need to purge the cache manually after every change?
Not once this is set up correctly — purge rules are configured to trigger automatically on the events that actually require it, like publishing new content.
Does this replace my existing caching plugin?
Not necessarily — it depends on what your plugin is doing well already. We coordinate the two rather than assume one should simply replace the other.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.