A hosting provider enables Redis caching to speed up a WooCommerce store. Five minutes later, every product image on the site disappears.
Redis had nothing to do with the images. The real problem was a Content Security Policy header that didn’t recognise the domain Jetpack was using to serve optimised images. That misconfiguration had been sitting there for months, silently, while everything appeared to work fine. The Redis change didn’t cause the breakage — it just drew attention to the site at the exact moment the older problem was waiting to surface.
The instinct is to blame the last change. It’s almost always wrong.
How Six Things Conspired to Break One Site
Here’s what actually happened, step by step:
- Jetpack was rewriting image URLs to its CDN (i0.wp.com)
- A Content Security Policy header was restricting which domains could serve images
- The CSP header didn’t include the Jetpack CDN domain
- But the site’s page cache was serving old HTML with the original image URLs, so nobody noticed
- Enabling Redis cleared the old cache, and fresh pages loaded with Jetpack’s rewritten URLs
- The CSP header blocked them, and the images vanished
Six components. None of them broken individually. The problem only existed in the interaction between them — and it was invisible until something else changed.
This is what makes it so frustrating for site owners. You’re told “we just enabled caching” and suddenly your product images are gone. The explanation — that a security header from eight months ago was quietly waiting to conflict with an image optimiser that rewrote URLs that were hidden behind a page cache — sounds absurd. But this is how modern WordPress sites actually work.
Why “Test After Every Change” Isn’t the Answer
The tempting response is vigilance: check every page after every update. In practice, nobody does this, and even if they did, problems like the one above don’t show up consistently. The images disappeared for logged-in users before logged-out users, because they had different caching behaviour. A quick visual check would have missed it entirely.
The more useful question is: why was this site fragile enough for a caching change to break images?
Sites Don’t Break — They Accumulate Fragility
In our experience, these cascading failures never come from one bad decision. They come from years of reasonable decisions that nobody revisited.
A developer adds Jetpack for image optimisation. A year later, someone else configures CloudFront as a CDN — not realising Jetpack is already rewriting image URLs. A security consultant adds a Content Security Policy header from a hardening guide, tuned for the site as it existed that week. A caching plugin gets installed. Then a second caching layer at the server level.
Each piece made sense when it was added. But nobody looked at the whole picture, because at any given moment the site was working fine. The fragility builds up silently, and only reveals itself when something changes.
What to Ask About Your Own Site
If your site has been built up over years — different developers, different agencies, plugins added for specific problems and never revisited — it’s probably more fragile than you think. Some questions worth asking:
Do you have overlapping tools doing the same job? Two image optimisers. A CDN plugin and a server-level CDN. A security plugin running behind a server firewall. Overlap doesn’t add safety — it adds unpredictable interactions.
Are your security headers based on your site, or a template? Content Security Policy headers are powerful but brittle. If they were set up once and never updated as the site’s dependencies changed, they’re a dormant breakage waiting for a trigger.
Does anyone have the full picture? If your theme was built by one agency, your plugins were configured by another, your hosting is managed by a third, and your content team installs things from the WordPress plugin directory — nobody has a complete view of how all the pieces interact. That gap is where fragility lives.
When was the last time someone removed a plugin? Sites grow by addition. Plugins get installed, rarely uninstalled. Every plugin that’s still active but no longer needed is an interaction surface — one more thing that can conflict with a future change.
The Pattern Behind Every “Small Change Broke My Site”
Every time we investigate one of these incidents, the story follows the same pattern. The change itself was fine. The thing that broke was a dormant issue — something misconfigured, outdated, or redundant — that had been hiding behind a coincidence of caching, timing, or load.
The site didn’t break because someone made a change. It broke because it was already fragile, and the change revealed it.
The fix isn’t more careful change management. It’s taking the time to look at what’s actually running, remove what doesn’t need to be there, and make sure the pieces that remain were chosen to work together — not just piled up over time.
