Lovable Prerendering: How It Works, When It Fails

What Lovable prerendering actually does

A React + Vite app ships a near-empty index.html plus a JavaScript bundle. The browser runs the bundle and builds the page. A crawler that does not run JavaScript sees almost nothing.

Prerendering closes that gap. When a request comes from a bot Lovable recognises, Lovable renders the page on the server and returns finished HTML. The bot gets headings, paragraphs, links and the title, not a blank <div id="root">.

This happens on request, per page. It is not a build step you can inspect in your repository, and it is not something that travels with your code.

• Who gets HTML — verified search engines, link-preview bots and AI crawlers.
• Who gets the shell — regular browsers, which then run the bundle, and any tool Lovable does not recognise.
• Where it runs — Lovable hosting only, as part of the platform.
• Which apps need it — apps created before 13 May 2026, which are React + Vite and client-rendered.

Server rendering versus prerendering

Apps created from 13 May 2026 use TanStack Start and are server-rendered. Every visitor and every crawler gets full HTML on the first response. There is no bot detection in the middle, because there is nothing to detect around.

Older apps rely on prerendering instead. The end result for Google is similar, but the mechanism is different, and the difference matters the moment you move the site.

To tell which kind you have, look at the code. Newer apps have file-based routes in src/routes, each with a head() that sets the title, description and JSON-LD. Older apps have pages in src/pages and routes declared in src/App.tsx.

If you are weighing up what Google sees in each case, we go deeper in is Lovable good for SEO.

When prerendering is not enough

Prerendering solves one problem well: crawlers that do not run JavaScript. It does not solve everything around it.

The most common surprise is auditing. Run an older Lovable app through a third-party SEO crawler and the report comes back almost empty. The scanner is not a verified bot, so it receives the app shell. Your pages are probably fine for Google; the tool simply cannot see them.

The second surprise is hosting. Prerendering belongs to Lovable hosting. Export the same project to Netlify, Vercel or Cloudflare Pages and you get static files that render in the browser. Nothing prerenders unless you add it yourself.

The third is per-page metadata. Older React + Vite apps do not carry per-page titles, descriptions and Open Graph tags the way newer apps do through head(). Prerendering returns HTML; it does not invent meta tags that the project never had.

• Audits look broken — third-party scanners see the shell, not the prerendered page.
• Moving hosts drops it — a static host serves files, not a prerenderer.
• Meta tags stay thin — older apps often have one shared title and description.
• No control — you cannot tune, debug or log the prerender yourself.

How to check what a crawler sees

Do not guess from an SEO tool's score. Look at the raw response, then at the rendered page, and compare.

If the raw HTML is empty in a plain browser request, that is expected for an older app. The question is what the verified bots receive, and Google Search Console is the honest answer for that.

1. View source, not inspect — open the page and use view-source. The inspector shows the rendered DOM, which always looks fine.
2. Request it without JavaScript — disable JavaScript in your browser and reload. An older app will show a blank page.
3. Use Search Console — run URL Inspection on a live URL and read the rendered HTML Google holds.
4. Check a link preview — paste the URL into a chat app and see whether a title and image appear.
5. Repeat per page — prerendering is per request, so test the homepage and at least two deep pages.

Options when you need HTML for everyone

If you want every request to return real HTML, you have three honest routes.

Stay on Lovable hosting and keep the prerendering. This is the least work. You accept that external scanners will keep reporting an empty page, and that the behaviour is tied to the platform. Our Lovable hosting guide covers what that includes.

Rebuild or recreate the project as a newer TanStack Start app, so rendering happens on the server for everybody. Whether an existing project can be migrated in place is not something we can state; check Lovable's documentation before you plan around it.

Self-host the export and add prerendering or server rendering yourself. The build is standard: npm install, then npm run build on Node 22, which writes static files to dist/. Adding a prerender step to that pipeline is a developer task, not a setting.

The fourth route is to stop depending on JavaScript rendering at all, which is what moving to WordPress does.

Why WordPress removes the question

WordPress renders pages on the server for every request. There is no bot list, no shell, no difference between what a browser, an auditor and a crawler receive. Titles, headings, links and structured data are in the first response.

That is the practical reason some teams convert. Our converter turns a Lovable ZIP or GitHub repository into a WordPress block theme: templates, header and footer template parts, one pattern per page, theme.json with your palette and fonts, and your images copied in. Conversion, review and the theme download are free.

Per-page titles and descriptions from a newer app's head() are written into Yoast, Rank Math or SEOPress, and JSON-LD comes across. For older React + Vite apps there is usually no per-page meta to carry, so you write it once in the SEO plugin after install. Open Graph tags are not converted either way.

Interactive parts do not survive the move: custom React state, event handlers, Supabase, authentication, dashboards and API calls. See supported features for the full list before you decide.

One setting to remember on a new WordPress install. Settings → Reading has a checkbox called "Discourage search engines from indexing this site". Leave it checked while you test, and uncheck it before launch.

FAQ

Does Lovable prerendering apply to all Lovable sites?

No. It applies to apps created before 13 May 2026, which are React + Vite and render in the browser. Apps created from 13 May 2026 use TanStack Start and are server-rendered for every visitor, so prerendering is not needed. Prerendering also only runs on Lovable hosting.

Why does my SEO tool say my Lovable page is empty?

Lovable prerenders pages only for verified search engines, link-preview bots and AI crawlers. A third-party SEO scanner is usually not on that list, so it receives the empty app shell. Check Google Search Console URL Inspection instead, which shows what Google actually rendered.

Do I keep prerendering if I move my Lovable site to another host?

No. Prerendering is part of Lovable hosting. On Netlify, Vercel or Cloudflare Pages the build output is static files, so an older app is client-rendered unless you add a prerendering or server-rendering step yourself. That is developer work, not a setting.

Does prerendering fix missing titles and descriptions?

No. Prerendering returns the HTML the app would produce, so it cannot add metadata the project does not have. Older React + Vite apps often share one title and description across all pages. Newer TanStack Start apps set them per route in head().

Is converting to WordPress a way around prerendering?

Yes, in the sense that WordPress serves server-rendered HTML to every request, with no bot detection involved. The IQDesk converter turns a Lovable ZIP or GitHub repository into a WordPress block theme, and conversion and download are free. Interactive React features such as custom state, Supabase and dashboards do not convert.

Keep reading