How Base44 pre-rendering actually works

Base44 keeps a cache of pre-rendered pages. When a request arrives, it checks the user agent. A browser gets the normal React app. A recognized crawler gets the cached render if one exists, and otherwise a hidden, auto-written summary. Nothing is rendered while the crawler waits, and asking for a page doesn’t reliably get it rendered. What fills the cache, and when, isn’t visible from outside: Base44’s docs say renders refresh when you publish.

This explains the mechanism based on Base44’s documentation and on requests to 186 pages across 47 live Base44 sites, plus follow-up cache tests. For the big picture, start with the complete guide.

The request flow#

Browsers also receive the summary block, hidden with a 1-pixel clipping style and replaced as soon as React renders. And every response, rendered or not, carries the page head Base44 writes: title, description, canonical, Open Graph tags and JSON-LD.

Why it has to be a cache#

Median time to first byte was about 0.6 to 0.7 seconds for browsers, summaries and renders alike, and rendered responses on repeat requests came back in 0.3 to 1 second. Starting a headless browser, loading a React app and waiting for its data takes several seconds. So a crawler never gets a render made for its request. It gets a stored copy or the summary.

What we measured about the cache#

It’s consistent. Twelve pages with a render returned it on 8 of 8 rapid repeat requests.

It’s keyed by URL, ignoring tracking parameters. The same twelve pages with ?utm_source=... added returned the render at once, matching how Base44’s canonical tags strip tracking parameters. With a made-up content parameter such as ?b44check=123, they were a new cache entry and returned the summary on 13 straight requests over three minutes.

Requests don’t fill it. We requested 28 pages that were serving the summary every 10 seconds for four minutes with Googlebot’s user agent. None got a render.

Something fills it in the background. In the first test, 32 inner pages and 7 homepages switched from summary to render between two passes a few minutes apart. The schedule behind that isn’t visible, and Base44 doesn’t document it beyond “refreshes this rendered content when you publish.”

Renders expire. About a day later, 13 of 44 pages that had a render were serving the summary again.

What this means for SEO#

• A different page for crawlers. Every summary response gives a crawler a page visitors never see. Google only excuses a separate crawler version “as long as your dynamic rendering produces similar content,” so this is a cloaking risk on every page without a cached render.
• Content arrives late. After you publish a new page or change one, crawlers get the summary or a stale render until Base44 renders it on its own schedule. If Google falls back to rendering your JavaScript itself, the page waits in its rendering queue, which is the delay pre-rendering exists to remove.
• You can’t fix it from inside Base44. Requesting pages doesn’t render them, and there’s no setting to render a page on demand. Republishing is the only documented refresh.
• Coverage gaps. Pages that never get a render, renders that expire, record URLs outside the sitemap, and crawlers Base44 never renders for all leave parts of your site known to search engines only as near-identical summaries.

Recognition is by user agent#

Changing only the user-agent string, from the same IP address, switched the response between the app and the cached render. That’s why testing with curl -A works on Base44, and why tools with their own user agents, like Screaming Frog, Ahrefs or Google’s inspection tool, see the summary. The crawler list shows which user agents were recognized.

The render includes your data#

When a render exists, it’s a real one. On the sites we tested, renders included data loaded from the app: a reading app’s series page showed the series’ name and description, and a directory’s homepage came back with 12,965 characters of real content where its summary had about 1,200. Some renders were thin, like forgot-password screens, because the page itself is thin.

What the render doesn’t fix is the head. Titles on record pages stayed generic (“Series | StoryNook”) because Base44 generates titles from the page’s URL. See the record pages guide.

The main SEO toggle#

All of this depends on Enable SEO for this app staying on. Base44’s docs say turning it off “also disables prerendering,” after which crawlers get “a bare HTML shell with no page content.” To manage your own meta tags or JSON-LD, use the Platform meta tag injection and Platform structured data injection toggles in Advanced Settings instead.

What to do next#

1. Test your key pages with a crawler user agent using the testing guide.
2. Test again after your next publish to see which pages get rendered.
3. If important pages serve the summary, read the fix options.