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

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. 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. 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. 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.

# 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 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.

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

1. 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. 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. 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. 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.

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

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.

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.

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.

# 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

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.

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.

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.