Rules that match how your site works
Target exact content, post types, categories, URL paths, or the entire eligible site. Combine conditions, add exceptions, and set priorities for predictable results.
Rule-driven WordPress cache
Faster pages. Your rules.
Basil turns eligible WordPress pages into static HTML—then lets you decide exactly what gets cached, what stays dynamic, and why.
Local files only
No telemetry
Fail-open by design
Warm hit served early
Private pages bypassed
WordPress 6.6+Built for modern WordPress
PHP 8.1+Lean, current foundation
Local storageYour cache stays on your server
Zero telemetryNo runtime external requests
Purposeful by default
Control the cache.
Control the cache.
Not the other way around.
Most cache plugins ask you to turn everything on and hunt for exceptions later. Basil starts with nothing cached, then follows the rules you choose.
Serve before WordPress boots
On a valid warm hit, Basil's standalone drop-in sends the final HTML without loading WordPress, Composer, a database, or a remote service.
Personalized traffic stays personal
Logged-in, session-based, cart, private, and otherwise unsafe requests bypass the cache and continue through WordPress normally.
Layer decisions without surprises
When more than one rule applies, Basil resolves them by priority, specificity, and creation order. The same request and rules produce the same decision.
How it works
From dynamic to delightfully simple.
Basil stays out of the way until a request is both explicitly matched and safe to cache.
1
Choose what can be cached
Create cache and bypass rules in the WordPress dashboard. Unmatched requests keep using normal WordPress processing.
2
Basil captures a safe response
The first eligible visit renders normally. Basil validates the final 200 HTML response, then stores it as a guarded local file.
3
Warm visits take the short path
Later eligible visits receive the cached HTML through WordPress's early cache lifecycle—before the rest of WordPress loads.
Safe by omission
When in doubt, Basil steps aside.
Performance is useful only when it respects your visitors. Invalid, expired, unknown, or unsafe cache states fail open to normal WordPress processing instead of showing a cache error.
Read common questions
Always handled with care
Bypass
Logged-in visits
Cart and sessions
Query strings
Password-protected pages
Private responses
Non-HTML responses
Preview and search
Unknown cache states
FAQ
Good to know.
Short answers to the questions site owners usually ask before choosing a cache plugin.
Does Basil cache everything after activation?
No. Basil starts in bypass mode. You complete the guided setup and create or enable a cache rule before any page can be cached.
Will logged-in visitors see cached pages?
No. Authentication, session, cart, password, and other known personalization signals make the request ineligible for the page cache.
Where does Basil store cached pages?
On your own server, inside Basil's private directory under wp-content/cache/basil/. Version 1 uses no remote cache service.
Does Basil send usage data or telemetry?
No. Basil makes no runtime external requests and collects no telemetry.
Does Basil support WordPress Multisite?
Not in version 1. Basil detects multisite and keeps page caching disabled with a clear explanation.
Keep caching understandable
Your WordPress site deserves a shorter path.
Basil is built for site owners who want the speed of static HTML and the confidence of explicit, explainable rules.