A Lovable site can be live in your browser and still be effectively invisible to Google.
Before changing the design, buying backlinks or rebuilding the project, identify which problem you actually have:
- the production site is not live at the URL you think it is;
- Google has not discovered the page yet;
- Google discovered it but has not indexed it;
- the page is indexed, but it does not rank for the search you tried.
Those are different problems. Treating all four as “SEO is broken” wastes time.
This is the order I would use to diagnose a Lovable site before touching the architecture.
1. Decide which domain is the real website
A product can accumulate several addresses while it is being built:
- a Lovable project URL;
- a custom root domain;
- a
wwwversion; - a staging or preview URL;
- perhaps another deployment created from GitHub.
Google needs a consistent answer about which version should represent the site.
Lovable’s current custom-domain documentation lets you connect a domain you own and designate one connected domain as the primary domain. It also recommends using a custom domain for brand identity and search visibility.
For a real business or SaaS, I prefer this ownership model:
registrar account you control → DNS you control → production domain → application
The builder can change later. The public address should not have to.
After connecting the domain, test the exact production URL in a private browser window. Check both the root and www versions if you use them, and confirm you are not accidentally sharing a preview URL as the main site.
2. Check whether the page is actually indexable
A public page needs to return usable content without telling search engines to stay away.
Check the production page for:
- a successful HTTP response;
- no accidental
noindexdirective; - a canonical URL pointing to the intended production URL;
- crawlable internal links;
- a page title and useful visible text;
- no login wall around a page you expect Google to index.
Lovable’s current SEO and AI-search review checks areas including metadata, semantic HTML, sitemap, robots.txt, canonical tags, accessibility, mobile usability and indexing readiness.
Use that as a first pass, not as proof that Google has indexed the page.
A tool can tell you that a page can be crawled. Only Google can tell you what Google actually did with it.
3. Verify the production domain in Google Search Console
This is the point where guessing should stop.
Google Search Console lets you inspect a URL and see whether Google knows about it, whether it was crawled, and whether it is indexed.
Lovable now documents a Search Console connection inside its SEO workflow. After the custom domain is live, you can verify the site and submit the sitemap from the project. See Lovable’s SEO/AEO documentation.
You can also work directly in Search Console.
Start with the homepage and two or three important public pages. Do not inspect fifty URLs before you understand what is happening to the first three.
The useful question is not:
“Why can’t I see my site when I Google the name?”
It is:
“What indexing state does Google report for this exact canonical URL?”
That distinction turns an SEO feeling into a diagnosable system state.
4. Submit the sitemap from the final host
Your sitemap should list the URLs you actually want Google to discover.
If the production site is:
https://example.com
then the sitemap should not be full of old preview URLs from another host.
Open the sitemap yourself and check a few entries. Confirm that:
- the URLs use the final domain;
- important public pages are present;
- draft/private pages are not being advertised as indexable content;
- the sitemap itself loads successfully.
Then submit that sitemap in Search Console.
Google’s sitemap guidance is worth keeping in perspective: a sitemap helps Google discover URLs, but it does not guarantee that every submitted page will be indexed.
That is why repeatedly resubmitting a sitemap is not a substitute for diagnosing the page.
5. Check the canonical, especially after changing domains
This is one of the easiest launch mistakes to miss.
You build on one URL, connect a custom domain later, and the visible site looks correct. But metadata or sitemap references still point somewhere else.
For each important page, the canonical should normally point to the production version of that page.
For example:
https://example.com/pricing
should not declare a preview-domain /pricing page as canonical.
Google explains in its canonicalization guidance that redirects and rel="canonical" are strong canonical signals, while sitemap inclusion is weaker. Consistency across those signals makes the preferred URL easier to understand.
If you changed domains during launch, inspect both the old and new versions in Search Console where possible. Do not assume Google has consolidated them because your browser lands on the right page.
6. If Google says “discovered” or “crawled” but not indexed, inspect the page itself
At this point, the problem is no longer simply “submit it to Google.”
Ask whether the page deserves to exist as a separate search result.
A thin page with a hero, three generic feature cards and almost no specific information gives Google little reason to choose it over stronger pages already available.
For a product website, make the page answer the buyer’s real questions:
- What does the product do?
- Who is it for?
- What problem does it solve?
- How does pricing work?
- What happens after signup?
- What integrations or constraints matter?
- What proof can the visitor evaluate?
For a local business, the questions may instead be services, locations, pricing context, availability, proof, process and how to enquire.
This is where product thinking and SEO meet. Indexability gets the page into consideration; useful information gives the page a reason to remain there.
7. If the page is indexed but not ranking, stop debugging indexing
This sounds obvious, but it saves a lot of wasted work.
If Search Console says the page is indexed, and Google can retrieve it correctly, you have moved into a ranking problem.
That can involve:
- weak or generic content;
- unclear search intent;
- a new domain with little authority;
- poor internal linking;
- stronger competing pages;
- a title that does not match the query well;
- insufficient evidence or specificity.
Changing DNS or resubmitting the sitemap will not solve those problems.
Instead, identify the query and improve the page for the person making that search.
If the page receives impressions in Search Console but few clicks, inspect its title, snippet and ranking position before rewriting everything. If it receives no impressions at all after indexing has settled, reassess whether the page targets a real search demand.
8. Do not rebuild the app just because SEO is not instant
AI builders make rebuilding feel cheap because generating another version is fast.
But a rebuild can introduce new problems:
- changed URLs;
- broken forms;
- lost analytics;
- new authentication redirect issues;
- duplicated domains;
- payment regressions;
- lost content;
- another indexing reset.
If the current Lovable project works, fix the smallest broken layer first.
A practical sequence is:
domain → crawlability → canonical → sitemap → Search Console indexing → page usefulness → authority and CTR
Only move into a deeper rebuild when the architecture itself is preventing the product from meeting its requirements.
That same principle applies beyond SEO. My AI-built app production checklist covers the security, payments, permissions and operational checks that matter before real users depend on the app. If the bigger concern is whether another developer can safely take over the project, use the Lovable developer handoff checklist.
And if your Lovable project has become a real MVP but you need help turning the generated build into something you can confidently launch and maintain, see my MVP development service or contact me.
