Lovable Site Not Showing on Google? Why, and How to Fix It
If your Lovable, Bolt or v0 site is not showing on Google, the most common reason is that Google is not getting proper HTML for each page. Many AI-built sites are single-page apps that build their content in the browser with JavaScript, share one title across every page, and have no sitemap. The fix is to serve real HTML per page, give each page its own title and description, and help Google find every URL.
I have been building websites for over 15 years, and this is one of the most fixable SEO problems there is. In most cases you do not need to start again.
Why do AI-built single-page apps often not get indexed?
Lovable, Bolt and v0 are great for getting a working site quickly, but their default set-up does not always match what search engines need.
1. Client-side rendering. A classic React and Vite app sends the browser an almost empty HTML file, and JavaScript then builds the page. Google’s JavaScript SEO documentation explains that Googlebot crawls a page, puts it in a queue for rendering, and only indexes what it sees after rendering. Pages can wait in that queue, and the same documentation says server-side or pre-rendering is “still a great idea” because not all bots can run JavaScript.
2. Missing or duplicate titles and meta descriptions. Many generated apps have one <title> and one description in index.html, so every route looks the same to a search engine. Google’s guidance asks for unique, descriptive titles and descriptions for each page.
3. No sitemap. A brand-new site with few links from other websites is exactly the case where Google’s sitemap documentation says a sitemap helps, because Googlebot might not otherwise discover your pages.
4. robots.txt or noindex problems. A leftover noindex tag, or a robots.txt rule that blocks the JavaScript and CSS files, can stop pages being indexed or rendered properly. Google’s robots.txt guide warns that blocking those resource files can make pages harder for Google to understand.
5. Links that are not real links. Google’s JavaScript documentation says it can only discover links that are <a> elements with an href. Buttons with click handlers, or routes using # fragments, will not help Google find your other pages.
6. Slow, heavy JavaScript. Large bundles delay when content appears for users and for crawlers, and they hurt Core Web Vitals.
Has Lovable fixed this?
Partly, and it is worth knowing which kind of project you have. According to Lovable’s own SEO documentation:
- New Lovable apps created from 13 May 2026 use TanStack Start with server-side rendering.
- Older React and Vite apps get on-request pre-rendering on deployed public URLs, but only for verified crawlers such as Google, Bing, social preview bots and some AI engines.
- Sitemaps and robots.txt “are not always generated up front”, and Lovable offers an SEO review that flags missing items.
The documentation covers Lovable’s own hosting. If you exported the code to GitHub and host it somewhere else, do not assume the same pre-rendering comes with it. Check what your host is actually serving.
With Bolt, many projects are React and Vite single-page apps, so the client-side rendering issue applies. v0 usually generates Next.js, which can render on the server, but pages built entirely as client components, or missing metadata, can still cause the same problems.
How do I check if Google can see my site?
Start with these checks, in this order.
| Check | How | What it tells you |
|---|---|---|
| URL Inspection | Google Search Console, paste a page URL | Whether that page is indexed, and if not, why |
| Live test | “Test live URL” in URL Inspection | Whether Google can fetch and render the page now |
| Rendered page | “View tested page”, then the HTML and screenshot | Whether your content actually appears after rendering |
| site: search | Search site:yourdomain.com |
A rough idea of indexed pages (not a complete list) |
| View source | Right-click, View Page Source in your browser | Whether the raw HTML contains your text or an empty shell |
| robots.txt | Visit yourdomain.com/robots.txt |
Whether anything important is blocked |
Google’s own help pages say the URL Inspection tool shows information about Google’s indexed version of a page and lets you test whether a URL might be indexable. You can also request indexing from there once the page is fixed.
Do not rely on the site: search alone. Google’s documentation says the site: operator does not necessarily return all the URLs that are indexed.
How do I fix a Lovable, Bolt or v0 site that is not on Google?
Serve real HTML for every page
This is the fix that matters most. You have three main options:
- Server-side rendering (SSR). The server builds the full HTML for each request. Next.js, TanStack Start and similar frameworks do this. It suits sites with lots of pages or content that changes often.
- Pre-rendering or static export. Each route is turned into a static HTML file at build time. This is often the simplest fix for a marketing site or landing pages that do not change every hour.
- Hosting-level pre-rendering. Some hosts, including Lovable for older projects, render pages on the fly for crawlers. It helps, but your users still get the JavaScript-built version.
After the change, view the page source again. You should see your headings and text in the raw HTML.
Give every page a unique title and meta description
Each route needs its own <title> and <meta name="description">, written for what that page is about. Add a canonical URL and Open Graph tags while you are there, so shared links look right too.
Add a sitemap and check robots.txt
Generate an XML sitemap listing every public page, reference it in robots.txt, and submit it in Search Console. Google is clear that a sitemap helps discovery but does not guarantee indexing, so it works alongside the other fixes, not instead of them. Make sure robots.txt is not blocking your JavaScript, CSS or important pages, and remove any stray noindex tags.
Use proper internal links
Link your pages to each other with normal <a href="/page"> links: in the navigation, the footer and inside the content. Use clean paths like /pricing rather than /#pricing for separate pages. For routes that do not exist, return a real 404 or add a noindex tag, which is what Google’s JavaScript guide recommends to avoid soft 404 errors in single-page apps.
Improve Core Web Vitals
Google’s Core Web Vitals guidance sets these targets for a good experience:
| Metric | Measures | Good target |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading | Within 2.5 seconds |
| Interaction to Next Paint (INP) | Responsiveness | Under 200 milliseconds |
| Cumulative Layout Shift (CLS) | Visual stability | Under 0.1 |
On AI-built sites the usual culprits are large JavaScript bundles, unoptimised images, web fonts loaded late, and animation libraries used on every page. Serving real HTML from the server can also help LCP, because the main content no longer waits for JavaScript to build it.
Ask Google to look again
Once the fixes are live, inspect your key pages in Search Console, run a live test and request indexing. Then give it time: Google does not promise to index every page.
Should I rebuild the site instead?
Not always. For a small site, adding pre-rendering or moving to a framework with SSR is often enough. If it needs to grow into a content-heavy site or an online shop, moving to WordPress or Shopify, where proper HTML and sitemaps are standard, can make more sense.
Need help?
If your AI-built site is still not showing on Google, book a 15-minute call. I will look at how it is built, tell you honestly what needs fixing, and send a fixed written quote within two business days. You keep ownership of all the code and accounts, and you get one month of free support after the fixes go live.