# Lovable SEO: why older Lovable sites were not indexed, and what to check now

It depends on when your project was created. Lovable projects created from 20 April 2026 are server-rendered, so every page reaches Google and AI crawlers as full HTML; older projects are client-rendered React apps that Lovable prerenders on request for verified crawlers, which works but deserves a check. Whichever you have, the titles, sitemap, status codes and links are still yours to get right.

Updated 2026-09-23 · Source: https://porteur.ai/guides/lovable-seo

## Which kind of Lovable project you have

Lovable changed its stack in 2026. New apps use TanStack Start with server-side rendering: every request returns the page already written out in HTML. The change shipped for projects created from 20 April 2026 and was announced on 13 May 2026. Projects created before that date are React and Vite apps, rendered in the visitor's browser.

You do not need to remember when you clicked "new project". Three checks settle it in two minutes.

1. **Open package.json in the code view** A server-rendered project lists a TanStack Start package among its dependencies. An older project lists Vite and React with no server framework, and has an index.html at the root with a single empty div.
2. **View source on a deployed page** In your browser, open view-source:https://yourproduct.com/pricing, not the element inspector. If you can read your pricing text in it, the server sent it. If you see an almost empty body and a script tag, the page is built in the browser.
3. **Fetch the page without JavaScript** Run the commands below from a terminal. curl never runs scripts, so it shows exactly what a crawler that does not render receives.

```bash
# What a crawler that does not run JavaScript receives
curl -s https://yourproduct.com/pricing | grep -i '<title>'
curl -s https://yourproduct.com/pricing | grep -c 'a sentence from your pricing page'

# An empty shell looks like this: no text, one root div, one script
curl -s https://yourproduct.com/pricing | grep -o '<div id="root"></div>'
```

> A curl request that pretends to be Googlebot is not a verified crawler, so on an older project it may still get the empty shell. That does not mean Google does. Use the live test in URL Inspection, described below, to see what Google receives.

## Why older Lovable sites were not indexed

A client-rendered app sends the browser a near empty HTML file and a bundle of JavaScript. The script then fetches data and writes the page. Your browser does this in a second, so the site looks fine to you. A crawler that reads the HTML first sees a shell with no words and no links.

Google does run JavaScript, but in a second pass that can be delayed. Until that pass, the page has nothing to index and no links to follow. Many other crawlers, including most AI crawlers, do not run JavaScript at all. For them an older Lovable page was blank for good.

That is why founders posted "my Lovable website is not on Google". Lovable's answer for these projects is on-request prerendering: on deployed public URLs, verified crawlers (Google, Bing, social preview bots and AI engines) are served a rendered copy of the page. Visitors still get the client-rendered app. The content is the same, only the moment it is assembled differs.

Prerendering happens on Lovable's hosting. If you export the code and host it somewhere else, the new host serves whatever the build produces, which for an older project is the shell again. Check again after any move.

## Checking what Google actually receives

Do not trust your own browser for this: it runs every script. Use Google's own view of the page.

1. **Verify the domain in Search Console** Add the custom domain as a domain property. Without it you cannot see indexing, and you cannot run the tests below.
2. **Run URL Inspection on three pages** Pick the home page, the pricing page and one content page. Click Test live URL, then View tested page. The HTML tab shows the rendered HTML Google got. Search it for a sentence from the middle of the page.
3. **Read the screenshot and the page resources** A blank screenshot or a failed script in the resources list means Google got the shell. Blocked resources in robots.txt cannot be rendered, so never block your script folder.
4. **Request indexing on the pages that matter** Once the live test shows the text, request indexing on your main pages. It asks Google to crawl one URL; do it for the handful that matter, not for every route.

If the live test shows your text on an older project, prerendering is working for Google. If it shows the shell, write to Lovable support with the URL and the tested HTML, or upgrade.

## Upgrade or rely on prerendering

An older project can be upgraded to TanStack Start. Whether it is worth doing now depends on what the site is for.

| Option | What a crawler receives | Effort | Choose it when |
| --- | --- | --- | --- |
| Stay client-rendered with Lovable's prerendering | Rendered HTML for verified crawlers, the shell for anything else | None | The site is small, hosted on Lovable, and URL Inspection shows your text |
| Upgrade to TanStack Start | Full HTML on every request, for every client | A migration, then retesting every route | Search is a real channel for you, or you plan to host elsewhere |
| Move marketing pages to a static site, keep the app | Full HTML for the pages people search for | A second site to maintain | The app sits behind a login and only the public pages need to rank |

Before an upgrade, write down every public URL and its title. After it, check that each URL still answers 200 with the same content, and that no route moved. A migration that changes URLs without redirects costs more than the rendering ever did.

## The checklist that is still yours

Server rendering puts your words in the HTML. It does not write a good title, create a sitemap or return the right status code. Lovable's documentation says sitemaps, robots.txt and metadata are not always generated up front. Its SEO and AI search review can create or repair them, but you still need to check the result.

| Check | How to test it | What good looks like |
| --- | --- | --- |
| One title and description per route | curl each route and grep for <title> and name="description" | Different text on every route, about 60 and 155 characters |
| One canonical per page | grep for rel="canonical" | One tag, pointing at the page's own URL on your custom domain |
| Sitemap | Open /sitemap.xml | Every public route, no admin or app routes, submitted in Search Console |
| robots.txt | Open /robots.txt | No Disallow on your pages or script folder; a Sitemap line |
| Real 404 for unknown routes | curl -s -o /dev/null -w '%{http_code}' on a made-up path | 404, not 200 |
| Links are real links | grep the HTML for <a href | Navigation and cards use <a href="/path">, not a button with an onClick |
| Content is public | Open the page in a private window | The text you want found is readable without signing in |
| One host | Open the builder subdomain | It redirects to your custom domain, or carries a canonical to it |

The 404 row catches most people. A single page app commonly returns status 200 for any path, so /pricng with a typo answers 200 with a "not found" message. Google may treat that as a soft 404, and a site full of them wastes the attention Google gives it.

```bash
# Should print 404. A 200 here means every typo is a page to Google.
curl -s -o /dev/null -w '%{http_code}\n' https://yourproduct.com/this-page-does-not-exist
```

## A prompt to give Lovable

Lovable works from prompts, so ask for the checklist in one message and then test the result with the commands above. Paste this and replace the routes with your own.

```text
Make this site ready for search engines. For every public route
(/, /pricing, /features, /about, /blog and each /blog/:slug):

1. Give the route its own <title> (under 60 characters) and
   <meta name="description"> (under 155 characters), written for the
   page's content. No two routes share either.
2. Add <link rel="canonical"> pointing to the route's own URL on
   https://yourproduct.com (no query string, no trailing slash).
3. Generate /sitemap.xml listing every public route, including every
   published blog post, and nothing behind the login.
4. Create /robots.txt that allows all crawlers and ends with
   Sitemap: https://yourproduct.com/sitemap.xml
5. Unknown routes must return HTTP status 404 with a helpful page,
   not status 200.
6. Every navigation element that goes to another page must be an
   <a href="/path"> link, not a button or a div with onClick.

Do not change any URL that already exists. List what you changed.
```

You do not need an llms.txt file for this. Lovable's documentation says it does not require one, and nothing on the checklist depends on it.

## Content and links are still the work

Rendering decides whether Google can read the page. It does not decide whether Google ranks it. A perfectly crawlable site with ten pages nobody links to still ranks nowhere, and a new site is discovered slowly even with a sitemap.

- Write one page per question your buyer types, with the answer in the first paragraph.
- Link your pages to each other with descriptive anchor text, so each new page is two clicks from the home page.
- Get three real links in the first month: a launch site, a directory in your niche, a community post that links to a useful page rather than the home page.
- Watch Search Console weekly: impressions first, then clicks, then the queries you did not expect.

If the site was built before April 2026 and has been live for months with no impressions, fix rendering first, then look at links. If it is server-rendered and still invisible, rendering is not the problem.

## Questions

### Is Lovable good for SEO?

For projects created from 20 April 2026, yes on the technical side: pages are server-rendered, so crawlers get full HTML. Older projects are client-rendered and rely on Lovable prerendering them for verified crawlers, which works on Lovable's hosting but is worth checking in URL Inspection. In both cases rankings depend on your content and links, not on the builder.

### Why is my Lovable website not on Google?

The most common reason is that the site is new and nothing links to it, so Google has not found or prioritised it. Next come an unverified Search Console property, no sitemap, and on older projects a rendering problem. Verify the domain, submit the sitemap, run URL Inspection on the home page, and read what it says before changing code.

### Does Lovable support SSR?

Yes, for new projects. Apps created from 20 April 2026 use TanStack Start with server-side rendering, and older projects can be upgraded to it. An older project that has not been upgraded is client-rendered.

### Can ChatGPT and other AI assistants read my Lovable site?

Most AI crawlers do not run JavaScript, so they need the text in the HTML. A server-rendered project gives it to them. On an older project, Lovable's prerendering covers the AI engines it verifies; any other client still sees the empty shell.

### Should I rebuild my site outside Lovable for SEO?

Not for rendering alone. Upgrading an older project, or simply confirming that prerendering works, fixes what crawlers see. Rebuild only for reasons that have nothing to do with search, and if you do, keep every URL the same.

## Read next

- [SEO for sites built with AI app builders: Lovable, Bolt, v0 and Replit](https://porteur.ai/guides/seo-for-ai-built-sites): Built your site with Lovable, Bolt, v0 or Replit and Google does not show it? The five usual causes, a 30-minute checklist and the first four weeks.
- [Single page application SEO: rendering, routes and status codes that Google can read](https://porteur.ai/guides/single-page-application-seo): Are single page applications bad for SEO? The six failure points with a test for each, the fixes ranked by effort, and host rules for real 404s.
- [React SEO: making a React app readable by Google and by AI crawlers](https://porteur.ai/guides/react-seo): Is React bad for SEO? How to tell what your React app sends crawlers, set per-route titles in React 19, prerender routes and avoid the React traps.
- [Prerendering](https://porteur.ai/glossary/prerendering): Prerendering means producing a page's HTML before the request. How it differs from SSR and dynamic rendering, how to test it, and where it becomes cloaking.
- [JavaScript rendering: what Google sees, what the AI crawlers do not](https://porteur.ai/guides/javascript-rendering-and-seo): Google renders JavaScript in a second pass and the AI crawlers do not render it at all. Here is what breaks, how to test it, and what to change.
- [How to use the URL Inspection tool in Search Console](https://porteur.ai/guides/url-inspection-tool): Read each panel, run Test live URL, and know when to request indexing. Fix new pages, dropped pages, and canonicals Google ignores.
- [Soft 404: when a page says 200 and Google reads not found](https://porteur.ai/guides/soft-404): Soft 404 means your server says 200 but the page reads like an error or empty. See where it shows in Search Console and fix each case fast.
- [How to use Google Search Console in ten minutes a week](https://porteur.ai/guides/how-to-use-google-search-console): A quick weekly routine: set four filters, compare 28 days, check pages then queries, and fix three findings, without getting lost in noise.

Paste your Lovable site's URL into the free check: in about thirty seconds it reads your site, the searches around it and the rivals on them, and shows three findings whole. Free check: https://porteur.ai/