Lovable SEO: get your Lovable site on Google

Yes, a Lovable site can show up on Google, and since May 2026 the platform does much of the hard part for you. Projects created from May 13, 2026 use TanStack Start and render on the server. Older projects are React + Vite apps that render in the browser, and Lovable serves a prerendered copy to verified search engine and AI crawlers. What it doesn't do for you is the per-page work: unique titles and descriptions, a sitemap, your custom domain as the one canonical host, and links between pages. Fix those first, in that order, then decide whether to migrate an older project to TanStack Start. This guide goes deeper than our general SEO for AI-built websites guide, for Lovable specifically.

#How your Lovable site renders

Which stack you have decides what crawlers get. Lovable's docs describe two cases:

Two consequences. On an older project, a plain curl showing an empty page does not prove Google sees an empty page: Lovable's hosting docs warn that third-party scanners "may report your pages as empty". And prerendering only captures what has loaded when the copy is made, so content that arrives late (a slow API call, a carousel that fetches on scroll) can be missing for crawlers too.

#The five-minute diagnosis

1. Find out which stack you have

   Check the project's creation date, or open the code: TanStack Start projects have a src/routes/ folder and @tanstack/react-start in package.json; older ones have vite.config.ts with react() and an index.html with <div id="root">.

2. Curl the live page

   URL=https://your-domain.com/pricing
   curl -s $URL | grep -o "<title>[^<]*"
   curl -s $URL | grep -o "<h1[^>]*>[^<]*"
   curl -s $URL | grep -o '<link rel="canonical"[^>]*>'

   $ curl -s https://old-app.example.com/pricing | grep -o "<h1[^>]*>[^<]*"
   (no output: the H1 is added by JavaScript)
   $ curl -s https://new-app.example.com/pricing | grep -o "<title>[^<]*"
   <title>Pricing | Acme
   $ curl -s https://new-app.example.com/pricing | grep -o "<h1[^>]*>[^<]*"
   <h1>Simple pricing for small teams
   

   On a TanStack Start project, missing H1 or text in this output is a real problem. On an older project, go to the next step before you worry.

3. See what Google gets

   In Google Search Console, paste the URL into URL Inspection, run Test live URL, then View tested page. That HTML is what Googlebot received. If your copy is there, rendering is fine for Google; work on metadata and discovery.

4. Compare titles and check the files

   for p in / /pricing /about /blog; do curl -s "https://your-domain.com$p" | grep -o "<title>[^<]*"; done
   curl -s https://your-domain.com/robots.txt
   curl -sI https://your-domain.com/sitemap.xml | head -1
   curl -s -o /dev/null -w "%{http_code}\n" https://your-domain.com/no-such-page

   Four identical titles means metadata is generic, which Lovable's docs say is the starting point. A sitemap that isn't a 200 XML file needs to be added. Lovable doesn't document what status unknown routes return, so look at the last line: a 200 is a soft 404 risk. The free SEO checker, robots.txt tester and sitemap validator do the same checks without a terminal.

#Fixes, in order of impact

1. Make your custom domain the only host

Custom domains need a paid Lovable plan. Once connected, set it as primary in the domain settings. Lovable then redirects your other connected domains, including the lovable.app address and www (on by default), to it. Those redirects are 302s: Lovable hosting doesn't support 301 redirects between project domains, so primary domains stay reversible. Google says its indexing pipeline doesn't use a temporary redirect as a signal for which URL is canonical, so other signals have to carry that: an absolute canonical on every page pointing at your custom domain, a sitemap on that domain, and internal links that use it.

curl -sI https://your-app.lovable.app/pricing | grep -iE "^(HTTP|location)"   # want 302 to your domain
curl -sI https://www.your-domain.com/ | grep -iE "^(HTTP|location)"

The redirect checker shows the full chain. Note that branded workspace URLs (app-name.workspace.lovable.app), unpublished projects and projects with restricted access never appear in search, so don't test SEO on those.

2. Give every page its own metadata

Run the built-in review first: in the project's SEO & AI tab, Your SEO & AI search review checks sitemap, robots.txt, titles, canonicals, structured data, alt text and noindex, and offers Try to fix. It is free on all plans. Then prompt for anything it leaves:

For every public page, set a unique <title> (under 60 characters, main topic first),
a meta description of 140-160 characters, an absolute canonical URL on https://your-domain.com,
and og:title, og:description and a 1200x630 og:image. Use the page's real content; don't invent
claims. List the values you set per route so I can review them.

Check the result with the SERP preview for length and the curl loop above for uniqueness.

3. Add a sitemap and point robots.txt at it

Lovable creates a robots.txt with each project but "not always a sitemap". Ask for one that lists only public, indexable pages, and make sure robots.txt names it:

Add a sitemap.xml at https://your-domain.com/sitemap.xml that lists every public page
(no login, admin or thank-you pages), using absolute URLs on my custom domain. Add
"Sitemap: https://your-domain.com/sitemap.xml" to robots.txt. Keep the sitemap in sync
when pages are added.

4. Connect Search Console

Lovable has a Google Search Console connection that shows clicks, impressions and queries and can submit sitemaps. It verifies with the meta-tag method only. Add a property for your custom domain (not the lovable.app URL), submit the sitemap, and come back to the Page indexing report after a week or two. A Bing Webmaster Tools connector exists too.

5. Fix the 404 status and late content

If the not-found curl returned 200, ask Lovable to render a not-found page with <meta name="robots" content="noindex"> for unknown routes (Google's advice for SPAs), or on TanStack Start to return a real 404 status from the not-found route. For content that loads late, ask Lovable to load the main copy with the page instead of after a delay or on scroll.

#Should you migrate to TanStack Start?

If your project is older and it matters that every client, not only verified crawlers, gets real HTML, yes. Lovable has a built-in Migrate to TanStack Start action on all plans: type / in chat and pick it, or use Project settings, General, Project actions, Migrate. Lovable says most upgrades cost 10 to 35 credits, carries over titles, descriptions, social tags and analytics, and leaves the live site alone until you republish. You can revert from version history.

#What you can and can't control

#When to move off Lovable, and how

Most sites never need to. Consider it when you need permanent 301 redirects (for example, a site migration with many renamed URLs), server-level control over status codes and headers, or a stack Lovable doesn't produce. Lovable is still great for building; you can keep using it and host elsewhere.

1. Sync the code to Git

   Git sync works with GitHub, GitLab and Bitbucket on all plans and is two-way, but it creates a new repository (you can't connect an existing one). ZIP download needs a paid plan.

2. Pick a host that fits the stack

   A TanStack Start project needs a host that runs a server. Its build uses Nitro, which detects Vercel, Netlify and Cloudflare Pages; elsewhere use the node-server preset and run node .output/server/index.mjs. An older React + Vite project is a static SPA: it needs an index.html fallback rewrite, and it loses Lovable's prerendering, so prerender it yourself (see React SEO for Vite apps) or migrate it first.

3. Brief your coding agent in the repo

   This repo was exported from Lovable and will be hosted on <host> at https://your-domain.com.
   1. Confirm every public route returns its H1, title, description and an absolute canonical
      on https://your-domain.com in the server HTML (curl a production build).
   2. Make unknown URLs return a 404 status and generate sitemap.xml from the real routes.
   3. Add 301 redirects from any old URLs I list below.
   Done when the curl checks pass on the preview deploy. Old URLs:

4. Switch the domain last

   Point DNS at the new host only after the preview passes, then resubmit the sitemap in Search Console. Server secrets aren't in the repo, so set them on the new host first.

Once the code is in a repo, npx serpkin can set up Claude Code, Codex or Cursor, register the site and run a first scan. It flags pages whose text isn't in the server HTML, bundles small metadata gaps into one "Fix the basics" mission, and npx serpkin check <preview-url> catches regressions on each preview before you switch DNS.