Pre-rendering a Base44 app: what Base44 does, what it misses, what to do

Base44 pre-renders your pages for search and AI crawlers, as long as your app is on a custom domain. It serves those renders from a cache, and only to crawlers it recognizes. A page with no cached render gets an auto-written summary of your app, nothing is rendered while the crawler waits, and requesting the page doesn’t get it rendered. That design is bad for SEO: crawlers get a different page from visitors, which Google’s policies treat as cloaking territory, the real content reaches them late, and many pages are never rendered at all.

This guide covers why Base44 apps need pre-rendering, what Base44 does, where the gaps are, and how to decide what to do about them.

Why a Base44 app needs pre-rendering#

Every Base44 app is a React app built with Vite and rendered in the browser. When anything requests a page, Base44’s server sends a small HTML document: some scripts, some meta tags, and an empty <div id="root">. The page itself is built by JavaScript after it loads, and its data arrives from Base44’s backend through the SDK.

Browsers run that JavaScript. Most crawlers don’t:

• Googlebot can render JavaScript, but renders in a second pass that can lag behind the first crawl.
• Most AI crawlers, including the ones behind ChatGPT, Claude and Perplexity answers, read the HTML they’re sent and move on.
• Link-preview bots from Slack, LinkedIn and WhatsApp read the page head and nothing else.

Pre-rendering fills the gap: something renders the page in a real browser ahead of time and sends crawlers the finished HTML.

What Base44 does on its own#

Base44’s SEO documentation describes two layers:

1. A rendered version for crawlers. “The platform automatically serves crawlers a rendered version of your pages, including meta tags, structured data, and your real page content.” Base44 refreshes it when you publish.
2. A fallback when the render isn’t ready. “A structured snapshot carrying that page’s heading, its description, and links to your other pages.” In the HTML, that’s a hidden block with the id seo-snapshot. The snapshot guide takes it apart.

When we tested this on live sites, the render was real: it contained the page’s headings, copy and data loaded from the app. What varied was whether a crawler got it. The mechanism guide explains the timing.

Where the gaps are#

In a test of 186 pages on 47 live Base44 sites, five problems showed up again and again.

1. Crawlers and visitors get different pages. When no render is ready, a recognized crawler gets a hidden summary: a heading, a stock app description and a list of links. Visitors get your page. Google’s dynamic rendering guidance accepts a separate crawler version only “as long as your dynamic rendering produces similar content,” and its spam policies list “inserting text or keywords into a page only when the user agent that is requesting the page is a search engine” as cloaking. The summary is text that exists only for crawlers.

2. First visits get the summary. A first Googlebot request got the rendered page on 34% of inner pages and 49% of homepages. Minutes later those numbers rose to 57% and 64% as Base44 filled its cache in the background, on a schedule that isn’t visible. Requesting pages ourselves didn’t fill it. A new page’s first crawl is the one most likely to see the summary.

3. Some pages never got a render, and renders expire. After two passes, 31% of inner pages were still summary-only. A day later, 13 of 44 pages that had been rendered were serving the summary again.

4. Some crawlers are never rendered for. Base44 decides by user agent. Google-InspectionTool (behind Search Console’s live test), GoogleOther, Bravebot, Meta-ExternalAgent, Amazonbot, CCBot and others only ever got the summary. The crawler list has the full split.

5. Record pages are thin. Pages that show records, like /Product?id=123, aren’t in Base44’s sitemap, share one generic title, and in our spot checks were the least likely to have a render. The record pages guide covers them.

Do you need to do anything?#

Test before you decide. The testing guide has the full routine, and the core of it is one command:

UA='Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)'
curl -s -A "$UA" https://yourdomain.com/pricing | grep -c 'id="seo-snapshot"'
# 0 = rendered page, 1 = summary

Then use this table:

The options#

1. Monitor what crawlers get after every publish with a script. Requesting pages doesn’t make Base44 render them, so this tells you where you stand without fixing anything. See can you warm Base44’s cache?.
2. Put a pre-rendering service in front of your domain. It renders every page ahead of time and serves the result to every crawler you choose. Encited has a documented Base44 setup, serves Markdown to AI agents, and logs which bot fetched which page. Prerender.io is the long-standing alternative. The setup guide compares them.
3. Build your own proxy with a Cloudflare Worker and a headless browser. See the Worker guide.
4. Export and move to server rendering. Full control, and a rebuild. See pre-rendering vs SSR.

What to do next#

1. Run the test command on your homepage and five inner pages.
2. Read your results against the table above.
3. Pick the lightest option that closes the gaps you found.