Lovable SEO: why AI crawlers see a blank page on your site, and the fix
Lovable and Vite apps built with client-side rendering often ship an empty HTML shell with one div and a script tag, because the page is built in the browser. Most AI crawlers, including GPTBot, ClaudeBot and PerplexityBot, do not run JavaScript, so they read nothing. Lovable SEO starts with fixing that: server-side rendering or prerendering, so finished HTML goes out instead.
The steps below are in the order you should do them.
1. Check which stack your app is actually running
Before you change anything, find out what you built on. There are three Lovable stacks in circulation: Vite client-side rendered built before April 2026, Vite client-side rendered built after April 2026, and TanStack Start, which renders on the server.
That matters because most Lovable apps are single-page applications that rely on client-side rendering, and because Lovable's own server-rendering support only went out for sites deployed after April 20, 2026. A project you started last year is on the old path whether or not your editor looks modern.
How to check it worked: open your project files and look for the TanStack Start entry points versus a plain index.html plus main.tsx. If you see an index.html with one root div, you are on Vite.
Common mistake: assuming an app is server-rendered because Lovable shipped SSR at some point. The deploy date of your project is what decides, not the date you last edited it.
2. View source to see what crawlers actually receive
This is the real diagnostic. Load your live page, then view source (not the inspector, which shows the DOM after JavaScript has run). Ctrl+U in most browsers. Or run curl https://yoursite.com in a terminal.
On Vite projects, the HTML that arrives first is close to empty: an empty div with id root and a script tag. That is the whole document. On TanStack projects, actual headings and paragraphs appear in the source HTML.
How to check it worked: search the raw source for your H1 text and the first paragraph of your page. If they are there as plain text, a crawler can read them. If they are not, nothing on that page exists for a bot that does not execute scripts.
Common mistake: using the browser devtools Elements panel and seeing your full page, then concluding you are fine. The Elements panel runs your JavaScript for you. Crawlers often do not.
3. Understand why this breaks AI search visibility specifically
Google is more forgiving here than the AI engines. Google splits crawler work into two passes: the first fetches HTML and indexes what it finds, and a second pass runs JavaScript, but only if the page is queued for it. So a client-rendered page can eventually get indexed.
AI crawlers mostly skip that second pass entirely:
| Crawler | Runs JavaScript? |
|---|---|
| OAI-SearchBot (ChatGPT Search) | No |
| GPTBot (OpenAI training) | No |
| PerplexityBot | No |
| ClaudeBot | No |
| Applebot (Apple Intelligence) | Limited |
| Google-Extended (Gemini) | Yes, via Googlebot |
This is not theoretical. Encited tested more than 50 live Lovable sites and found that ChatGPT, Claude and Gemini returned responses carrying no page content when asked about pages on Vite projects. The model had nothing to summarise, so it said nothing useful.
So javascript seo is now two problems, not one. Ranking in classic search is the old problem. Being readable by a bot that fetches once and leaves is the new one.
How to check it worked: once you have a fix in place, paste a page URL into ChatGPT or Perplexity and ask it to summarise the page. If it describes your actual content instead of guessing from the URL, the fix landed.
Common mistake: treating Google Search Console's rendered screenshot as proof that AI engines can read the page. Those are different crawlers with different budgets.
4. For new Lovable apps: confirm server-side rendering is on
If you started the project recently, this step may already be done. New Lovable apps ship with server-side rendering that renders pages as complete HTML before they reach the browser.
How to check it worked: repeat step 2. View source on a deployed page and look for your H1 and body copy in the raw HTML. That is the only confirmation that counts.
Common mistake: testing on the preview URL inside the editor rather than the deployed domain. Test what the public gets.
5. For existing Vite apps: check the prerendered snapshot reaches AI crawlers, not just Google
Lovable did not leave older projects without anything. Apps built on the previous tech stack get pre-rendered snapshots so crawlers can access content.
The open question is which crawlers. A snapshot that serves to Googlebot and not to GPTBot or ClaudeBot solves half your problem. The documentation does not spell out which user agents are covered, so verify it yourself rather than assuming.
How to check it worked: fetch your page with a changed user agent string and compare the output to a normal fetch. In a terminal:
curl -A "GPTBot" https://yoursite.com
curl -A "Googlebot" https://yoursite.com
curl https://yoursite.com
If the Googlebot response has your headings and the GPTBot response is an empty root div, you have found the gap. Fix it in step 6.
Common mistake: running this once on your homepage and calling it done. Test a blog post and a deep product page too. Snapshot coverage is often uneven across routes.
6. Decide: migrate to server-side rendering, or add a prerendering service
Two real options for an existing Vite or Bolt project. The right one depends on how much of your app you are willing to touch this month.
| Option | What it does | Setup time | Best for |
|---|---|---|---|
| Migrate to a server-rendered stack | Renders pages as complete HTML before they reach the browser, as new Lovable apps do | Not stated | Apps you plan to keep for years, content-heavy sites, anything where the marketing pages matter more than the app shell |
| Prerender.io | Crawlers receive pre-rendered pages instead of waiting for JavaScript to load | 30 to 45 minutes | Existing projects you do not want to rebuild, sites deployed before the SSR rollout |
A migration rewrites routing and data loading, which takes real time on an AI-built app as the agent works through the changes. The prerendering route leaves your code alone and puts a layer in front of it.
Reading this because you need customers?
Paste your URL. See what ChatGPT, Perplexity and Google AI answer when your buyers ask, who they name instead of you, and which pages they read. Then we do the work to get you onto those pages.
Free scan, no signup, no card.
How to check it worked: whichever path you take, run the curl commands from step 5 again against three different routes. Raw HTML with real content, or it did not work.
Common mistake: picking the migration because it sounds cleaner, then stalling halfway with half the routes converted. If you are not going to finish it in one sitting, take the prerendering route first and migrate later. A half-migrated app is worse than a prerendered one.
7. Check that data fetched after load is not invisible
Server-side rendering does not automatically cover your data. On TanStack projects, data from Lovable Cloud, Supabase or a remote API is fetched in the browser after the initial HTML, so it is not in what a crawler reads.
This is the one that catches people who think they are done. Your layout, nav and static copy render on the server. Your blog posts, your pricing tiers and your directory listings load from the database a moment later, in the browser, where the crawler is not watching.
How to check it worked: view source on a page whose main content comes from your database. A blog post is the clearest test. If you see the shell but no post body, your data is client-side.
Common mistake: fixing the homepage, which is usually hardcoded, and never testing a database-driven route. Those are your long-tail pages and they are the ones AI engines are most likely to surface.
8. Verify the built-in SEO features behave on your stack
Meta tags, structured data and sitemaps all sit downstream of rendering. On a server-rendered stack, titles and descriptions are in the HTML that goes out. On a client-rendered Vite app, anything written into the head by JavaScript after load is subject to the same problem as your body copy, unless it is covered by the pre-rendered snapshot.
How to check it worked: curl a few pages and grep for <title> and og: tags. Each page should have its own, not the same default title repeated across the site.
Common mistake: setting per-page meta tags through a React head component and assuming every crawler picks them up. Confirm in raw source, page by page, for at least a sample.
9. Run an SEO and AI search review as a checkpoint
Once the plumbing is right, get a second opinion. Lovable's SEO and AI search review is free on all tiers, which makes it a reasonable checkpoint rather than a purchase decision. Chatting with Semrush data comes at no extra cost through September 15, 2026.
How to check it worked: run the review before and after your rendering change and compare what it flags. The issues that disappear are the ones your fix actually addressed.
Common mistake: running the review first and treating its checklist as the work. A perfect meta description on a page no crawler can read is worth nothing. Rendering first, review second.
10. Go beyond crawlability: get cited once engines can read you
Being readable is the floor, not the goal. An AI engine reading your page does not mean it will name you when a buyer asks which tool to use.
There is real run-to-run variance in which brands get named. In welaunch's test of live AI answers on 27 Sep 2026, only 9 of 32 brand appearances (28%) in ChatGPT answers were named in all four runs of the same prompt, and 6 of 21 (29%) in Perplexity. The brand sets ChatGPT returned for the same prompt across four runs overlapped by a mean Jaccard similarity of 0.54, and Perplexity by 0.57, in the same test. Ask the same question twice and you often get a different shortlist.
Which means the work after crawlability is about the sources those answers pull from: comparison posts, directory listings, forum threads, review pages. Those get cited whether or not your own site does.
That second half is what welaunch handles. It asks your buyers' questions on ChatGPT, Perplexity, Gemini and Google AI several times a week, keeps every answer in full so you can read what each engine said, finds the pages the engines cite, and drafts the reply, listing or page that gets you onto one. You review each draft and press submit, from your own accounts. It never posts under an account of its own, and on Reddit and Quora it names the product only, with disclosure, rather than stuffing links.
How to check it worked: ask your top buyer question on each engine, four times, a week apart, and record whether you are named. One run is noise.
Common mistake: fixing rendering, seeing no change in AI answers after three days, and concluding the fix failed. Crawl and re-index cycles are slower than that, and naming depends on sources beyond your own domain.
FAQ
Does Lovable support SEO out of the box?
Partly, and it depends on your stack. New Lovable apps ship with server-side rendering that produces complete HTML before the browser gets involved, and older apps on the previous tech stack get pre-rendered snapshots. Lovable also includes a free SEO and AI search review on all tiers. Check your own raw HTML before trusting any of it.
Is there an AI tool that can do SEO for me?
No tool does the whole job unattended, but parts of it are automatable. Lovable's own review tool runs checks on your pages for free, and chatting with Semrush data is included at no extra cost through September 15, 2026. For AI search specifically, welaunch runs your buyer questions across the engines on a schedule and drafts the work to get you onto the pages those engines cite, with you approving each submission.
Is Lovable good for building websites that rank?
It can be, once rendering is sorted. The default problem is that most Lovable apps are single-page applications relying on client-side rendering, and client-rendered pages ship an empty shell. Server-rendered builds put real headings and paragraphs in the source, which is what both Google and AI crawlers need.
What is the 80/20 rule in SEO?
For a React or Vite app, the 80/20 is rendering. If crawlers cannot read your pages, keyword work, internal linking and schema markup produce nothing. Confirm raw HTML contains your content, then spend time on everything else. This is the single biggest difference between react seo on a client-rendered app and on a server-rendered one.
Can I migrate an existing Lovable project to server-side rendering?
Yes, though Lovable's built-in SSR was rolled out only for websites deployed after April 20, 2026, so an older project needs either a stack migration or a prerendering layer. Prerender.io integration with Lovable sites usually takes 30 to 45 minutes and leaves your code untouched. Migrating is more work but removes the dependency.
Which Lovable stack am I actually on?
There are three: Vite client-side rendered built before April 2026, Vite client-side rendered built after April 2026, and TanStack Start with server rendering. The fastest test is view source on a live page. An empty div with id root and a script tag means Vite; visible headings and paragraphs mean TanStack. The same test works for bolt seo and vite seo audits on any other builder.
Sources
- Is Lovable SEO Friendly in 2026? Vite vs TanStack Explained | Encited Blog
- How To Make Lovable Website SEO-Friendly (A Tested Guide)
- SEO and AI search for apps built with AI | Lovable
- welaunch test of live AI answers, 27 Sep 2026
- welaunch's test of 434 live AI answers to buyer questions in seven software categories, 27 Sep 2026, US
Related on welaunch
Do buyers find you, or your competitor?
Paste your URL. See what ChatGPT, Perplexity and Google AI answer when your buyers ask, who they name instead of you, and which pages they read. Then we do the work to get you onto those pages.
Free scan, no signup, no card.
Part of Technical AEO, in the guides on getting your SaaS named in AI answers.