From May 1 to May 28, 2026, GA4 recorded zero organic-search sessions for a small service website. Not low. Zero across the measured 28-day period.

The migration that preceded the collapse was not ours. The site had been moved from Lovable to Firebase Hosting, and we were brought in afterward to diagnose why a live, crawlable website with real content and structured data had disappeared from organic search. What we found was a platform migration that was live and a search handover that was unfinished. Completing that handover is what brought visibility back.

This case study documents technical recovery work completed after a separately handled Lovable-to-Firebase migration. The site is anonymised, with the underlying Search Console, GA4 and production records preserved for verification.

Key Takeaways

What Did We Find When the Site Reached Us?

Alive, reasonably built, and invisible. The Firebase version was live and served real static HTML with page titles, canonical tags, JSON-LD structured data, product and FAQ markup, and genuine public content. This was not a blank shell Google could not render.

GA4 told the other half of the story. Organic search sessions ran at 3 during March 1 to 28, 4 during April 1 to 28, and zero during May 1 to 28. A functioning website with working markup had gone completely dark in search.

That combination matters, because the usual advice would have been to add more schema or rewrite the content. The documented failure was not an absence of content or structured data. The evidence pointed to an incomplete migration and conflicting technical signals.

What Was Actually Wrong?

The migration had never been finished, and Google was receiving several different descriptions of the same website. The new Firebase site was live, but the previous Lovable connection had not been completely retired. The site owner confirmed that connection remained, although historical logs do not prove that visitors were actively split between Lovable and Firebase. An old Lovable sitemap was still submitted in Search Console, listing 23 URLs from the previous version of the site, many of which no longer existed and returned 404s.

The domain signals disagreed with each other. The submitted sitemap used the www version of the domain while the canonical tags used non-www, and the initial URL-prefix Search Console property showed 3 indexed pages out of 21, with 10 pages excluded as “Alternate page with proper canonical tag” and 5 as “Duplicate without user-selected canonical.” The sitemap also listed /pricing and /how-it-works as standalone pages when they were actually homepage sections, while a real support page had such weak discovery paths that Search Console described it as “URL is unknown to Google.”

Underneath all of that, the URL system itself was inconsistent. Different parts of the site used .html URLs, extensionless URLs, and both trailing-slash and non-trailing-slash variants, so canonical tags, internal links, sitemap entries, Open Graph URLs, and structured-data identifiers did not agree with each other. Old routes redirected broadly to the homepage or blog index, discarding the subject of the original URL, and some public articles existed as static files without consistent links from the blog index.

What Did the Repair Actually Involve?

Finishing the migration, in layers, over several months. Our first pass was diagnosis and Search Console consolidation: retiring the remaining Lovable connection so Firebase became the sole intended production host, verifying a Domain property covering www, non-www, HTTP and HTTPS, removing the obsolete Lovable sitemap and the conflicting www sitemap, and submitting one corrected sitemap. The Domain property showed 12 indexed pages during the diagnosis. That property covers all protocol and subdomain variants, while the original URL-prefix property covered only one version. The corrected sitemap reported 14 discovered URLs within hours.

The July production repair was the comprehensive pass. One URL format, extensionless and non-www, applied everywhere: canonical tags, sitemap entries, internal links, navigation, Open Graph URLs, and structured-data identifiers. Broad redirects were replaced with relevant one-to-one destinations. Old article routes went to their matching articles. The old support file went to the live support page. Other obsolete routes went to their closest current equivalents, under one rule: every valuable legacy URL should reach the closest relevant replacement, not automatically the homepage. Pages that had been wrongly redirected to the homepage, including the support section, were restored as genuine destinations. Dashboard routes, email templates, and utility pages got an X-Robots-Tag noindex header so private machinery stayed out of the index, and a proper 404 page was added with noindex, follow and links back to useful destinations.

The final layer rebuilt discovery and made it durable. Every indexable article got a static link from the blog index and a place in a complete linked archive, with descriptive anchor text and multiple paths to each article: homepage to blog to article, homepage to directory to article, sitemap to article. The publishing workflow was repaired so a new article automatically updates the article file, the blog index, the directory, the sitemap, and the modification dates together, which is what stops this whole failure pattern from quietly rebuilding itself. Existing structured data was retained and revalidated rather than treated as the fix.

What Happened to the Traffic?

It came back, unevenly, which is worth showing honestly. Organic search went from zero sessions during May 1 to 28 to 30 during June 1 to 28 and 36 during July 1 to 28. Organic traffic began returning as the initial migration cleanup progressed. The later July production repair coincided with the sharpest measured change in Google Search exposure, not with the original return of sessions.

From July 30 to August 26, 2026, GA4 recorded 11 organic sessions, including 9 engaged sessions, an 81.82% engagement rate and average engagement time of 2 minutes 28 seconds. So traffic has returned but not stabilised: below July’s peak, with a larger proportion of the current visits engaged.

The search-exposure change around the July repair was sharper. The week before, July 10 to 16, the site recorded 16 impressions and 2 clicks. The first full week after, July 18 to 24, it recorded 164 impressions and zero clicks. That was 10.25 times as many impressions as the preceding week, although the increase in exposure had not yet translated into clicks. The lift held: August 18 to 24 recorded 165 impressions, still more than ten times the pre-repair week. The July production repair coincided with a tenfold increase in weekly Google Search impressions, and that 925% figure applies specifically to impressions, not to traffic.

The 28-day comparison shows the same shape with the caveat attached. Search Console impressions rose from 244 during June 30 to July 27 to 471 during July 28 to August 24, an increase of 93%, while clicks fell from six to three. The Domain property showed 12 indexed pages during the initial diagnosis and 43 when checked on August 27, 2026, against 3 of 21 on the original, narrower URL-prefix property. Over the three months from May 25 to August 24, checked on August 27, the site totalled 910 impressions, 16 clicks, a 1.8% click-through rate, and an average position of 27.3. In this case, discovery recovered faster than clicks: Google can now find and show the site, and converting that exposure into visits is the next phase, not a finished result.

There is also a list of things we cannot claim, so we will not. No verified evidence exists for revenue, lead, or conversion growth, for AI citation growth, or for a Google penalty ever having existed. The site owner confirmed the old platform connection remained, but no historical logs prove that traffic was actively split between the two hosts. The recovery is real. It is not complete.

What Should Anyone Migrating Platforms Take From This?

That a migration is finished when the old platform is fully retired and every signal agrees, not when the new site loads. This site had schema, content, and titles from day one on Firebase, and it still recorded zero organic sessions across a measured 28-day window, because Google was being handed an obsolete sitemap, competing domain variants, phantom pages and several inconsistent URL formats at once.

The checklist that would have prevented it fits in a sentence each. Retire the old platform connection completely. Submit one sitemap, on the domain variant your canonicals use, containing only pages that exist. Pick one URL format and apply it to canonicals, links, sitemap, Open Graph, and structured data together. Redirect old URLs to their closest equivalents, not the homepage. And wire your publishing system so the sitemap, indexes, and dates update together, because crawl paths that depend on someone remembering will drift.

None of that is glamorous, which is exactly why it gets skipped while everyone argues about content and schema. The site did not need another redesign. It needed the migration to be finished.

Frequently Asked Questions

Q: Why did organic traffic drop to zero after a website migration?

A: In this case, the migration was incomplete rather than the new site being broken. The old Lovable platform connection was not fully retired, an obsolete sitemap with dead URLs was still submitted, the sitemap used www while canonicals used non-www, and URL formats were inconsistent, so Google received conflicting descriptions of the same site, and GA4 recorded zero organic-search sessions from May 1 to May 28, 2026.

Q: How long did it take for traffic to recover after the migration was fixed?

A: Organic sessions went from zero during May 1 to 28, 2026 to 30 during June 1 to 28 and 36 during July 1 to 28 as the initial migration cleanup progressed. The later comprehensive July production repair coincided with weekly search impressions rising from 16 to 164 within a week. Recovery was not instant or linear, and clicks did not follow the impression increase, falling across the latest comparable 28-day periods.

Q: Does fixing technical SEO problems increase traffic immediately?

A: Exposure can move quickly while clicks lag. Here, weekly impressions rose about tenfold immediately after the July repair and impressions nearly doubled across the latest 28-day comparison, while clicks fell from six to three over the same window. In this case, discovery recovered before click-through. That is why impressions and sessions must be reported separately.

Q: Was schema markup the reason the site recovered?

A: No. The site already had JSON-LD, product, offer, and FAQ markup before the recovery work began, and GA4 still recorded zero organic-search sessions from May 1 to May 28, 2026. The repairs that coincided with recovery were the hosting handover, sitemap cleanup, URL standardisation, one-to-one redirects, indexing controls, and internal link architecture. Existing schema was retained and revalidated, supporting understanding once the signals agreed.

Q: What should I check first if traffic collapsed after changing website platforms?

A: Check whether the old platform is fully disconnected, whether Search Console still holds an old sitemap, whether your sitemap domain variant matches your canonical tags, and whether your URL formats are consistent across canonicals, internal links, and structured data. In this case those were the documented failure points associated with the collapse.

Everyone migrating a website worries about the design, the content, and the launch day. The documented problem here was not an empty website or missing schema. It was the unfinished handover after launch, the part nobody assigned to anyone: finishing.

Data note: Organic-session and engagement figures come from GA4 using the fixed date windows stated above. Search impressions, clicks, indexed-page counts and average position come from Google Search Console. The latest figures were checked on August 27, 2026, with Search Console data available through August 24.

AI Visibility Studio helps websites structure content so AI systems can find it, understand it, cite it, and actually use it when generating answers. aivisibilitystudio.com