Lovable added SSR. AI search visibility is still on you.
Since May 13, 2026, new Lovable apps ship with server-side rendering by default. The empty HTML shell that made Lovable sites unreadable for AI crawlers is gone for new projects, and older projects now serve pre-rendered pages to verified crawlers. The rendering problem is solved. Visibility in AI search is a different problem, and Lovable's own docs say it is still yours.
This post started in April as a warning. A founder had shown me their Lovable site, and every crawler test returned an empty div where the content should be. Then Lovable shipped the fix, and the warning needed a rewrite. Here is where things stand now.
What Lovable fixed in May 2026
Until this spring, every Lovable project was a React single-page app. The server sent an empty <div id="root"></div> and JavaScript assembled the page in the browser. Fine for humans, useless for AI crawlers. Glenn Gabe of GSQi confirmed in testing that ChatGPT, Perplexity, and Claude fetch raw HTML and do not execute JavaScript. Whatever is missing from the initial response does not exist for them.
Two changes ended that era, both documented in Lovable's changelog:
- New apps created since May 13, 2026 run on TanStack Start with server-side rendering. Every request returns fully rendered HTML, to humans and crawlers alike. Enterprise workspaces followed on June 22.
- Older React + Vite apps get on-request pre-rendering on their deployed public URLs. Lovable serves a rendered snapshot to verified crawlers: Google, Bing, social preview bots, and AI engines including ChatGPT, Perplexity, Claude, and Gemini.
If you publish a Lovable site today, the major AI engines can read it. Anyone telling you otherwise is working from pre-May information. That includes older curl tests: an outside scanner is not a verified crawler, so it still gets the empty shell on older sites, which proves nothing about what the real bots see.
Where the gaps still are
Rendering is the floor, not the ceiling. Three gaps remain.
The verified-crawler list is short. Pre-rendering on older sites covers a named list of bots and nothing else. Smaller AI engines, agent browsers doing research for their users, and any fetcher outside the list still receive the empty shell. Only new TanStack Start apps serve full HTML to every visitor. The pre-rendering also applies to deployed public URLs only, so previews and unpublished projects stay dark.
Metadata, schema, and sitemaps stay manual. Lovable's docs list what you still have to prompt for yourself: unique titles and descriptions per route, structured data, sitemap accuracy, robots.txt rules, and Open Graph tags. The platform can apply many of these fixes when you ask its agent. It does not provision them on its own. Rasesh Koirala's independent guide lands in the same place: SSR does not generate correct SEO tags or structured data for you.
Rendered HTML is not answer-ready HTML. AI engines cite pages that answer a question in their first clear statement and whose sections hold up as standalone extracts, with schema marking up the entities. That is editorial work. No rendering mode does it, on Lovable or anywhere else.
| Layer | Status after the update |
|---|---|
| Full HTML for Google, Bing, and major AI engines | Fixed on new apps; older apps covered for verified bots |
| Full HTML for other agents and scanners | New apps only; older apps still serve the empty shell |
| Titles and meta descriptions per route | Manual, prompt and review each route |
| Structured data | Manual |
| Sitemap accuracy and robots.txt | Manual |
| Answer-first content structure | Editorial work, ongoing |
When a migration to Next.js still pays off
The case for moving to an owned Next.js SSG codebase changed shape. Rendering is no longer the headline reason. Ownership is. You get a standard repository any developer or coding agent can work on, static pages that hit strong Core Web Vitals without tuning, and no dependency on one platform's rendering pipeline or crawler allowlist. If Lovable changes its stack again, that is their roadmap decision, not yours.
The DIY path with Claude Code or OpenAI Codex works the same as before: export your code, have the agent rebuild it as a Next.js App Router project with static generation, review every file, push to GitHub, deploy on Vercel, point your DNS at the result. Budget real time for the review step. When Cloudflare's engineers rebuilt Next.js with AI coding agents earlier this year, they shipped in a week and still reported that the agents needed steady manual correction. The agent does the rote work. The judgment calls stay with you.
What this means if you built with Lovable
Three checks, in order. First, look up when your project was created. Before May 13, 2026 means your public site serves real HTML to the big verified crawlers and an empty shell to everyone else, so decide whether that long tail matters for your business. Second, view your page source and look for a title, a meta description, and schema on each route. If they are missing, no rendering mode will save you, because there is nothing there to cite. Third, decide what the site is for. A brochure runs fine on Lovable's defaults now. A growth channel needs the metadata, schema, and content layer that still does not build itself.
That layer is what we do. webentity migrates Lovable sites to a clean Next.js SSG codebase as a one-time delivery. You get the repo, the deployment, and the DNS handoff, and the code stays editable with Claude Code or Codex afterwards because it is a standard Next.js project. If the site is a growth channel, the Grow plan keeps the schema and content work moving daily after launch. See what we build and how it worked for Alveni.