When a CDN sits in front of your site, conflicts between what the CDN caches and what your actual origin server serves can cause visitors to see outdated content, broken functionality on pages that shouldn’t be cached, or inconsistent behaviour depending on whether a request hits the CDN’s cache or reaches your server directly.
Compare what the CDN serves against your origin server directly
If your CDN allows bypassing it temporarily (often via a specific header or a direct origin URL), compare that against what visitors normally see through the CDN. A difference confirms a genuine caching or configuration conflict rather than an issue with your site’s actual content.
CDN configuration & origin conflict fix
A CDN serving stale or broken dynamic content, traced against the origin server directly.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Your CDN is serving outdated content, breaking dynamic functionality, or behaving inconsistently | This fix covers it |
| You want a CDN configured for the first time, not an existing conflict fixed | Worth confirming your specific setup — initial CDN configuration is a related but distinct starting point |
| The conflict is specifically between server-level and plugin-level caching, not a CDN | Server cache & plugin cache conflict, a related but different layer |
| You want Cloudflare specifically audited, not a general CDN conflict diagnosed | Cloudflare settings audit & correction, the more specific version if Cloudflare is your CDN |
What you are seeing
- Visitors seeing outdated content that should have updated
- Dynamic functionality (checkout, account areas) breaking or behaving inconsistently
- Content appearing correct in some tests but not others, depending on cache state
- The issue possibly appearing only after a CDN configuration change or a new page type being added
Common causes
- Dynamic or sensitive pages not correctly excluded from CDN caching
- A cache purge not correctly triggered after content updates, serving stale cached versions
- The CDN and origin server disagreeing about which version of a resource is current
- SSL or header configuration mismatches between the CDN and origin causing inconsistent behaviour
- A CDN cache key configured without accounting for cookies or query strings that vary per visitor, serving one visitor’s personalised response to another
What we do
- Compare CDN-served content against the origin server directly
- Identify the specific caching rule or configuration causing the conflict
- Correct exclusions for dynamic and sensitive content
- Configure appropriate cache purging triggered by content updates
- Verify consistent, correct behaviour between CDN and origin
- Test dynamic functionality specifically to confirm it’s unaffected by caching
What is included
- The specific CDN and origin conflict identified and corrected
- Appropriate exclusions configured for dynamic and sensitive content
- Verified cache purging on content updates
- Confirmed consistent behaviour after the fix
Not included
- Setting up a CDN for the first time, if not already in place — a separate, related fix
- Cloudflare-specific configuration and audit, a separate, more targeted fix if that’s your specific CDN
- Broader server-level cache conflicts unrelated to the CDN specifically
- Ongoing tuning as your site’s content and traffic patterns change
Questions about this fix
Why would a CDN cause dynamic pages like checkout to break?
If a page that should never be cached (because it needs to reflect real-time, visitor-specific information) gets cached anyway, every visitor might see the same cached snapshot instead of their own, personalised state — which is exactly the kind of exclusion this fix ensures is correctly configured.
How do I know if my CDN is actually the cause of an issue, versus something else?
Comparing what the CDN serves against your origin server directly is the most reliable way to isolate this — if the two differ, the CDN layer is genuinely involved; if they're identical, the cause lies elsewhere.
Will fixing this slow down my site by excluding more pages from caching?
We aim to exclude only what genuinely needs to be dynamic, keeping everything else appropriately cached — this is a precise correction, not a blanket disabling of caching's benefits.
Could this have been happening for a while without anyone noticing clearly?
Yes, especially if the symptom is intermittent or only affects a subset of visitors depending on cache state, which can make this kind of issue harder to pin down than a consistent, every-time failure.
Is this specific to one CDN provider, or could it happen with any of them?
This kind of conflict can happen with any CDN, though the specific configuration and fix depend on which provider you're using — we'd work within your specific CDN's actual settings and capabilities.
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.