Posted On 28.03.2026

WordPress – Caching riddles

0 comments
confdroid.com >> blog >> WordPress – Caching riddles

When Caching Breaks Your WordPress REST API: A Debugging Story and Why Caching Still Matters

For the past six months, my custom publishing pipeline has worked flawlessly. I write a blog post once in Markdown with YAML frontmatter, push it to Git, and a Jenkins-based CI/CD pipeline automatically publishes it to multiple platforms. WordPress serves as the canonical source, with the pipeline using the WordPress REST API to create or update posts, upload media, set tags, and handle everything else.

Then, two days ago, everything stopped. The pipeline started throwing tracebacks on every run. Nothing in my code or setup had changed — only a new post was being published. Even after removing the new post, the errors persisted. A similar pipeline on another site broke at the same time.

After a full day of troubleshooting, I narrowed it down: the WordPress REST API was returning completely empty responses for posts and tags endpoints. That left only two likely culprits — a recent WordPress core update or a plugin update. I rolled back the latest WordPress update (not ideal, as database schema changes can cause issues). No improvement. Then I began disabling plugins one by one. The culprit? W3 Total Cache.

Even though it was explicitly configured not to cache the REST API, it was still interfering and returning empty pages. Disabling the plugin instantly fixed the problem. What surprised me most was that this same setup had worked without issues for several years. I tried flushing all caches, re-saving settings, and restarting services multiple times — nothing helped. In the end, I switched to WP Super Cache (developed by Automattic) and so far, everything is running smoothly again. I still want to keep caching on my WordPress sites — it’s simply too important for performance to give up.

Why Caching Is Essential for WordPress Sites

Caching dramatically improves website speed and user experience by storing ready-to-serve versions of your content instead of regenerating it from scratch on every request. Without it:

  • Every page load hits the database and PHP processor heavily.
  • Server load increases, especially under traffic spikes.
  • Visitors experience slower load times, which hurts both user satisfaction and SEO.

Modern caching plugins typically combine several layers:

  • Page caching — Stores full HTML output as static files.
  • Object caching — Caches database queries and expensive operations (often using Memcached or Redis).
  • Browser caching — Tells visitors’ browsers how long to keep assets like images, CSS, and JavaScript.
  • Minification and CDN integration — Reduces file sizes and delivers content from edge locations.

The challenge arises when caching touches dynamic endpoints like the WordPress REST API, which my publishing pipeline relies on. API calls need fresh, up-to-date data — not stale cached responses.

Advertisements

How Object Caching Works with Memcached (Visualized)

Here’s a simplified flow of how object caching (using Memcached) typically works in a WordPress environment:

Mermaid diagram

In this flow:

  • On a cache hit, the response is served almost instantly from memory.
  • On a cache miss, WordPress does the heavy work once, then stores the result in Memcached so future requests are lightning-fast.
  • Keys usually include a version or hash so updates can invalidate old entries.

The trick is configuring the cache plugin to exclude dynamic paths like /wp-json/ while still benefiting from full-page and object caching everywhere else.

Lessons Learned

  • Even well-configured caching plugins can suddenly interfere with the REST API after years of smooth operation.
  • When debugging API issues, always consider caching plugins early in the process.
  • Simpler solutions like WP Super Cache can sometimes be more reliable for certain setups than feature-heavy ones like W3 Total Cache.
  • Caching remains one of the highest-ROI performance improvements you can make on a WordPress site — just make sure it plays nicely with your automation and API-driven workflows.

My publishing pipeline is back online, and I’ll continue monitoring how WP Super Cache behaves over the coming weeks. If you run a similar automated publishing setup or rely heavily on the WordPress REST API, double-check your caching exclusions.

Have you ever had a caching plugin silently break your API calls? Which caching solution are you using now — W3 Total Cache, WP Super Cache, or something else? Share your experiences in the comments.


Did you find this post helpful? You can support me.

Hetzner Referral
Substack
ConfDroid Feedback Portal

Author Profile

12ww1160DevOps engineer & architect

Advertisements

Leave a Reply

Your email address will not be published. Required fields are marked *

3 + sixteen =

Related Post

Migrating my cloud to Kubernetes – Part II about storage facilities

A few days ago I had posted part 1 of my quest to move my…

The TLS Journey: Fixing Wiki.js → PgBouncer → PostgreSQL (and learning Node.js SNI the hard way)

You know those bugs that look small at first — but then drag you, willingly,…

How to add an existing Paypal button to WordPress

So you run a Wordpress website and want to add a simple button for donations…
Social Media Auto Publish Powered By : XYZScripts.com