Most migration damage is invisible on launch day. The site looks right, everyone celebrates, and the losses surface over the next three weeks as Google recrawls: unmapped URLs, missing schema, vanished internal links, forms that submit into a void. All of it is catchable before DNS moves. This is the checklist I run, failure by failure.
TL;DR
Migration losses come from ten specific, boring failure modes — not from the new platform.
Nine of the ten are verifiable on staging before DNS ever changes.
The most expensive three: unmapped long-tail URLs, canonicals still pointing at the old domain, and schema that quietly disappears with a plugin.
Launch day is the midpoint of a migration, not the end. The last deliverable is 30 days of Search Console monitoring.
If traffic drops anyway, diagnose against year-on-year and branded versus non-branded queries before blaming the migration.
Launch day is the midpoint
A migration has three phases: everything before DNS, the cutover itself, and the month after. Most teams put all their care into phase one, treat the cutover as the finish line, and skip phase three entirely. Google does not work on that schedule. It recrawls a moved site over days and weeks, which is why a migration can look perfect on Monday and lose a third of its organic traffic by the end of the month. The process below assumes a platform move like WordPress to Framer, but it applies to any migration. The failures are ordered roughly by how expensive they are — and each one ends with the check that catches it while it is still free to fix.
The ten failure modes
1. Unmapped URLs
The homepage, the services pages and the top ten posts always get redirects. The 2019 landing page that still earns forty clicks a month from one long-tail phrase does not — because nobody knew it existed. Multiply that across the whole long tail and you lose real traffic without any single loss being big enough to notice.
How to catch it: build the URL inventory from four sources — a full crawl, the XML sitemaps, the CMS database export, and a 16-month Search Console export. Any URL with even one impression goes in the redirect map. A crawl alone finds only what is linked; the database and Search Console find the orphans.
2. Redirect chains
Old sites accumulate redirects: http to https, non-www to www, renamed slugs from past redesigns. Point your new 301 at an old URL that itself redirects, and the request hops two or three times before reaching content. Each hop wastes crawl budget and adds latency, and long chains get abandoned by crawlers. The full pre-launch process for this lives in my 301 redirects checklist.
How to catch it: after building the redirect map, crawl the map itself. Every source URL must resolve to a 200 in exactly one hop. Anything that returns a 301 to another 301 gets flattened to point directly at the final destination.
3. Structured data that disappears
On WordPress, schema mostly comes from a plugin, which means nobody on the team knows it exists. The migration ships, the plugin is gone, and Article, FAQ, Organization and Breadcrumb markup vanish with it. Rich results disappear a few recrawls later, and click-through rate goes with them.
How to catch it: crawl the old site and extract every JSON-LD block by template type before the rebuild starts. Framer has no schema plugin — markup is added as custom code in site or page settings — so each type has to be recreated deliberately. Validate staging pages with Google’s Rich Results test before launch, not after.
4. Headings rebuilt around the visuals
Designers pick heading sizes for how they look; builders then tag whatever is biggest as the H1. The result is a brand name as the H1, section labels tagged by font size, and a document outline that no longer says what the page is about.
How to catch it: export URL, H1 and H2s from the old crawl. Diff them against staging. Every page keeps one H1 that names the topic, and heading levels descend without skipping. Where the old structure was bad, improve it — deliberately, not as a side effect of the design.
5. Internal links that vanish with the navigation
The old sidebar, the fat footer, the related-posts widget — together they carried hundreds of internal links that told Google which pages matter. New designs are cleaner, which usually means fewer links, which means some pages quietly lose most of their internal equity.
How to catch it: from the old crawl, note the internal link count for each money page. On staging, count again. Where a page has lost most of its inbound internal links, restore them structurally: related-item lists driven by category, in-body links from the articles that mention it, breadcrumbs.
6. Forms that submit into a void
The form renders, the button works, the success state shows — and the submission goes nowhere, because the endpoint, the notification address or the spam protection did not survive the rebuild. You find out two weeks later when someone asks why the leads stopped.
How to catch it: submit every form on staging and confirm delivery end to end: the email arrives at the right inbox, the webhook fires, the CRM row appears. Test the failure state too — a form that swallows errors silently is worse than one that shows them.
7. Analytics and tags left behind
GA4, Tag Manager, conversion pixels, consent banners: some are pasted into the old theme, some live in plugins, some in the tag container. Miss one and you launch blind — or worse, you keep firing tags built for URLs that no longer exist and spend a quarter trusting numbers that are wrong.
How to catch it: inventory the old tag container and on-page scripts before the rebuild. Reinstall on staging, then verify with the tag manager’s preview mode that pageviews and key events actually arrive. Annotate the cutover date in analytics so every later comparison has a reference point.
8. Images that lose their alt text
Pages get rebuilt visually — from screenshots, from Figma, from the live site — and every image gets re-placed without its alt attribute. Accessibility drops, image search traffic goes with it, and no automated check on the new site will flag it, because missing alt text is only visible against what used to be there.
How to catch it: export a src-to-alt map from the old crawl and treat alt text as migration content, the same as body copy. Spot-check the top landing pages on staging against the map before launch.
9. Canonicals still pointing at the old domain
Metadata gets copied field by field, and the canonical comes with it — as an absolute URL on the old domain. Every page on the new site then tells Google that the real version of it lives somewhere else. This is the fastest way to make a launch invisible, and it is one paste away.
How to catch it: crawl staging and check the canonical host on every page. Each canonical should be self-referential on the new domain. This check takes minutes, and it has saved more launches than any other line on this list.
10. Nobody watches the month after
Every failure above can slip through in some small way. Caught in week one, each is a quick fix. Unwatched, they compound: 404s accumulate, coverage drops, and by the time someone looks, the decline has a quarter’s momentum behind it.
How to catch it: put the monitoring on the calendar before launch. Daily for the first week: Search Console coverage, the 404 report, and clicks on the top twenty pages against the pre-launch baseline. Weekly for the rest of the month. Every 404 with real impressions gets a redirect the same day it appears.
The checklist in one table
Failure | First symptom | Typical lag | Pre-launch check |
|---|---|---|---|
Unmapped URLs | 404s with impressions | 1–3 weeks | Four-source URL inventory |
Redirect chains | Slow recrawl, lost equity | 2–4 weeks | Crawl the redirect map itself |
Lost schema | Rich results disappear | 2–6 weeks | JSON-LD extract plus Rich Results test |
Broken headings | Key pages slide | 2–6 weeks | H1/H2 diff, old versus staging |
Vanished internal links | Deep pages fade | 3–8 weeks | Link counts per money page |
Dead forms | Leads stop | Immediate, noticed late | End-to-end submission test |
Missing tags | Blind analytics | Immediate | Tag inventory plus preview mode |
Lost alt text | Image traffic fades | 2–8 weeks | Src-to-alt map from old crawl |
Wrong canonicals | Pages deindexed | 1–3 weeks | Canonical host check on staging |
No monitoring | All of the above, later | — | Calendar the first 30 days |
When the migration isn’t the culprit
Sometimes traffic drops in the same window for unrelated reasons: seasonality, an algorithm update, a competitor shipping something better, or content that was already sliding for months. Before blaming the migration, check three things. Compare year-on-year rather than week-on-week, so seasonality cancels out. Segment branded from non-branded queries — a branded drop is rarely a migration problem. And check whether the decline started before the cutover date you annotated in analytics. Migrations take the blame for plenty of drops they did not cause, and the fix for those lives in content, not redirects. If the technical layer checks out and rankings are still soft, that is SEO work, not migration repair.
FAQ
How long after launch can traffic still drop?
Two to four weeks is the usual window, because Google recrawls a moved site progressively rather than all at once. That is why the monitoring period is 30 days rather than a launch-day check. A drop that begins in week three is still usually a launch-week defect surfacing late — check redirects and canonicals first.
Can a migration that already lost traffic be fixed?
Usually, yes. The method is the same inventory in reverse: pull the 16-month Search Console export, find the URLs that lost clicks, and check each one’s redirect, canonical, metadata and content against the old version. The longer the damage has been live, the slower the recovery — speed matters more than perfection here.
Should the old site be kept running?
Keep the old hosting for at least a month, and keep a full export permanently. You cannot diff against a site that no longer exists, and half the checks in this article compare old against new. One extra month of hosting costs nothing against losing the reference copy.
What does the first week of monitoring actually look like?
Ten minutes a day: the Search Console coverage report for new 404s, clicks on the top twenty pages against the pre-launch baseline, and a scan for redirect entries that never fire. Anything anomalous gets investigated the same day — in week one, every fix is cheap.
Planning a move? Send me your URL and you’ll get a crawl summary, a redirect risk list and a fixed quote back within 48 hours — the audit is free and yours to keep either way.
Framerfry
Founder-led Framer studio by Zakir Ullah — Official Framer Expert & Creator. Design, build, migrate, maintain and rank — one person, end to end.
© 2026 Framerfry. Built by an Official Framer Expert.
