Doesn't Google render JavaScript now?

Yes, but with significant limitations. Google's two-pass indexing renders JS but with a delay of days to weeks, and the rendered version sometimes drops dynamic content the crawler considered slow or expensive. Many sites with CSR-only stacks see 30-70 percent fewer pages indexed than equivalent SSR sites. AI search crawlers (Perplexity, ChatGPT, Bing Copilot) are even less reliable on JS-heavy pages. Treating CSR as an SEO-neutral choice is wrong.

Will adding meta tags via JS fix the indexing problem?

Partially and unreliably. Google can read JS-injected meta tags during the second pass, but title and description can be missed if the second pass is delayed or never completes. AI crawlers usually do not execute JS at all, so JS-injected meta is invisible to them. Server-rendered or pre-rendered HTML with the title and meta description in the initial response is the only reliable solution.

Can I just add a sitemap and robots.txt and call it done?

No. Sitemaps and robots.txt help crawlers find your URLs but do not help them see your content. If the URL resolves to an empty HTML shell, Google can crawl it but cannot index meaningful content. The fix is in the response body, not the discovery layer. Sitemaps are still useful as a complement once your pages render content server-side.

How much traffic am I losing to CSR right now?

Hard to measure precisely without an SSR baseline, but estimates from Merebase and other audits suggest 50-80 percent of potential organic traffic is lost when a content site relies on Base44's CSR default. For pure SaaS apps with no marketing site dependency on Base44, the loss is mostly on the marketing pages. For content-driven apps (directories, marketplaces, blogs), the loss is severe enough to make Base44 the wrong primary platform.

Is migrating to Next.js the only real fix?

It is the most direct fix, but not the only one. A pre-rendering proxy (Prerender.io, Rendertron, or a Vercel function in front of Base44) can serve cached, fully-rendered HTML to crawlers while users still get the SPA. This is a workable mid-step. The full migration is the right move when SEO is a primary acquisition channel, because pre-rendering is an additional moving part and adds operational cost.

Fix Base44 CSR Making Your App Invisible to Google

What's happening

You launched your Base44 app. You wrote a homepage with strong copy targeting your main keyword. You added a blog. You requested indexing in Google Search Console. A month later, you check rankings and you have no organic traffic. Search for your exact title and you find nothing.

The reason: Base44 ships your app as a single-page application that renders client-side. Google's crawler initially sees something close to this:

<!DOCTYPE html>
<html>
  <head><title>App</title></head>
  <body>
    <div id="root"></div>
    <script src="/main.bundle.js"></script>
  </body>
</html>

Your title says "App." Your body is empty. Google has nothing to index until JavaScript renders, and JavaScript rendering happens on a slower, less reliable second pass.

Merebase covered this in their analysis of vibe-coding platforms: "Base44 generated web apps are invisible to Google...CSR penalty." The feedback board has a top-voted post titled "Essential SEO Improvements" with 199 upvotes specifically requesting SSR support.

For content-heavy apps — marketplaces, directories, blogs, anything that needs organic traffic — this is a structural problem. You did not build an SEO-disadvantaged app by accident; the platform built it for you.

Why this happens

Base44 generates React-based single-page apps. The runtime mounts a root component into <div id="root"> after the JavaScript bundle loads, parses, and executes. The HTML response from the server contains no rendered content for any page in the app, including the homepage.

Three issues compound for search and AI visibility.

Two-pass indexing delays. Google indexes JS-heavy pages in two passes: first the empty HTML shell, then a deferred render pass that may run days or weeks later. During the gap, your page is in Google's index with no meaningful content. Competitors with SSR get content indexed on the first pass and reach top results before you appear at all.

Inconsistent JS execution by crawlers. Googlebot is the most capable JS-rendering crawler in the wild. AI search crawlers (Perplexity, ChatGPT search, Bing Copilot, Gemini) are far less consistent. Some never execute JS. Some execute but with strict resource budgets. AI Overviews citation rates are weighted heavily against JS-rendered-only sites.

Per-page meta tags missing. React Router-style apps update the page title and meta tags in JavaScript after route changes. Crawlers that hit /blog/post-1 directly see the same generic title as /. Even when JS executes, dynamic meta updates often happen too late to be picked up. The result: every page in your app has effectively the same title in Google's eyes.

Sources: merebase.com/vibe-coding-platforms-seo, feedback.base44.com post "Essential SEO Improvements" (199 upvotes), Google Search Central documentation on JavaScript and indexing.

How to reproduce

Open your Base44 app. Note the URL and the page title in your browser tab.
Disable JavaScript in your browser (DevTools → Settings → Disable JavaScript, or use a JS-disabled environment).
Refresh the page.
Note what you can see. For most Base44 apps you will see a blank page or a loading spinner.
Re-enable JavaScript. Open DevTools → Network → fetch the URL again. Click the document request. Look at the Response tab. The HTML should contain almost no body content — just a script tag and an empty root div.
Use Google's URL Inspection tool in Search Console. Run "Test live URL." Look at the rendered screenshot and the rendered HTML. Compare to the actual rendered page in your browser. Note any missing content in the rendered version.
Search Google for site:yourapp.base44.app. Compare indexed page count to your actual page count. The gap is your CSR penalty.

Step-by-step fix

There are three workable paths. Pick based on your traffic stakes.

Path A: Pre-rendering proxy (cheapest, fastest, partial fix)

Place a pre-rendering proxy in front of Base44. The proxy detects crawler user-agents, fetches the page from Base44, runs a headless browser to render the JS, caches the rendered HTML, and serves the cached HTML to crawlers. Real users continue to hit Base44 directly.

Tools: Prerender.io ($90/month and up), Rendertron (open source, self-hosted), or a custom Vercel/Cloudflare Worker function.

# Sample Prerender.io middleware on a Cloudflare Worker
addEventListener("fetch", (event) => {
  event.respondWith(handle(event.request));
});

async function handle(request) {
  const ua = request.headers.get("user-agent") ?? "";
  const isCrawler = /Googlebot|Bingbot|Yandex|DuckDuckBot|PerplexityBot|ChatGPT/i.test(ua);
  if (!isCrawler) return fetch(request);

  const url = new URL(request.url);
  const prerenderUrl = `https://service.prerender.io/${url.toString()}`;
  return fetch(prerenderUrl, {
    headers: { "X-Prerender-Token": "YOUR_TOKEN" },
  });
}

Point your custom domain at the worker. Crawlers get pre-rendered HTML; users get the SPA. This works, but adds a cache layer to manage and an external dependency.

Path B: Critical pages on a separate SSR-rendered host

Move your highest-SEO-value pages — homepage, pricing, top blog posts — onto a separate Next.js or Astro site that renders server-side. Keep the application itself on Base44. Use subdomain routing or path-based routing.

yourdomain.com           → Next.js (marketing, blog, SEO)
app.yourdomain.com       → Base44 (the SaaS application)

This is what most teams end up doing once SEO becomes important. You get clean SSR for the pages that need it, you keep Base44 for the application, and the migration scope stays manageable.

Path C: Full migration

If your business is content-driven (publication, directory, marketplace) or if SEO is your primary acquisition channel, migrate the entire stack to Next.js + Supabase or equivalent. You will not solve CSR for SEO inside Base44 — the platform team has acknowledged the limitation but not shipped SSR.

This is a larger project. Plan 4-12 weeks depending on app size. See Vendor lock-in via SDK dependency for the decoupling work that must precede the migration.

In all paths: fix per-page meta tags

Inside Base44, ensure every route updates document.title, the meta description, and Open Graph tags on route change. The agent often does not generate this code by default. Audit each route file and add explicit useEffect hooks that update these on mount.

useEffect(() => {
  document.title = "Pricing — YourApp";
  document
    .querySelector('meta[name="description"]')
    ?.setAttribute("content", "Plans, billing, and credit-pack details.");
}, []);

This helps with the second-pass indexing on Googlebot and is essentially free.

Add structured data via JSON-LD inline scripts

Even on CSR pages, you can inject JSON-LD <script type="application/ld+json"> blocks. Some crawlers (including Googlebot) read these without full JS rendering. This is detailed in the schema markup fix.

DIY vs hire decision

DIY this if: You are technically comfortable, your traffic stakes are moderate, and you can use Path A (pre-rendering proxy). Setup is 4-8 hours. Ongoing cost is low.

Hire help if: SEO is your primary acquisition channel, your competitors rank for your target keywords and you do not, or you need to ship the marketing site fast and the rest of the app later. Path B (split SSR marketing site) is a typical small-to-medium engagement. Path C (full migration) is a larger migration project with 4-12 weeks of timeline.

Need this fixed before your next launch?

For pre-rendering setup, our complex-fix engagement ships the proxy, validates indexing across crawlers, and instruments search-console verification. For larger SEO recoveries, our migration service moves the marketing surface to a Next.js stack with full SSR while keeping the application on Base44.

Start a complex-fix engagement for SEO recovery

No schema markup or dynamic meta tags — the sibling SEO problem you also need to fix.
Vendor lock-in via SDK dependency — the decoupling work that precedes a full SSR migration.
Editor hangs and crashes on large apps — performance signals that suggest you have outgrown Base44 as a primary platform.