What a cache refresh rule does
Encited serves crawlers a cached HTML snapshot of every page. Rendering happens once, the result is stored, and the next million crawler hits read from cache. Cache refresh rules decide when each cached snapshot becomes stale and gets re-rendered in the background.
A rule is a (path pattern, interval) pair. When a cached snapshot is older than the interval, the next crawler hit serves the cached version immediately and triggers a background re-render — so the next request gets the fresh snapshot.
You configure rules in Site Settings → Cache & rendering → Cache refresh rules.
This guide covers the timer rules. For the On-demand render toggle (what happens on a first-time request), see the On-demand render guide.
How rules are matched
More specific patterns win. When multiple rules match a path, the most specific one applies. Specificity is judged segment-by-segment, with literal segments beating wildcards.
Path patterns use * (one segment) and ** (rest of path). Both must be whole segments — /blog/* is valid, /blog-* is not. ** may only appear as the last segment. See the redirect guide for the full pattern grammar.
The default catch-all rule
Every domain ships with one non-removable rule:
/** matches every path on the site. You can change its interval, but you can't delete it — it's the fallback when no more-specific rule matches.
Why a catch-all is required — Without one, paths that don't match any rule would have undefined refresh behavior. Forcing a default makes cache freshness predictable across the whole site.
Interval options
There are five intervals. Pick the one that matches how often the underlying content actually changes — refreshing more often than that just burns prerender quota with no SEO gain.
Every day
Re-render ~24 hours after the last render, on the next crawler hit.
Use case — Homepage, category pages, or any landing page that pulls from a frequently-updating data source (recent posts, featured products, live counters). You want crawlers to see today's snapshot, not last week's.
Every week (default)
Re-render after 7 days. The right default for most content.
Use case — Blog posts, product detail pages, marketing pages. Content that's edited occasionally but doesn't change daily. A weekly refresh picks up typo fixes, schema updates, and CMS edits without thrashing the cache.
Every month
Re-render after 30 days. Cheap on prerender quota.
Use case — Long-tail content, archives, legal pages, "About" pages — anything that almost never changes. Monthly refresh ensures crawlers eventually see edits without spending budget on pages that haven't changed.
Disabled
The cached snapshot never auto-refreshes. It only updates when you explicitly invalidate it via the cache invalidation API — typically from a CMS webhook or a deploy hook.
Use case — Pages where you control exactly when content changes. You don't want any background refresh racing your invalidation, and you'd rather pay the API call than let a stale snapshot ship.
"Disabled" is not "never render." The page still gets cached the first time it's rendered. After that, the snapshot is frozen until you invalidate it. To skip caching entirely, use Do not cache instead.
Do not cache
Every crawler request triggers a fresh render. Nothing is reused.
Use case — Highly personalized or real-time content where a stale snapshot would be wrong (e.g. a price page that varies by region, a stock-aware product detail). Or short-term, while debugging a specific path.
"Do not cache" forces On-demand render on. Without it, an uncached URL would return a passthrough — and since nothing is ever cached, every request would passthrough. The UI handles this for you: setting any rule to "Do not cache" auto-enables on-demand render and locks the toggle.
This burns prerender quota fast. Every crawler hit equals one render. Use it for narrow paths only, never on /**. A popular path set to "Do not cache" can chew through your monthly quota in hours.
A worked example: e-commerce site
A typical store might want:
Reading the rules: a crawler hitting /products/red-shoe matches /products/** (more specific than /**), so the page refreshes daily. A hit to /about only matches /**, so it refreshes weekly.
Plan limits
| Plan | Path-specific rules |
|---|---|
| Starter / Basic | Catch-all only |
| Essential, Pro, Agency, Enterprise | Unlimited custom rules |
On Starter and Basic, you can change the interval of /** but you can't add more rules. Upgrade to add per-path rules.
Verify a refresh
Cache state is exposed in response headers:
curl -sI -H "Accept: text/html" -A "Googlebot" https://example.com/blog/post# x-lovablehtml-render-cache: hit | miss | stale# x-lovablehtml-snapshot-key: ...
hit— served from cache, within interval.stale— served from cache, but a background re-render was triggered.miss— no cache; rendered on the spot (requires on-demand render).
For programmatic control of the cache itself, see the cache invalidation API.
