Base44 SEO: what’s handled for you, and where the ceiling is

How Base44 serves your pages

A Base44 app is a single-page React app: the browser downloads a small HTML shell and JavaScript, and the JavaScript draws the page. On its own, that’s a poor fit for search engines, which is why Base44 adds a layer for crawlers.

Base44’s search visibility documentation explains it: because apps run in the browser, a crawler would normally see an empty page, so Base44 serves crawlers a rendered version of your app instead, with your meta tags, structured data and real page content in the HTML. If a page hasn’t been rendered yet, Base44 falls back to a shorter version. People visiting your app still get the normal browser-rendered app.

That’s a genuinely useful feature, and it’s more than many builders offer. It also means how your pages look to Google is decided by a system you can’t see or tune.

What Base44 manages for you

On apps published to a custom domain, Base44 takes care of:

• Canonical tags on every page, stripping tracking parameters such as utm_* while keeping ones that change content.
• A sitemap at /sitemap.xml with your public pages. You can turn it off and deploy your own public/sitemap.xml, or serve a dynamic sitemap from a backend function and submit its URL to Google Search Console (each fetch counts as a function call).
• robots.txt, allowing search engines and AI crawlers to reach public content.
• llms.txt, an optional summary for AI crawlers, switched on from the SEO & GEO page.
• Titles and descriptions per page, and a search-visibility switch per page that adds noindex and removes it from the sitemap.
• Your index.html, editable in the Code tab for verification tags and third-party scripts.

Base44 also supports permanent (301) URL redirects, so old links keep working after you move a page (Apps API: domains and redirects), and runs an SEO and GEO scan that suggests fixes from the dashboard (Optimizing SEO and GEO).

The custom-domain requirement

Base44 is explicit that its SEO setup is designed and supported for apps published on a custom domain. Free base44.app addresses can still be crawled, but the documentation says they aren’t intended for long-term, production SEO, and the automatic files and social previews are built for custom domains.

Connecting a domain is a paid feature: Base44’s pricing lists it from the Starter plan up. So in practice, serious SEO on Base44 starts with a paid plan and your own domain.

Where the ceiling is

Most of the limits aren’t bugs. They’re what happens when rendering, caching and routing belong to the platform.

• Rendering is a black box. You can’t choose which pages are pre-rendered, when they are refreshed, or what the fallback contains. If a page renders badly for crawlers, your only lever is to change the app and publish again.
• Crawlers and people see different things. Search engines get the rendered snapshot; visitors get the JavaScript app. When the two drift apart, it’s hard to notice and harder to debug.
• Login walls stop indexing. Pages that require sign-in can’t be indexed, on Base44 or anywhere else. Keep marketing and content pages public.
• Dynamic content needs workarounds. Pages generated from your data, like a blog or a directory, need a sitemap from a backend function, and every crawler fetch uses a function invocation.
• Turning SEO off is drastic. Base44 documents that with the main SEO switch off, crawlers reach an empty page, even if robots.txt allows them.
• Headers, caching and performance are fixed. You can’t set cache rules, compression, security headers or edge behaviour on the server that serves your app.

For a small marketing site these rarely matter. For an app whose growth depends on search, such as a directory, a marketplace or a content site, they add up.

What changes when you run the server yourself

After a migration with Unbase44, your app is served by your own server, from your own repository, and your SEO settings come with it. Here is what that means in practice, including the part that is a trade-off.

Your server writes the tags. For every page, your server puts the title, description, canonical URL and Open Graph and Twitter tags from your SEO settings into the HTML it sends, for every visitor and every link preview, not only for crawlers. It serves robots.txt and a sitemap from the same settings, and marks private apps noindex.

Page content still renders in the browser. The body of each page is drawn by JavaScript, as it was for your human visitors on Base44. Google renders JavaScript and indexes such pages routinely, though other crawlers vary. What doesn’t come with you is Base44’s crawler-only snapshot. If fully pre-rendered HTML matters for your app, you can add prerendering or server-side rendering, because the server and the code are yours. That’s a change you make in your repository, with Claude Code, Cursor or a developer.

Everything else is yours to decide. Redirects, caching and compression, security headers, a CDN in front of the app, which host names serve it, and how long pages are cached. None of it needs a platform feature or a plan upgrade.

An SEO checklist for moving an app

Moving hosts is invisible to search engines if you’re careful, and expensive if you aren’t.

1. Keep your URLs identical. Same domain, same paths. If a path must change, add a permanent redirect from the old one.
2. Move the domain, not the content. Point your existing custom domain at the new app when you’re ready, so the addresses Google knows keep working.
3. Check what the new server returns. Load a few pages with “view source” and confirm the titles, descriptions and canonical URLs are right.
4. Avoid duplicate content. Once the new app is live on your domain, stop the old Base44 copy competing: turn off search visibility on it rather than unpublishing it, because it still needs to run while your users sign in for the first time.
5. Resubmit your sitemap in Google Search Console, and use URL Inspection on your most important pages.
6. Watch the coverage report for a few weeks for pages that drop out or error.