Site migration SEO comes down to one rule: every URL that was ever indexed either keeps serving a page or redirects in one hop to the page it meant. Everything else, from the redirect map to the DNS change, exists to keep that rule true. We've done it twice now, moving our consultancy's site off Webflow in August 2026 and moving fabric.pro out of its product app this autumn, and the sitemap was never the whole list.
Two moves, two shapes
Our consultancy's site moved from Webflow to Next.js on a Cloudflare Worker. It was rebuilt, cut over and checked on a single day, 10 August 2026, and we spent the following six weeks finding the URLs we'd missed.
fabric.pro had a different problem. Its marketing pages lived inside the product, one Next.js app serving the blog, the docs and the app itself under /en. The marketing site is moving into its own repository so it can change daily without a product release, and the app is moving to app.fabric.pro. Its old site had 80 indexed URLs, and 67 of them were docs.
Start with every URL, and know the sitemap is a floor
The first inventory comes from the live sitemap. On one of our own sites, diffing the old Webflow sitemap against the new build found 22 URLs that would have returned 404 at cutover. There were nine expertise pages, three legal pages, three case-study paths in the singular, a category whose live slug carried a typo, /search, /sitemap, and a case study that had been scraped but never added to the index.
Then the sitemap ran out. Five paths from before Webflow, such as /our-work and /services/staff-augmentation, returned 404 for weeks after the move because the Webflow sitemap never listed them. A full crawl and Search Console found them on 19 September. On 10 September, Search Console's "Not found (404)" report turned up seventeen URLs that other sites linked to and we'd never redirected.
So the inventory gets built three times: before you build, again before cutover, and once more after Search Console has four weeks of the new site. Export the pages your backlink tool knows about and add them too. A URL another site links to is worth more than one only the sitemap knows.
One redirect map, read by the server and the check
Each line in the inventory needs a page or a redirect to its closest equivalent. A redirect to the home page is a soft 404 to Google, so it doesn't count.
We keep the map in one file that the server and the build's URL check both read, so they can't drift apart. On fabric.pro that file lists the app's prefixes, and the Worker answers every one of them with a 308 to the app host. A 308 keeps the method and body, so a POST to an old /api path still works after the move, where a 301 wouldn't. Moved pages get a 301.
Redirects can do damage too. In September we redirected an empty author page to /blog. When the author published again in October, the sitemap listed the page and the redirect hid it. The URL check now fails any redirect that shadows a page the build makes.
Prefix redirects need the most care. On fabric.pro, the rule sending /blog to the app was exactly the one that would have hidden the new marketing blog, so we removed it in the same change that added the blog.
Collapse chains while you're there. The old blog subdomain took three hops to reach a post, and the first one lived in the Cloudflare dashboard, out of reach of the repository.
Decide where the docs live, in writing
When a marketing site leaves a product app, the docs are the hard call. They're most of the indexed URLs and they change with the product. We kept fabric.pro's docs with the app, where they stay current, and every old /en/docs URL redirects to the same page on app.fabric.pro/docs. The blog posts and the legal pages moved to the marketing site at the same slugs, and for those the /en prefix is stripped with a single 301.
Keep the entity the same
An overhaul is when a second company description, a second Organization node and a new logo URL creep in. Answer engines identify a company by matching it across sources, so we kept one Organization @id in the structured data and made every surface quote one canonical description. fabric.pro's pages point at the company's existing Organization node and never mint a new one.
Check the new site by mechanism, then crawl all of it
Before cutover we went through the old site by what each page does, and confirmed the new one does it at least as well. That covered titles, canonicals, share cards, structured data, the sitemap, the contact form end to end, analytics, RSS and a 404 page that returns a 404 status.
Then crawl the preview with no page limit. Our first crawler stopped at 100 pages, described a third of a 294-page site, and missed the problems that mattered.
The cutover, in an order you can undo
Deploy to a preview host first, with every response marked noindex and crawlers still allowed to fetch it. A robots.txt Disallow would stop Google reading the noindex at all, and a blocked URL found through a link can still be listed. Our Worker's default address served the whole site with nothing stopping a crawler until we fixed it on 8 October.
The domain moves last. When the move came on 10 August, we captured the full DNS zone and then changed only the apex A record and the www CNAME that pointed at Webflow. Mail and verification records stayed untouched.
Then purge the cache. After our cutover, Cloudflare kept serving 19-day-old Webflow responses, so some paths returned 404 and the home page kept its old title until the zone was purged. A social preview also failed because its image URL still served the old site's HTML. Check that share images come back as images.
After the move, read the reports before reacting
For the first month, the Search Console 404 report feeds the redirect map every week. Read the "crawled, currently not indexed" list by kind before worrying. Of 132 rows on one of our own sites, 26 were image and font endpoints, about 12 were legacy paths that already redirected, and 8 were on other subdomains. None was a real page problem.
Don't save a position reading for four weeks. A reading taken before the new pages are fetched again says nothing changed, and it becomes the false baseline for everything after. Ping IndexNow with every URL that changed so Bing doesn't wait for a crawl.
The inventory command, the redirect check and this cutover order are written into Heddle as the first step of every engagement, because there's no point building new pages on a site whose old URLs are about to break.
Questions
How do I avoid losing rankings in a site migration?
Keep every indexed URL alive. Build an inventory from the sitemap, a full crawl, Search Console and your backlinks, then give each URL a page or a one-hop redirect to its closest equivalent, and fail the build if any line has neither.
Should old URLs redirect to the home page?
No. Google treats a redirect to an unrelated page, including the home page, as a soft 404. Redirect each URL to the page that replaced it, or to the closest equivalent.
Should docs move with the marketing site or stay with the product?
It depends on what changes them. Docs that change with every release stay current when they live with the product. Either way, every old docs URL needs one redirect, and the decision should be written down.
When can I measure the SEO impact of a migration?
Not before three to four weeks. Pages have to be fetched again before positions mean anything. Read Search Console's 404 and coverage reports weekly in the meantime, and save no position baseline until the new pages have been crawled.