Our most-read article explains a Lovable problem that Lovable has since changed.
In August 2025 we wrote that Lovable sites were hard for Google and AI tools to read, because their pages were built in the visitor’s browser. On May 13, 2026, Lovable changed how it serves those pages. The change matters less for how you build a Lovable site than for how you test one.
This describes sites published on Lovable’s hosting. If you exported your project and host it elsewhere, check that deployment separately.
Key takeaways
- New Lovable apps created from May 13, 2026 (June 22 for Enterprise workspaces) render on the server, so every visitor and crawler gets a rendered page.
- Older Lovable apps serve rendered pages only to crawlers Lovable verifies. Lovable says third-party scanners and other unverified agents get the regular app shell.
- An empty result from curl, View Source or a scanner tells you what that request received. On an older Lovable app, it may not be what Google or a verified AI crawler received.
- Before paying to fix an “invisible” site, ask what was tested, by what, and what the result actually proves.
What did Lovable change on May 13, 2026?
Two things, depending on when your app was created.
According to Lovable’s documentation, apps created from May 13, 2026 use TanStack Start, which renders pages on the server. For Enterprise workspaces, the date is June 22, 2026. Lovable’s hosting documentation says every visitor and crawler of these apps receives a fully rendered page.
Older apps still use React and Vite and still build pages in the browser. For those, Lovable announced on May 13, 2026 that pre-rendering was live across all existing apps, with no action needed from owners. When a verified crawler requests a page, Lovable renders it on the spot and returns the HTML.
Lovable’s SEO and AI search documentation lists who counts as verified: Google, Bing, social preview bots, and AI engines including ChatGPT, Perplexity, Claude and Gemini. Older projects can also be upgraded to TanStack Start to get server rendering for every visitor.
All of this is Lovable describing its own platform. We have not independently tested it across sites yet.
What did our 2025 article get wrong?
More than the platform change.
Our original article described changes to our site and reported that Google had indexed 15 of its 16 pages. We stretched that evidence too far when we described the site as indexed by AI systems too. Google indexing did not establish that.
We also generalised from our implementation to Lovable sites more broadly. One site, one fix and one Google result is a case, not a rule about a platform.
The fix we described needs a fresh look too. Lovable’s documentation says sitemaps, robots.txt and metadata are not always generated up front, so checking them still makes sense. Before rebuilding page delivery, establish whether the relevant crawler is already receiving the content.
Why can an empty test result be misleading?
Because the same URL now has different delivery paths, and most tests only show you one of them.
On an older Lovable app, Lovable’s documentation describes it like this:
A person in a browser. The regular app shell, which the browser then builds into the page by running JavaScript.
A verified crawler (Google, ChatGPT and others). Pre-rendered HTML.
A third-party scanner, link checker or other agent. The regular app shell. Whether the scanner then renders the main content depends on the scanner.
Lovable is direct about the consequence: third-party SEO scanners are not verified crawlers, so they may report pages as empty even though Google, social platforms and AI search engines see the full content.
That reaches beyond scanners. View Source shows the shell your browser received before JavaScript ran.
A curl request shows what that request received. Simply changing a request’s user agent to a crawler’s name does not establish that Lovable will treat it as a verified crawler. Lovable’s public documentation identifies the verified crawler categories but does not explain its verification mechanism.
The scanner implementation we reviewed sends sites to Google PageSpeed Insights and Cloudflare’s agent-readiness checker, and we have not yet tested how either responds to an older Lovable app.
None of this means empty results are always wrong. An empty result is a fact about one request, not a verdict about your site.
Which checks prove what?
Each check concerns the requester or system it tested. None of them answers the next question.
Page delivery. View Source and curl show what one specific request received. On a server-rendered site, that is a strong signal. On a pre-rendered site, it is a partial one.
Google access. The URL Inspection live test in Google Search Console shows how Google’s inspection tool rendered the page. Look at the rendered HTML as well as the screenshot, since the HTML shows whether your actual text is there. Google’s help documentation says the live test is separate from Google’s stored index data and that a valid result does not guarantee indexing.
Google indexing. The indexed status in URL Inspection tells you whether Google stored the page. That says nothing about what AI systems have read.
AI crawler visits. If your host gives you access logs, requests from OpenAI’s crawlers can be checked against the IP ranges OpenAI publishes. A request whose user agent and source IP match OpenAI’s published information establishes that an OpenAI-operated crawler requested that URL. The status code and response size provide additional delivery evidence, but they do not by themselves prove what page content the crawler parsed or used.
Mentions and citations. Asking ChatGPT about your category, several times, records what happened in those tests. A business mentioned by name is different from a linked citation to your page. Neither result measures your overall visibility, and neither shows why it happened.
Business outcomes. Track enquiries, qualified leads and sales separately. Technical checks can help investigate obstacles, but they do not establish commercial results.
What should you ask for before paying for a fix?
Ask for the evidence behind the diagnosis, in this order.
First, where is the site hosted, and does the current deployment use React and Vite or TanStack Start? An older React and Vite app that has not been upgraded is delivered differently from one built on TanStack Start.
Second, what tool produced the “empty” result, and is it one of the requesters Lovable verifies? Third, what does the URL Inspection rendered HTML show for the same page?
If the only evidence is a scanner screenshot, you have a question, not a diagnosis. That applies to our scanner as much as anyone’s.
A test result is a fact about one request. Treat it as a verdict about your whole site and you can end up paying to fix something that was never broken.
Want to go deeper? Our books explain AI visibility for business owners — from understanding how AI finds information to investigating what needs fixing. Explore the books.
Originally published on Medium