Lovable's rendering story now has two parts. The current platform documentation says newer projects use TanStack Start with server-side rendering, while older React and Vite projects receive Lovable-managed prerendering on deployed public URLs.
That means the old blanket claim—“Lovable sites are client-rendered and need prerendering”—is no longer accurate.
The more useful question is: which Lovable generation is this, where is it hosted now, and what does the production URL actually return?
Quick answer
Many legacy, exported, and independently hosted Lovable projects still behave as client-rendered SPAs. Newer Lovable projects may include server rendering, and older projects hosted by Lovable may receive platform-level crawler rendering. Test the production site before adding another rendering layer.
Lovable says hosted projects on either supported stack are designed to provide crawler-readable output without an external prerendering service. That platform behavior should not be assumed to follow code exported to Vercel, Netlify, Cloudflare, or self-managed infrastructure.
Four Lovable deployment cases
| Project type | Likely situation |
|---|---|
| New Lovable-hosted project | Projects created from May 13, 2026 generally use TanStack Start with SSR; Lovable documents an Enterprise-plan exception, so confirm the actual stack |
| Older Lovable-hosted project | React and Vite projects remain SPAs for visitors, while Lovable says deployed public URLs are prerendered for recognised search, AI, and social-preview crawlers |
| Legacy Lovable project moved to Vercel or Netlify | Usually remains a React/Vite SPA unless SSR, static generation, or another rendering layer was added |
| Exported or heavily modified project | The framework, host, routing, and crawler output must be tested individually |
See Lovable's current platform FAQ, SEO and AI search guide, and external deployment guide for the platform's own description of these paths.
Rendering status
| Question | Current answer |
|---|---|
| Default framework | Newer projects: TanStack Start; older projects: React + Vite |
| Hosting environment | Lovable-hosted public URL or an independently managed deployment |
| Is SSR automatic? | Generally for new Lovable-hosted projects created from May 13, 2026; confirm the project and plan |
| Does crawler-specific rendering exist? | Lovable says older hosted React/Vite projects are prerendered for recognised crawlers |
| What happens after export? | The exported application's framework and the new host determine the response; Lovable's managed crawler path should not be assumed to follow it |
| Could external prerendering still be needed? | Yes, but only when testing an exported, migrated, modified, or otherwise unsupported deployment shows thin crawler HTML |
How to identify your case
Check the repository and deployment rather than guessing from the brand name.
- A TanStack Start project has server-oriented framework configuration and routes.
- A legacy project commonly has Vite scripts, a client entry point, and React Router.
- An exported deployment may build to a static
distdirectory and use an SPA fallback rewrite. - A custom domain may point either to Lovable hosting or to another platform entirely.
The date is a useful clue, not a substitute for inspecting the actual project.
Who this is for
- Founders who shipped a Lovable site quickly
- No-code teams using a custom domain
- Agencies maintaining Lovable client sites
- Builders whose page looks done but may not be crawler-readable
What to test on the production site
Test the final canonical hostname—not only the Lovable editor preview or an old *.lovable.app URL.
For the homepage and important deeper routes, compare:
- a normal raw HTML request
- Googlebot-style output
- AI crawler-style output for the agents you care about
- title, description, canonical, Open Graph tags, and structured data
- the primary H1, body copy, and internal links
- root and
wwwbehavior when both hostnames resolve
A page returning HTTP 200 is not enough. The response should contain meaningful route-specific content.
When Prerender Buddy fits
Prerender Buddy is most relevant when a legacy or exported Lovable React/Vite application is already deployed outside Lovable and crawler tests show an empty or partial shell.
It can also help when the production deployment needs crawler coverage beyond the platform-managed path, independent output verification, or monitoring across hosting changes.
It is usually unnecessary when a Lovable-hosted project already returns complete HTML to the crawlers that matter.
You may not need Prerender Buddy if
- Server HTML is already complete.
- Static pages crawl correctly.
- You are already rebuilding with SSR or static generation.
- You only need an audit, not a rendering fix.
Lovable rendering decision tree
- Is the project currently hosted by Lovable?
- Was it created before or after Lovable's May 13, 2026 rendering change?
- Is the deployed project still React/Vite or does it use TanStack Start?
- Was the frontend exported, migrated, or substantially modified?
- Does the raw HTML contain the primary heading, page copy, metadata, and links?
- Do Googlebot and the AI crawler user agents you care about receive the same meaningful content?
Use the result this way:
- Meaningful HTML returned: no external rendering service may be needed.
- Empty or partial HTML returned: add SSR, static generation, or Prerender Buddy based on the project's lifecycle.
- Different crawlers receive different results: verify crawler coverage and decide whether the existing platform path is sufficient.
Bottom line
Test first. Add Prerender Buddy only when the production deployment does not return meaningful HTML to the crawlers you care about.
Check what crawlers receive
Check what crawlers actually receive from your Lovable site.
If your production deployment still returns an empty JavaScript shell, Prerender Buddy can provide crawler-ready HTML without rebuilding the application.
Check the site before changing the stack
- Bulk Crawler Readability Checker to sample important pages or sitemap URLs
- Raw HTML vs Rendered HTML to confirm whether JavaScript adds the missing content
- Bot View Checker for a deeper check of one affected page
Implementation guides
- Lovable setup for the public domain and builder origin
- Root vs www to keep both hostname variants consistent
Final recap
Lovable SEO and Prerendering comes down to what search engines and AI crawlers actually receive from your site.
Prerender Buddy does not guarantee rankings or AI citations. It helps with one specific technical problem: making sure crawlers receive readable rendered HTML instead of a thin JavaScript shell.
The first step is to check what bots see.
Check your website
Scan important pages from this site to test whether the site sends readable HTML to search engines and AI crawlers.