A client migrated their site off Lovable to Firebase Hosting. Within weeks, organic traffic dropped to near zero. Google Search Console showed 3 pages indexed out of 21. The site was live, the content was good, and the HTML was clean. None of it mattered because Google could not figure out which version of the site to trust.

This is a walkthrough of what broke, why it broke, and the exact steps we used to fix it. If you have migrated off Lovable (or any visual builder) and your traffic disappeared, this is potentially what happened to you too.

What Does Google Actually See After a Platform Migration?

When you move a site from one host to another, Google does not automatically follow you. It keeps crawling the old URLs, the old sitemap, and the old domain signals until you tell it otherwise.

In this case, the client moved from Lovable to Firebase Hosting. The new site served real static HTML with proper meta tags, JSON-LD schema, and canonical tags. No SPA rendering issues. No blank pages. The technical foundation was solid.

But Google was still looking at the old signals. And those signals were a mess.

The www vs Non-www Split That Killed Indexing

The first thing we found: the sitemap had been submitted under `www.domain.com` in Google Search Console, but every canonical tag on the site pointed to `domain.com` (no www).

Google treats www and non-www as separate sites unless you tell it otherwise. When the sitemap says one thing and the canonical tags say another, Google gets confused about which version is authoritative.

The result: 10 pages flagged as “Alternate page with proper canonical tag” and 5 flagged as “Duplicate without user-selected canonical.”

That is 15 pages Google refused to index because it could not resolve the domain conflict.

The fix was straightforward. We verified a Domain property in Google Search Console (which covers www, non-www, http, and https in one). The client’s DNS was on Cloudflare, so Google offered a one-click verification flow. Took about 30 seconds.

The Ghost Sitemap From Lovable

The second problem: an old Lovable sitemap was still submitted in Search Console. It listed 23 pages from the previous version of the site. Most of those URLs no longer existed on the new Firebase site.

Google had been trying to crawl 23 dead URLs for months. Every request returned a 404. On a young domain with low authority, that is a crawl budget disaster. Google was spending its limited attention on pages that did not exist instead of indexing the real ones.

We removed the old sitemap and submitted a clean one with only the URLs that actually resolve on the current site.

Sitemap URLs That Were Actually Anchor Links

The third issue was subtle. The sitemap listed `/how-it-works` and `/pricing` as standalone pages. On the actual site, those are anchor sections on the homepage (`/#how-it-works` and `/#pricing`). They are not real pages. They do not have their own HTML files.

When Google crawled those URLs, it got the default Firebase 404 page. Two more dead URLs in the sitemap, two more signals telling Google this site has quality problems.

We removed both from the sitemap. A better long-term fix is adding Firebase Hosting rewrites so those paths serve the homepage, but removing them from the sitemap stops the immediate damage.

A Page Google Had Never Seen

While inspecting URLs in Search Console, we found that `/support` had never been crawled.

Google’s status: “URL is unknown to Google.” No referring pages detected. No sitemaps pointing to it. It simply did not exist in Google’s awareness.

The old sitemap did not include it. No other page on the site linked to it prominently enough for Google to discover it through internal crawling. A real page with real content, completely invisible.

We added it to the corrected sitemap and requested indexing manually. The live test confirmed “Page can be indexed.” It should appear in search results within days.

What the Fix Actually Looked Like

Here is the full sequence, in order:

Verified a Domain property in Google Search Console to consolidate all URL variants under one roof.

Removed the stale Lovable sitemap and the www sitemap.

Deployed a corrected sitemap with only real, resolving URLs and no domain mismatch.

Submitted the new sitemap to the Domain property.

Requested indexing on the homepage, blog, support page, and directory page via URL Inspection.

Confirmed that the homepage’s JSON-LD schema, Product snippets, Merchant listings, and FAQ structured data were all being detected correctly.

Total time from diagnosis to fix: about 45 minutes.

Why Lovable Migrations Are Particularly Risky

Lovable builds client-side rendered React SPAs. When a site is on Lovable, Google may or may not render the JavaScript to see the content. That is a known issue. But when you migrate off Lovable, the problems compound.

The old sitemap stays submitted. The old URLs are gone. If you change domain variants (www to non-www or vice versa), Google has to re-evaluate everything. And if you do not explicitly clean up the old signals, Google keeps trying to reconcile two versions of a site that no longer agree with each other.

This is not specific to Lovable. Any platform migration carries the same risks. Lovable just makes it more common because creators are building and shipping fast without thinking about what happens to Google’s understanding of their site when they move.

How Long Does Recovery Take?

For this client, the Domain property showed 12 pages indexed immediately (up from the 3 we initially saw on the URL prefix property). The corrected sitemap was processed same-day. Google discovered 14 pages from it within hours.

Full recovery typically takes one to four weeks for a site this size. Google needs to re-crawl everything, process the new signals, and update its index. The structured data was already clean, which helps. The content was solid. The only problem was the infrastructure signals, and those are now fixed.

Questions We Get After a Migration Goes Wrong

Q: Will my site automatically keep its rankings after migrating off Lovable?

A: No. Google does not automatically transfer rankings to a new host. You need to update your sitemap, verify Search Console properties, fix canonical tags, and request indexing on key pages.

Q: What is a Domain property in Google Search Console?

A: A Domain property covers all URL variants of your site in one place: www, non-www, http, and https. It requires DNS verification but gives you the most complete view of how Google sees your site.

Q: Can a wrong sitemap hurt my site’s indexing?

A: Yes. A sitemap pointing to URLs that return 404 errors wastes crawl budget and signals low quality to Google. This is especially damaging on young domains with limited crawl frequency.

Q: Should I list anchor links as separate URLs in my sitemap?

A: No. If `/pricing` is just `/#pricing` on your homepage and does not resolve as a standalone page, it should not be in your sitemap. Google will crawl it, get a 404, and flag it as an error.

Q: How do I check if my canonical tags match my sitemap?

A: View your page source and look for `<link rel=”canonical” href=”…”>`. Then open your sitemap.xml and compare. The domains must match exactly, including whether they use www or not.

Q: How long does it take for Google to re-index after fixing these issues?

A: For a small site (under 50 pages), most changes are reflected within one to four weeks. Requesting indexing on key pages via URL Inspection speeds this up. Larger sites take longer.

The client’s site went from 3 indexed pages to 12 in a single session, with a clean sitemap submitted and all major pages queued for re-crawling. The structured data was already doing its job. The problem was never the content. It was the infrastructure nobody checked after the migration.

AI Visibility Studio helps websites become easier for AI systems and search engines to find, read, and cite.