Blog · · 7 min

Lovable SEO depends on one date

Whether a Lovable site is crawlable depends on when the project was created. Since 13 May 2026 new apps render on the server; older ones are client-only and rely on pre-rendering served to verified crawlers, which is why an SEO scanner sees an empty page and Google does not.

By

"Do Lovable sites rank?" has two different answers, and which one applies to you is decided by a single date: 13 May 2026.

Projects created from that day forward are built on TanStack Start with server-side rendering, deployed to Cloudflare Workers. The server runs the React tree, executes the loaders and streams fully-formed HTML on the first request. A crawler gets content immediately.

Projects created before it are Vite plus React Router, client-rendered only, previously deployed as static files. The first response is close to an empty shell — a root div and a script tag — and the content exists only after a crawler executes JavaScript.

So the first thing to establish is not a tactic. It is which of the two you have.

Which one do you have

Open your published URL and view source — the real source, not the inspector, which shows the page after JavaScript has run. Headings, copy and meta tags in the raw HTML mean you are on the server-rendered stack. An almost-empty body with a script tag means the older one.

Lovable's documentation states that an older project can be upgraded to TanStack Start for full server-side rendering. That is the highest-leverage SEO action available on an older project, and it is one setting rather than a content strategy.

Why your SEO tool says the page is empty

This is the part that sends people in circles, and it has a clean explanation.

Older client-rendered Lovable projects are not left bare. Lovable applies on-request pre-rendering on deployed public URLs — but it serves that pre-rendered HTML only to verified crawlers: Google, Bing, social-preview bots, and AI engines including ChatGPT, Perplexity, Claude and Gemini. Because pre-rendering runs at request time, dynamically loaded content is included.

Everyone else — including third-party SEO scanners — gets the regular single-page app.

That means an audit tool can report "no H1, no meta description, empty body" on a page Google is indexing perfectly well. The tool is not wrong about what it received. It is wrong about what Googlebot received. Before rewriting anything on the strength of a red audit, check the page in Google Search Console's URL inspection, which shows what Google actually rendered. On this stack, a third-party crawl is not evidence.

The two stacks side by side

Created before 13 May 2026Created from 13 May 2026
FrameworkVite + React RouterTanStack Start
RenderingClient-side onlyServer-side rendering, with SSG and per-route CSR available
What a crawler receives firstPre-rendered HTML if verified; the SPA shell otherwiseFully-formed HTML, streamed
What a third-party SEO tool seesThe SPA shellThe real page
Upgrade pathCan be upgraded to TanStack Start

Lovable's own write-up of the migration reports that apps already using pre-rendering saw a 2.9% increase in organic search traffic and a 98.5% increase in traffic from AI tools such as ChatGPT and Perplexity. Those are the vendor's figures about their own platform, not an independent measurement, and the asymmetry between the two numbers is the interesting part: AI crawlers were the ones being starved. Search engines had learned to wait for JavaScript. The engines answering questions largely had not.

The domain detail that quietly costs you

One line in Lovable's custom-domain documentation is worth acting on: connected domains redirect between each other with 302 temporary redirects, not 301 permanent ones. You also cannot remove the default xxx.lovable.app URL, and only one primary domain is allowed per project.

A 302 tells a search engine the destination is temporary and the original URL should be kept — the opposite of what you want when you have moved a site onto its real domain and want the authority to follow. If your project is served on both the .lovable.app URL and your own domain, decide which is canonical and point a rel="canonical" at it, so the signal does not rest on the redirect type alone.

Two smaller ones from the same page: the project must be published before the domain serves content, and no AAAA record can be present on the domain you connect.

What SEO on a Lovable site will not fix

Everything above is about being reachable. None of it is about being convincing, and the two get conflated constantly.

You can fix the rendering, connect the domain, ship a clean sitemap and earn the ranking, and still watch the traffic leave without buying anything — because the page that ranks is a page a general-purpose builder composed, and no general-purpose builder composes a page that sells.

Ask Lovable, or Bolt, or v0, or a coding agent for buy 2, save 15% and you get a stepper: a number input with plus and minus buttons. We ran that prompt against two models with web search enabled and both returned exactly that, one citing no source at all. The reason is structural rather than a fault of any tool — there is no canonical spec on the open web for the component actually being asked for, so the model returns the nearest thing it has read a thousand times.

What was wanted is a radio group of named, pre-composed offers. A stepper asks how many, which is arithmetic the buyer has to perform; a radio group asks which package, and one of them is visibly the sensible one. That is the quantity break, and it is absent from every builder.

So are the other three: a free-shipping bar showing the amount still missing in money, an order bump whose box starts unchecked as Article 22 of Directive 2011/83/EU requires, and a sticky add-to-cart that waits for the inline button to leave the viewport.

This matters more on a page you worked to get ranked, not less: traffic makes an omission expensive. If sessions are still low, the order of operations is in ecommerce conversion rate optimization without traffic; if the page is a landing page rather than a shop, see SaaS landing page sections that convert.

The four components are specified, with their rules and their EU constraints, in the commerce kit.

FAQ

Is a Lovable site good for SEO?

It depends on when the project was created. From 13 May 2026, new Lovable apps use TanStack Start with server-side rendering, so a crawler receives real HTML on the first request. Older projects are client-rendered and rely on pre-rendering that Lovable serves only to verified crawlers. Lovable's documentation says an older project can be upgraded to the newer stack.

Why does my SEO tool see an empty page on my Lovable site?

Because on older client-rendered projects the pre-rendered HTML is served only to verified crawlers — Google, Bing, social-preview bots and AI engines such as ChatGPT, Perplexity, Claude and Gemini. Third-party SEO scanners are not on that list and receive the single-page app instead. Check the page with Google Search Console's URL inspection rather than trusting the third-party crawl.

Can I add meta tags and a sitemap on Lovable?

Yes. Lovable's SEO documentation covers metadata, sitemaps and robots.txt as things the platform handles. On the older client-rendered stack the value of those tags still depends on the pre-rendering described above, which is why establishing your rendering mode comes first.

Does ranking a Lovable page make it sell?

No, and the two problems are independent. A page can be perfectly crawlable and still lack every mechanic that raises a basket — a quantity break, a free-shipping threshold bar, an order bump, a sticky add-to-cart on mobile. No builder generates those, so they remain a deliberate addition after the SEO work is done.