Most traffic lost during a migration was never lost to the migration itself — it was lost to a redirect that pointed to the wrong place, a staging noindex that shipped to production, or an internal link graph that still pointed at dead URLs. A website migration checklist that only says “add 301s and submit a sitemap” is how sites end up with a 40–70% traffic drop that takes two quarters to claw back. The real work is preserving every signal Google has already attributed to your URLs, and proving to the crawler that the new address is the same entity — not a brand-new site it has to re-evaluate from scratch.
What Counts as a Migration (and Why the Risk Differs)
“Migration” is a loose word that covers at least six distinct changes, each with a different failure mode. Knowing which one you’re doing tells you where the risk actually sits:
- Domain change — same content, new hostname. Lowest content risk, but every URL changes, so the redirect map is everything.
- HTTP to HTTPS — the mildest migration; still a URL change Google treats as a move.
- URL structure change — new folder logic, cleaner slugs. Content stays but the address space is rewritten.
- Replatform SEO — moving CMS (e.g. WordPress to a headless stack, or onto Shopify). The dangerous one: URL patterns, rendering, and templates all change at once.
- Site redesign — same URLs, new templates and copy. Redirects may be a non-issue while on-page signals and internal linking shift dramatically.
- Consolidation — merging two sites or pruning a bloated one into fewer URLs. Many-to-one redirects and lost pages.
The reason this matters for your website migration checklist is that a redesign needs a content-parity audit far more than a redirect map, while a domain change is the opposite. Scope the work to the change you’re actually making instead of running a generic list.
Baseline Everything Before You Touch Anything
You cannot diagnose a post-launch drop if you never recorded the “before.” Capture a full baseline while the old site is still live: a complete crawl of every indexable URL, current organic traffic and rankings by page, top landing pages and their queries from Search Console, backlink targets (which external URLs point where), and your current Core Web Vitals field data from CrUX. Export the full list of indexed URLs from the site: report and the GSC Pages report — those are the addresses that carry equity and every one needs a destination. This baseline is the single most-skipped step, and it’s the one that turns “we lost 30% of traffic somewhere” into “these 84 URLs 404 and here’s the fix.”
The Redirect Map Is the Whole Game
If one section of this website migration checklist deserves 60% of your effort, it’s the redirect map. The rules that actually matter:
- 301, not 302. A 301 (permanent) passes signals and consolidates the old URL into the new one. A 302 (temporary) tells Google to keep indexing the old address — the wrong instruction for a move.
- One-to-one, to the closest equivalent. Map each old URL to the single best matching new URL. Do not lazily redirect everything to the homepage — Google treats a redirect to an irrelevant page as a soft 404 and drops the equity entirely.
- No redirect chains. Old-A → New-B, never Old-A → Old-B → New-B. Chains bleed a little equity at each hop and slow the crawler. If you have historical redirects, flatten them so the old rules point straight to the final destination.
- Preserve query and anchor behavior where pages depend on it, and keep redirects live indefinitely — at minimum a year, ideally forever, since Google needs to re-crawl every old URL before it fully transfers signals, and that can take months for deep pages.
A correct Apache rule looks like Redirect 301 /old-page/ https://newsite.com/new-page/; on nginx it’s return 301 https://newsite.com/new-page/; inside the matching location block. For thousands of URLs, drive it from a mapping file rather than hand-writing rules.
Staging: Block It, Then Actually Unblock It
The most common self-inflicted disaster in a migration is a staging directive that survives launch. During development you keep the staging site out of the index — ideally behind HTTP authentication, or with a site-wide noindex meta tag. The failure is launching with that block still in place. Understand the two mechanisms precisely, because they interact badly:
noindex(a meta robots tag orX-Robots-Tagheader) tells Google not to index a page it has crawled.Disallowinrobots.txttells Google not to crawl the URL at all.
Here’s the trap: if you both Disallow a URL in robots.txt and put noindex on the page, Google can’t crawl the page, so it never sees the noindex — the URL can linger in the index as an untitled result. On launch day, robots.txt should allow crawling and every production template must ship without the staging noindex. Verify this on the live site with a real fetch before you announce anything.
Preserve On-Page Signals and Metadata
Redirects move equity between URLs; they don’t preserve the content signals Google ranked in the first place. On a replatform or redesign, audit parity for every important page: title tags, meta descriptions, H1s, body copy, image alt text, and canonical tags. A new CMS loves to “clean up” your titles or truncate content, and a template that emits a self-referencing canonical pointing at the wrong protocol or a trailing-slash variant will quietly split your signals. If page copy is genuinely changing, expect some ranking movement independent of the migration — that’s a content change, not a technical one, and it’s worth separating in your reporting so you don’t blame the redirects for a rewrite.
Rebuild Internal Links to Final URLs
After launch, every internal link should point to the final destination URL directly — never to a URL that 301-redirects. Redirected internal links work for users but waste crawl budget and dilute the “these are my real URLs” signal you’re trying to send. Navigation, breadcrumbs, in-content links, XML sitemaps, and canonical tags should all reference the new address. This is exactly the kind of issue that hides at scale: a header nav updated but 400 in-body links still pointing at old slugs. A real-crawler site audit — the kind SEO Rocket runs continuously rather than as a one-off desktop scan — surfaces internal links that resolve through a redirect, broken links, and redirect chains automatically, with the offending source page named so you can fix it at the template.
Technical Parity: Structured Data, Sitemaps, Core Web Vitals
Carry over everything the old site earned. Re-implement structured data (JSON-LD for Article, Product, FAQ, Breadcrumb, Organization — whatever you ran) on the new templates, because rich results vanish the moment the markup is missing. Generate a fresh XML sitemap of the new URLs and submit it, and keep the old sitemap available too for a while — counter-intuitively, letting Google re-crawl the old URLs speeds up how fast it processes your redirects. On performance, know the current thresholds: LCP ≤2.5s, CLS ≤0.1, and INP ≤200ms are the “good” bars (INP replaced FID as a Core Web Vital in March 2024). A new platform can silently regress these with heavier templates or layout shift, so measure the new site against the CrUX baseline you captured, not against a vague sense that it “feels fast.”
Launch-Day Checklist
The go-live window is where small misses become outages. Run this sequence:
- Confirm redirects fire — spot-check high-traffic and deep URLs, and verify each returns a single 301 to a live 200, not a chain or a 404.
- Confirm robots.txt allows crawling and does not contain a leftover
Disallow: /. - Confirm no production page carries the staging
noindex. - Check canonical tags resolve to the correct protocol, host, and trailing-slash convention.
- Submit the new XML sitemap in Search Console and re-submit the old one.
- For a domain or host change, use the Change of Address tool in GSC — it explicitly signals the move to Google and speeds signal transfer (it applies to hostname changes, not folder-level restructures on the same domain).
- Verify analytics and Search Console are installed and firing on the new property.
Post-Launch Monitoring: Where Drops Actually Show Up
A migration isn’t “done” at launch — the first four weeks are where you catch the failures. Watch the GSC Crawl Stats and Coverage/Pages reports for a spike in 404s, “Discovered – not indexed,” or unexpected redirects; those are your redirect map’s gaps made visible. Server log files are the ground truth here: they show exactly which old URLs Googlebot is still hitting and what status code it gets back, which tells you whether the crawler has re-processed your moves or is still stuck on the old address space. Track rankings and organic traffic daily against the baseline — a modest, temporary dip while Google re-crawls is normal; a sustained slide concentrated on specific URL groups points to a fixable technical fault, not “migration turbulence.” SEO Rocket’s rank tracking and site audit are built for this continuous-monitoring phase, catching status-code problems and ranking slides as they happen rather than at the next manual crawl. Be honest about the ceiling, though: for the deepest enterprise log-file analysis, a dedicated crawler still earns its place — treat the automated audit as the always-on layer, not a claim to replace forensic log work.
A Realistic Recovery Timeline
Set expectations before launch so a normal dip doesn’t trigger a panicked rollback. Even a clean migration usually shows a short-term ranking wobble in the first two to four weeks as Google re-crawls and re-attributes signals. A well-executed move typically stabilizes and returns to baseline within one to three months; larger or messier migrations (replatform plus URL change plus redesign at once) can take longer. If you’re still meaningfully down after three months, it’s rarely “Google hasn’t caught up” — it’s an unfixed fault: a redirect gap, a lingering block, lost internal links, or content that genuinely changed for the worse. The migrations that recover fastest are the ones where the redirect map was one-to-one and the baseline was complete enough to diagnose problems in hours instead of guessing for weeks. That discipline is the same one that scaled a portfolio past 1,000,000+ ranking pages — nothing clever, just refusing to lose signals you already earned.
Frequently Asked Questions
How long should I keep 301 redirects after a migration?
Keep them permanently, or at an absolute minimum one year. Google has to re-crawl every old URL before it fully transfers ranking signals to the new one, and deep or low-traffic pages can take many months to be re-crawled. Removing redirects early strands that equity and resurrects 404s for any old links still pointing in.
Will I lose rankings when I migrate my website?
A short, temporary dip in the first two to four weeks is normal even for a flawless migration, because Google re-crawls and re-evaluates the moved URLs. A clean move recovers to baseline within one to three months. A large, sustained loss almost always signals a technical fault — broken redirects, a staging block that shipped, or lost internal links — not the migration itself.
Do I need the Change of Address tool in Google Search Console?
Yes, for a domain or hostname change. It explicitly tells Google the site has moved and accelerates signal transfer from the old property to the new one. It does not apply to same-domain restructures (like changing your URL folder structure), where correct 301s and an updated sitemap do the work instead.
Should I migrate content and technical changes at the same time?
Avoid it if you can. Bundling a replatform, a URL change, and a full content rewrite into one launch makes diagnosis nearly impossible — you can’t tell whether a drop came from a bad redirect or worse copy. Where the timeline allows, migrate the technical structure first, confirm stability, then iterate on content.
