About

The product came out of a recurring frustration: WordPress caching makes sites fast, but keeping cached content fresh gets harder once content is reused across pages, non-archive pages, shortcodes, templates, post type relationships, forms and other structures.

The usual fallback is to manually clear specific pages or the entire cache. That works — but is avoidable effort, and the latter also throws away cached pages that were still perfectly valid.

The project that forced a proper solution

The project that made the problem impossible to ignore was taking over tierpark-bern.ch — the official zoo website in Bern, Switzerland. More than 1200 URLs, 16 custom post types, 15 forms across the site, shortcodes all over the place, and three languages.

I’d already been writing one-off cache invalidation snippets for smaller sites, but that approach was no longer going to scale on a site like this. The problem needed a proper system.

The result: Cache Autopilot

When something changes in WordPress, it determines which frontend pages are affected, purges those URLs through the existing cache plugin, and preloads them again in the background — while leaving unrelated cached pages alone where possible.

That also makes site handover simpler: once Cache Autopilot is configured, editors can publish normally without having to know which caches need clearing afterwards.

Watching the right pages appear in the warmup log after a change is genuine cache-nerd satisfaction.

Development

Cache Autopilot is maintained by one person — the same person who builds it, uses it on production sites, and supports it.

Development priorities come from real site needs. New capabilities are added when they solve a genuine problem, with stability taking precedence over adding features for their own sake.

If you want to know more about the work behind it — or about Beat — you’ll find that at ekesto.com.