Lovable SEO: What Pre-rendering Fixes, and What Our Own Migration Measured

How does Lovable handle SEO now?

Two ways, depending on when the app was created. Lovable's SEO documentation, read on 26 September 2026: “New apps created from May 13, 2026 use TanStack Start with server-side rendering (SSR). Every request returns fully rendered HTML, for humans and crawlers.” And for the rest: “Older React + Vite apps use on-request pre-rendering on deployed public URLs”, which is “only served to verified crawlers: Google, Bing, social-preview bots, and AI engines like ChatGPT, Perplexity, Claude, and Gemini.” Both shipped on 13 May 2026 with the Discoverability release, which added an SEO review and Semrush-backed keyword research to the chat.

The sentence that matters most is the docs' last one on the subject: “Ranking still depends on factors outside Lovable's control, including content quality, search intent, backlinks, competition, performance, and search ranking algorithms.” Everything below is about the gap between what the platform fixes and what it cannot.

Is a single-page app invisible to Google?

No, and the pages that say so are usually selling the fix. Google's own JavaScript SEO basics describes three phases, crawling, rendering and indexing, and says: “Googlebot queues all pages with a 200 HTTP status code for rendering”, and “Once Google's resources allow, a headless Chromium renders the page and executes the JavaScript.” The catch is the queue: “The page may stay on this queue for a few seconds, but it can take longer than that.” Google's conclusion is measured, and worth quoting in full: “server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.”

Our own case is the proof. This site ran as a Lovable-built React + Vite app until 25 July 2026. Its index.html, still in our repository, is 3,291 bytes with an empty root element, 0 characters of visible text, no structured data and no canonical tag, plus a noscript fallback of 190 characters. In its last four weeks it drew 28,591 impressions and 525 clicks from Google. Ahrefs, which is exactly the kind of third-party scanner Lovable's docs mention, read the same site on 25 July 2026 as zero organic keywords. Both were right about what they could see.

What changed when we moved the site to server rendering?

On 25 July 2026 we replaced the Lovable build with a Next.js app at byte-identical URLs, server-rendered for every visitor, with generated sitemap and robots files, Article and FAQ structured data on each guide, and a build gate that fails if any page ships under a text floor. The rendering difference is not subtle:

The Search Console difference is the part nobody publishes. We compared the last four weeks on the Lovable build with a four-week window that starts five weeks after the cutover, so the re-crawl period is excluded. Same property, same URLs, web search only, pulled on 26 September 2026.

Read it straight. Impressions fell by roughly half, clicks by a third, and two guides lost ten to twenty positions. Click-through rate rose by almost a point and the number of URLs earning impressions went up, because pages that were never in the sitemap on the old build now are. None of that is what the “your SPA is invisible” articles predict. It is also not a clean experiment: the same weeks carried summer seasonality, retitled pages, a retired pricing page and whatever Google shipped in August. We cannot separate those, and we say so rather than credit or blame the stack.

What the move did buy is control, and control is what the rest of this page is about: we can see what the crawler sees, ship structured data everywhere, regenerate the sitemap on every change, and fail a build that goes thin. On a Lovable app since May 2026, most of that is available too. The mistakes below cost more than the rendering ever did.

What actually holds a Lovable app back in search?

1. A sitemap that never changes. Our Lovable build shipped a static sitemap with every lastmod set to the day it was generated. Two months after we published new pages, Google's URL Inspection still reported them as unknown, and the sitemap dates were part of the reason. Regenerate lastmod when a page materially changes and resubmit; Lovable's review checks the sitemap exists, not whether it is honest.
2. One page per app. A landing page has one query it can win. Lovable's prompts default to one route; ours ask for the public pages a channel needs, which is why the landing page prompts carry an SEO variant with its own URL per intent and a sitemap-and-metadata prompt in the same category.
3. No internal links. A crawler reaches a page through links, and a Lovable app built screen by screen usually has a nav and nothing else. This site now fails its build if any indexable URL has fewer than eight contextual inbound links from other pages, because four of our kit pages sat at one to three for two months.
4. Metadata written by the model. Lovable writes a title and description on request; it does not know which query the page should win. Give it the query. Our prompting guide covers the skeleton, including the metadata line.
5. Nothing worth citing. Google's and Lovable's advice converge on the same point: the rendering is table stakes, the content ranks. A page with a definition, a measured number and a named source gets quoted by the AI engines Lovable lists; a page of adjectives does not, on any stack.

What does Lovable's built-in SEO review find?

We asked for one in the chat of the SaaS project built earlier on 26 September 2026 for the prompt examples page, with no code changes allowed. The docs describe the review as “on-demand audits for sitemap, robots.txt, metadata, structured data, semantic HTML, content structure, alt text, canonical tags, indexing, and AI readiness” with “Try to fix” on each finding.

It cost 1.1 credits, read from the workspace credits page before and after (62.4 to 61.3), ran three tool calls, and reported “Passing (5 of 6 checks)”: crawler rules, page basics, site icon, search metadata and social preview. The one failure was “No sitemap”, deferred because the project “isn't published yet and has no public web address”. Then it said the thing this whole page is about, unprompted: “Cadence is a sign-in product with one public landing page, so search visibility will mostly depend on publishing and getting mentioned elsewhere, not on technical tweaks.”

The review is a good first pass and a poor last one. It cannot tell you that the app has one page where it needs twenty, or that no other site links to it, which are the two findings that decided our own numbers above, though its closing sentence points at both. The credits guide covers what a review message costs; the common mistakes page has the rest of the list that the review does not check.

Sources

All checked on 26 September 2026. Search Console and crawler measurements are in src/data/lovableSeoMigration.ts in the site repository; the Lovable build is kept in the repository as legacy/.

• Lovable docs: Optimize your app for SEO and AI search
• Lovable docs: FAQ (rendering and pre-rendering)
• Lovable blog: Building is just the beginning: Introducing Discoverability (13 May 2026)
• Google Search Central: Understand JavaScript SEO basics