What this toggle does
Encited (formerly LovableHTML) keeps a rendered HTML snapshot for every URL it has seen before. The On-demand render toggle decides what to do when a crawler asks for a URL we've never rendered.
| State | Behavior on a cache miss |
|---|---|
| On | Render the page on the spot, store the result, return rendered HTML. |
| Off | Skip rendering. Return a passthrough so the crawler hits your origin SPA. |
The setting lives in Site Settings → Cache & rendering → On-demand render.
This toggle is independent from the cache refresh rules. Refresh rules govern re-rendering of pages already in cache. This toggle governs the first render for a URL the system has never seen.
When to turn it on
The default. Use this if any of these are true:
- You publish content faster than your sitemap updates (CMS, blog, user-generated pages).
- Your URL space is large or dynamic — product pages by SKU, location-based pages, parameterized routes.
- Backlinks point to pages that aren't in your sitemap yet.
A bot finds an uncached URL → we render it once → every subsequent bot hit is a fast cache hit.
Use case — A blog with thousands of long-tail posts that aren't all listed in sitemap.xml. A search engine discovers one via a backlink and gets a fully-rendered snapshot the first time. The next crawler reads from cache.
When to turn it off
Use this when your sitemap is the source of truth and you don't want bots seeing anything you haven't explicitly approved.
- Marketing sites with a fixed list of pages.
- Compliance-sensitive sites where a draft URL leaking into the index would be a problem.
- Sites where you control prerendering through deploy hooks + the cache invalidation API.
With on-demand off, a cache miss returns a passthrough — the crawler still gets a response, but it's whatever your origin SPA serves (which for a crawler usually means an empty shell).
Use case — A B2B marketing site with ~50 pages. You run prewarm after every deploy, so every page is in cache before any crawler arrives. On-demand stays off so a typo in a backlink can't add a 404 page to the index.
How it interacts with cache refresh rules
A Do not cache rule means every crawler request is a fresh render — there's nothing in cache to serve. That requires on-demand to be on, otherwise every request would passthrough.
The settings UI handles this for you: setting any rule to Do not cache auto-enables on-demand and locks the toggle until you change the interval back.
Off + Do not cache = no rendering at all. The UI prevents this combination. If you're hitting it via the API, expect rendered HTML to disappear from the path until you fix one or the other.
Verify the behavior
Cache state is exposed in response headers:
curl -sI -H "Accept: text/html" -A "Googlebot" https://example.com/some-page
| Header value | Meaning |
|---|---|
x-lovablehtml-render-cache: hit |
Served from cache, within the refresh interval. |
x-lovablehtml-render-cache: stale |
Served from cache; a background re-render was triggered. |
x-lovablehtml-render-cache: miss |
No cache hit. With on-demand on, this means the page just rendered live. |
To exercise on-demand specifically, hit a URL that's never been seen — append a random query string the system has never indexed, or pick a fresh path. With on-demand on you get miss followed by full HTML; with it off you get a passthrough.
Related
- Cache refresh rules — control how often cached pages re-render.
- Cache invalidation API — programmatically invalidate or prewarm.
