Lovable is genuinely impressive for spinning up a full React app from a plain-English prompt. In an hour you can have a product with auth, a database, and a working UI. What you also have, by default, is a site that Google and AI bots largely cannot read. That is not a Lovable bug, it is a React/Vite architecture fact, and it is fixable. This guide explains exactly what the problem is, how to verify it, and what to do about it.
The core problem: Googlebot is reading an empty page
A Lovable project outputs a client-rendered React/Vite single-page application. The initial HTML file that hits the crawler looks roughly like this:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8" />
<title>Vite + React</title>
</head>
<body>
<div id="root"></div>
<script type="module" src="/assets/index-abc123.js"></script>
</body>
</html>The <div id="root"> is empty. All your content, headings, and text only appear after the browser downloads and executes the JavaScript bundle. Googlebot does eventually render JavaScript, but it does so in a second wave, often days later, and with resource constraints that mean complex apps are sometimes rendered partially or not at all. AI crawlers (Perplexity, OpenAI’s bot, Anthropic’s ClaudeBot) generally do not execute JavaScript at all. They read the raw HTML and move on.
The practical result: your app may rank for nothing despite being well-built, and AI tools will not cite it as a source.
The “view raw source” test
Before doing anything else, run this test. Open your Lovable site in a browser, then view the raw HTML source (Ctrl+U on Windows, Cmd+Option+U on Mac, or “View Page Source” in the menu, not DevTools). Do not use the Elements panel in DevTools, which shows the rendered DOM after JavaScript runs.
If the source shows your page headings, body text, and key content, crawlers can read it. If the source shows only the empty <div id="root"> and script tags, crawlers are seeing nothing.
Most Lovable projects will fail this test out of the box.
What you can and cannot control inside Lovable
This is worth being direct about. Lovable gives you a prompt-driven development environment. You can instruct it to add code, modify components, and install packages. What you cannot do inside Lovable’s hosted environment is change the build output from a client-side bundle to a server-rendered or fully static site, at least not without exporting the code and deploying it yourself.
Here is a practical breakdown:
| Fix | Inside Lovable | After export/deploy |
|---|---|---|
| Add react-helmet for per-page titles | Yes | Yes |
| Add a sitemap.xml | Yes (static file) | Yes |
| Add a robots.txt | Yes (static file) | Yes |
| Add JSON-LD structured data | Yes | Yes |
| Add canonical tags | Yes (via react-helmet) | Yes |
| Prerender HTML at build time | Limited | Yes (Vite plugins, Netlify, Vercel) |
| Full SSR (server-side rendering) | No | Yes (migrate to Next.js or Remix) |
The good news is that the highest-impact fixes, meta tags, a sitemap, and schema, are all achievable inside Lovable or with minimal post-export configuration.
Fix 1: Add real per-page titles and meta descriptions
The default Vite template ships with a static <title>Vite + React</title>. Every page of your app shares that title unless you change it. Install react-helmet-async (or use the @tanstack/react-router meta API if your project uses it) to set dynamic per-page titles and descriptions.
npm install react-helmet-asyncWrap your app root:
// main.jsx or App.jsx
import { HelmetProvider } from 'react-helmet-async';
function App() {
return (
<HelmetProvider>
{/* your router and routes */}
</HelmetProvider>
);
}Then on each page component:
import { Helmet } from 'react-helmet-async';
export default function PricingPage() {
return (
<>
<Helmet>
<title>Pricing | Your App Name</title>
<meta
name="description"
content="Simple, transparent pricing. Start free and upgrade as you grow."
/>
<link rel="canonical" href="https://yourapp.com/pricing" />
</Helmet>
{/* page content */}
</>
);
}You can prompt Lovable to do this for you. Something like: “Install react-helmet-async and add a Helmet component to every page with a unique title, meta description, and canonical URL. Wrap the app root in HelmetProvider.”
Note that react-helmet writes these tags into the <head> at runtime. They only exist after JavaScript runs. For crawlers that do not run JavaScript, this approach alone is not sufficient. It is still worth doing because Googlebot will eventually pick it up, and it is the foundation the prerendering step builds on.
For a full treatment of React-specific meta tag patterns, the React SEO guide goes deeper. The broader SPA SEO guide covers the architecture tradeoffs across frameworks.
Fix 2: Prerender your HTML
Prerendering means generating static HTML snapshots of your routes at build time, so crawlers get real content without needing to execute JavaScript. It is not full SSR (the server does not render on each request), but it solves the crawler problem in most cases.
For a Vite/React project there are a few practical paths:
Option A: Deploy to Netlify or Vercel with prerendering. Both platforms offer prerendering as a configuration option. Netlify’s prerendering service fetches each URL with a headless browser at build time and caches the HTML for bots. Vercel has similar functionality via its Edge Network. These are the lowest-friction options if you are deploying a Lovable export.
Option B: Use vite-plugin-prerender or vite-ssg. If you want the prerendering to happen locally at build time rather than relying on a platform feature, these Vite plugins render your routes to static HTML files. vite-ssg works well with Vue (it originated there) but has React community forks. Check current package maintenance before committing.
Option C: Migrate to Next.js. If your app has many routes, complex data requirements, or you want full control over rendering, migrating a Lovable-generated React codebase to Next.js is the most thorough solution. Next.js gives you SSG (static generation), SSR, and incremental static regeneration in one framework. The Next.js SEO guide covers how to configure it properly.
Exporting your code from Lovable (via the GitHub integration) and moving it to one of these deployment paths is the practical route for anyone serious about SEO.
Fix 3: Add a sitemap.xml
A sitemap tells crawlers which URLs exist on your site. Without one, they have to discover pages by following links, and single-page apps often do not have traditional <a href> links that crawlers can follow through JavaScript routing.
For a Vite project, the simplest approach is a static sitemap.xml in the public/ folder. Anything in public/ is served as-is at the root URL.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://yourapp.com/</loc>
<lastmod>2026-05-20</lastmod>
<priority>1.0</priority>
</url>
<url>
<loc>https://yourapp.com/pricing</loc>
<lastmod>2026-05-20</lastmod>
<priority>0.8</priority>
</url>
<url>
<loc>https://yourapp.com/about</loc>
<lastmod>2026-05-20</lastmod>
<priority>0.6</priority>
</url>
</urlset>For apps with dynamic routes (e.g. user profiles, blog posts), you will need a build-time script that queries your data source and generates the full sitemap. Once the file exists, submit it in Google Search Console under Sitemaps.
Add a robots.txt in public/ at the same time:
User-agent: *
Allow: /
Sitemap: https://yourapp.com/sitemap.xmlFix 4: Add structured data (JSON-LD)
Structured data helps search engines and AI tools understand what your content is about. For a SaaS or product app, SoftwareApplication schema is the right starting point. Add it as a JSON-LD block in your root index.html or inject it via react-helmet on the relevant page.
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"name": "Your App Name",
"applicationCategory": "WebApplication",
"operatingSystem": "Web",
"url": "https://yourapp.com",
"description": "One sentence about what the app does.",
"offers": {
"@type": "Offer",
"price": "0",
"priceCurrency": "USD"
}
}For a blog or content section within your app, use Article or BlogPosting schema on each piece. The schema markup guide covers the full range of types and how to validate them.
How this affects AI citations
AI tools like ChatGPT, Perplexity, and Google AI Overviews cite sources that their crawlers can read and understand. A client-rendered SPA with no prerendering, no meaningful meta description, and no structured data is essentially invisible to most of these systems. They will not cite what they cannot read.
The fixes above, especially prerendering and structured data, directly improve how AI crawlers index your app. Structured data gives these systems a machine-readable signal about your content type and topic. A well-formed meta description becomes the text they show when citing your page.
If you publish content (guides, blog posts, feature explanations) from your Lovable app and want them to appear in AI-generated answers, that content needs to exist in raw HTML before the JavaScript executes. There is no shortcut here. The AI SEO guide covers what it takes to get cited consistently.
Other AI builder platforms face the same architecture problem. The Bolt SEO guide walks through nearly identical fixes for another popular vibe-coding tool. The approaches transfer directly.
Publishing content into a Lovable-based repo
One practical workflow: export your Lovable project to GitHub, add a src/content/ folder for blog posts or guides, and use Fokal’s GitHub adapter to commit new articles directly into the repo. Each commit triggers your deployment pipeline, the static HTML is prerendered at build time, and Google can index the content without any manual intervention.
What to do next
The most impactful first step is the raw source test described above. Once you know what crawlers are seeing, the priority order is: add per-page titles and descriptions with react-helmet, add a sitemap.xml and robots.txt, then decide whether prerendering via your deployment platform is sufficient or whether a migration to a framework with native SSG is the right long-term move.
Lovable SEO checklist
- Run the view-source test: check that crawlers see real content, not an empty
<div id="root"> - Install react-helmet-async and add unique
<title>,<meta name="description">, and<link rel="canonical">to every route - Add
public/sitemap.xmllisting all crawlable URLs - Add
public/robots.txtpointing to the sitemap - Enable prerendering on your deployment platform (Netlify, Vercel) or add a Vite prerender plugin
- Add JSON-LD structured data for your app type (SoftwareApplication, Article, etc.)
- Submit your sitemap in Google Search Console
- Re-run the view-source test after prerendering is live to confirm HTML is populated
For the full picture on JavaScript rendering and why crawlers struggle with SPAs, read the platform SEO guide and the SPA SEO deep-dive.