Archive note, November 20, 2025: This post is based on SoCalNomad operations notes about WordPress, Breeze, ticker API caching, and Cloudflare purge behavior.
The fastest version of a site is often the one that refuses to change.
That is the bargain caching offers. SoCalNomad needed aggressive caching because it was running from modest infrastructure behind Cloudflare. The site needed to be fast for readers and credible to crawlers. Cloudflare made that possible.
Then publishing exposed the tax.
The Stale Page Problem
WordPress could publish a post successfully. The origin could serve the new page. The database could be correct.
The public site could still look stale.
That is not a WordPress problem in isolation. It is what happens when multiple caches exist:
- WordPress transients.
- Object cache behavior.
- Breeze file cache.
- API in-memory cache.
- Revive ad delivery cache.
- Cloudflare edge cache.
- Browser cache.
Each layer may be doing exactly what it was configured to do. Together, they can make a fresh deployment feel broken.
Manual Purges Were A Necessary Phase
The operational notes included explicit cache-clearing recipes:
- Clear WordPress transients and object cache.
- Remove Breeze cache files.
- Restart the ticker API when its memory cache needed clearing.
- Purge Cloudflare when edge content needed to refresh.
- Clear Revive delivery cache when ad changes did not appear.
This kind of checklist is not elegant, but it is honest. Before automation, the important thing is to make the complete state-reset path known.
If you cannot clear the caches manually, you cannot automate cache invalidation safely.
Publishing Needed Targeted Purge
The next step was connecting WordPress publishing events to Cloudflare purge behavior.
When a post changes status, the site does not need to purge the entire internet. It needs to purge the URLs whose visible output depends on that post:
- The post permalink.
- The homepage.
- The latest-news page.
- Relevant category archives.
- Sitemaps.
That is much better than treating every content change as a global emergency.
It also reflects a larger production principle: invalidation should follow dependency.
Caching And Search Are Connected
Cache behavior became part of SEO.
If Google sees stale sitemaps, stale archive pages, or inconsistent status codes, it does not care that the CMS is correct behind the curtain. The crawler evaluates what it receives.
That made Cloudflare purge behavior part of the Search Console story. The site had to update visibly when the publication state changed.
The goal was not only speed. It was freshness with control.
The Black Box Needs A Reset Button
A home-hosted production system behind Cloudflare is a black box to the public. That is fine. It should be.
But internally, the operator needs reset buttons:
- A WordPress cache reset.
- An API restart.
- A Cloudflare purge.
- An ad-server cache clear.
- A way to verify headers before and after.
Those buttons turn panic into procedure.
The Lesson
Caching did not make SoCalNomad simpler.
It made the site possible on the infrastructure I had.
The cost was operational discipline. Every cached layer became another place where truth could lag behind reality. The solution was not to give up caching. The solution was to write the purge paths down, automate the common ones, and accept that cache invalidation is part of publishing.
That was the launch tax.