Prevent Traffic Loss: 90 Day Website Migration SEO Checklist

A migration will not automatically wreck your rankings, but skipping preparation usually does. Benchmark your current performance in Search Console and GA4, build a complete redirect map before a single line of code changes, and confirm three things on launch day: noindex tags are removed, redirects resolve correctly, and your new sitemap is submitted. Get those right and most of the risk disappears.

TL;DR:

Proper pre-migration audits include exporting baseline data from Search Console and GA4 to distinguish migration effects from algorithm updates.

A comprehensive crawl and a prioritized list of key pages ensure vital organic traffic and backlinks are protected during redirect planning.

Testing staging redirects and removing noindex tags before launch prevents common hangovers caused by staging leftovers or canonical errors.

Maintaining redirects for at least 12 to 24 months helps preserve link equity, as backlinks and cached links update gradually over time.

In-house team coordination from planning through 90-day post-migration monitoring reduces failures caused by miscommunication and ensures quicker fixes.

WWS – Web Development + SEO

Protect Your Search Visibility

WWS combines in-house web development and SEO to help local businesses maintain a stronger digital presence through website changes.

Explore WWS services

What Is Website Migration SEO and Why Does It Matter?
Pre-Migration Planning: What Should You Audit Before You Move?
How Do You Test a Migration Safely on Staging?
How Should You Map URLs and Handle Redirects?
What Should You Check in the First 48 Hours After Launch?
How Long Should You Monitor SEO After a Site Migration?
What Are the Most Common Website Migration Mistakes?
How WWS Approaches Migration Without the Guesswork
What Most Migration Advice Gets Wrong
Ready to Migrate Without the Guesswork?
Sources
FAQ

What Is Website Migration SEO and Why Does It Matter?

Website migration SEO is the discipline of protecting search rankings, indexed pages, and organic traffic while you change a site’s domain, platform, URL structure, design, or hosting. It is not a single task. It is a sequence of checks that run before, during, and after the technical switch, and each phase catches a different category of failure.

The reason this deserves its own process, rather than “just launch it and see,” comes down to what actually causes traffic drops. A pre-migration SEO audit that captures baseline metrics from Search Console, analytics, a full crawl inventory, and backlink data is critical for diagnosing what changed after launch and why. Without that baseline, you’re guessing.

The stakes are real but not mysterious. A prolonged traffic suppression after a site move, often called a migration hangover, can persist for months. Most of these hangovers trace back to preventable execution errors: missing redirects, forgotten noindex tags, or a canonical mess left over from staging. That’s the good news buried in the bad news. If the causes are preventable, the outcome is controllable.

Pre-Migration Planning: What Should You Audit Before You Move?

Everything downstream depends on what you document now. Skip this phase and you’ll spend weeks after launch trying to reconstruct what “normal” looked like, usually while a client or your boss is asking why traffic fell off a cliff.

Start with a full export from Google Search Console and GA4. Pull queries, landing pages, clicks, impressions, click-through rate, and average position for at least the trailing 12 months, ideally 16 to account for seasonality. In GA4, export sessions, conversions, and revenue by landing page. This becomes your control group. Without it, you can’t tell whether a ranking drop three weeks post-launch is migration fallout or a Google core update that happened to land the same week.

Next, run a complete crawl of the existing site. Crawlers built for this job map every indexed and linked URL, along with status codes, titles, and internal link counts. Save that crawl as your master URL inventory. You cannot build an accurate redirect map from a sitemap alone. Sitemaps often miss orphaned pages that still rank and still receive links.

Identify your priority pages before you map anything. Not every URL deserves equal attention. Rank pages by three factors:

Organic traffic volume over the trailing 12 months
Conversion or lead volume attributed to that page
Number and quality of external backlinks pointing to it

A prioritized shortlist, often the top 20 to 50 URLs, dramatically lowers risk because most sites concentrate the bulk of their traffic and equity in a small fraction of pages. Get those exactly right and you’ve protected the majority of your organic value even if something smaller slips through.

Your redirect spreadsheet is the backbone of the entire migration, and it needs specific columns to function as a working document rather than a wish list:

Old URL (exact, including trailing slashes and query parameters)
New URL (the destination after migration)
Redirect type (301, 302, or 410 for pages being retired)
Priority tier (based on the traffic/conversion/backlink ranking above)
Verification status (not tested, tested on staging, confirmed live)
Owner (who is responsible for confirming this row)

Finally, this is not a solo project. Bring in development, content, and marketing stakeholders before build starts, not after something breaks. Successful migrations tend to be organizational as much as technical, and appointing a single migration owner who coordinates across those teams cuts down on the cross-team failures that cause the worst hangovers. Set a rollback trigger in advance too. Agree on what traffic drop, over what time window, would justify reverting to the old site, so that decision isn’t made in a panic on day three.

Pro Tip: Keep your redirect spreadsheet in a shared document, not a local file. The most common migration failure isn’t a technical mistake. It’s three people updating three different versions of the same map and nobody catching the conflict until launch day.

How Do You Test a Migration Safely on Staging?

Staging exists to catch the mistakes that are expensive to fix after launch. Treat it as a dress rehearsal, not a formality.

Block public and search engine access first. Use HTTP authentication or an IP allowlist rather than relying solely on a robots.txt disallow, which search engines can occasionally still crawl around. If you need Googlebot to see specific pages for testing, use Search Console’s URL Inspection tool on a controlled basis rather than opening the whole staging environment.
Audit templates, not individual pages. Check title tags, meta descriptions, canonical tags, structured data, and hreflang attributes (if you run multiple language or regional versions) at the template level. A single template error can propagate across thousands of URLs, which is exactly how a migration goes from “minor issue” to “hangover.”
Benchmark Core Web Vitals before launch, not after. Compare staging performance against your old site’s baseline. If Largest Contentful Paint or Interaction to Next Paint regresses on the new build, fix it before launch rather than treating speed as a post-launch cleanup item. Site moves also tend to temporarily spike crawl activity, so confirm your hosting can absorb heavier bot traffic without slowing real users down.
Test the redirect map on staging before it goes live. Run every row of your spreadsheet through a crawler pointed at staging and confirm each resolves to a single 301 or 308, not a chain, not a soft 404. Also test robots.txt and check for stray noindex meta tags. This matters more than it sounds: migration hangovers frequently trace back to noindex or canonical tags copied over from a staging template and never removed before launch.

Statistic to remember: hangovers caused by these staging leftovers are among the most preventable failures in the entire migration process, because every one of them is catchable with a pre-launch crawl. There is no excuse for a live noindex tag surviving past hour one.

How Should You Map URLs and Handle Redirects?

Redirect strategy is where migrations quietly succeed or visibly fail. Get the mechanics right and link equity transfers cleanly. Get them wrong and you create the exact conditions that produce a months-long hangover.

Server-side 301 or 308 redirects are the standard for any URL that has a genuine replacement, because they pass ranking signal and tell both users and crawlers the move is permanent. Reserve 410 (Gone) for pages you’re deliberately retiring with no equivalent content elsewhere. Sending Google a clean 410 is more honest, and often more effective for cleanup, than pretending a dead page still has a home.

Avoid these common mapping errors:

Redirecting deleted pages to the homepage instead of the closest relevant page. This is one of the most frequent causes of major post-migration traffic loss, because it signals to Google that the destination has nothing to do with the original content.
Creating redirect chains, where URL A points to B, which points to C. Chains should be flattened to a single hop using a crawler like Screaming Frog or Sitebulb to detect them before launch.
Leaving query parameters or trailing slash variants unmapped, which creates duplicate content issues on the new site.

When a page genuinely has no replacement, map it to the most topically relevant category or parent page rather than the homepage by default. A visitor landing on a redirected plumbing-repair page should land on your new plumbing services page, not your homepage.

Verification needs two layers. Run an automated crawl of the full redirect map against the live site to confirm every row resolves correctly. Then manually check your top 20 priority pages by hand, because automated tools miss edge cases like redirect loops that only trigger under certain query strings.

Pro Tip: Keep every migration redirect active for a minimum of 12 to 24 months, even ones you’re confident are fully absorbed. Backlinks update slowly, some webmasters never update a link at all, and ranking signal transfer isn’t instant. Removing redirects early is one of the few migration mistakes with no upside.

If your migration involves a domain or subdomain change, plan to file Google’s Change of Address tool once redirects are confirmed live. It helps Google prioritize crawling the new site and forwards ranking signals for a defined window, but it only works correctly after the redirects themselves are functioning, not before.

What Should You Check in the First 48 Hours After Launch?

The first two days determine how fast Google understands what happened to your site. Work through this in order.

Confirm noindex tags and robots.txt are correct on the live, public site. Spot-check at least 10 to 15 pages across different templates, not just the homepage. A single noindex left on a template can quietly deindex an entire section within days.
Verify redirects are live and returning the correct status codes. Run your full redirect crawl again, this time against the production URL, not staging. A redirect that worked on staging can fail in production if server configuration differs.
Submit your updated sitemap to Google Search Console immediately. If you moved domains, submit sitemaps to both the old and new properties to speed up discovery of the new URLs. This is also the point to file the Change of Address tool if applicable, once redirects are confirmed functioning.
Check canonical tags, hreflang, schema markup, and internal links on a representative sample of pages. Look specifically for canonicals still pointing at staging URLs, a surprisingly common leftover.
Monitor server load and Googlebot crawl activity. Migrations tend to trigger a temporary crawl spike as Google works to re-index the new structure. If your hosting struggles under that load, coordinate with your hosting provider to throttle or scale resources rather than letting the site slow down for real visitors.

Treat these 48 hours as damage control, not celebration. The migration isn’t done at launch. It’s just entering the phase where problems become visible.

How Long Should You Monitor SEO After a Site Migration?

Give it 90 days, structured, not just 90 days of occasional glancing at a dashboard.

Watch four reports on a recurring basis: Search Console Performance and Coverage, GA4 traffic and conversions by landing page, and results from a scheduled recrawl of your priority URL list. A tool that tracks your Google ranking positions daily rather than weekly will surface a ranking slide faster than Search Console’s own reporting lag allows.

When something looks wrong, triage in this order, because fixing them out of sequence wastes time chasing symptoms instead of causes:

Redirects first. Confirm every priority page redirects correctly and isn’t chaining or looping.
Indexation second. Check Coverage reports for pages excluded by noindex, canonical, or crawl errors.
Canonical tags third. A canonical pointing to the wrong URL can quietly suppress an otherwise healthy page.
Content loss fourth. Compare word count, headers, and internal links against your pre-migration crawl.
Performance last. Core Web Vitals regressions matter, but they rarely cause the sharp traffic drops the earlier four categories do.

Run a structured check at 30, 60, and 90 days, and schedule a full post-launch audit at the 90-day mark regardless of how things look. If a priority page still isn’t reindexed by day 30, request reindexing manually through Search Console rather than waiting. Document every fix you make and when, both for your own reference and so stakeholders can see the causal chain if traffic dips get questioned later.

Pro Tip: Don’t forget outreach. If your top backlinks point to old URLs that now redirect, a quick email asking the linking site to update the link directly (skipping the redirect hop entirely) preserves more equity than the 301 alone ever will.

What Are the Most Common Website Migration Mistakes?

Some traffic movement after a migration is normal. A true hangover looks different: a drop that holds steady or keeps worsening past the four to six week mark.

The recurring culprits behind that pattern:

A noindex tag or staging robots.txt rule that migrated to production and was never caught
Missing redirects for URLs that existed on the old site but weren’t captured in the crawl inventory
Canonical tags pointing to the wrong version of a page, or still referencing staging
Deleted pages mass-redirected to the homepage instead of a relevant replacement

Diagnosing the real cause means cross-referencing your pre-migration crawl against a fresh post-launch crawl, checking Search Console’s Coverage report for excluded URLs, and reviewing your backlink profile for links now pointing at broken or redirected chains. That comparison usually points straight at the problem within an hour of focused work.

Rolling back should be a last resort, reserved for cases where the root cause can’t be isolated and fixed within a reasonable window, typically a few days. If you do roll back, document exactly why and what specific failure triggered it, because that record is what prevents the same mistake on the next migration.

How WWS Approaches Migration Without the Guesswork

Every step above works better with a single team accountable for all of it, instead of a developer, an SEO contractor, and a content manager each assuming someone else caught the noindex tag. That’s the structural advantage of an in-house model: development and SEO working from the same task list can deploy a fix in hours, not after a support ticket clears a queue.

WWS – Web Development + SEO runs migrations as an in-house Google and Meta Partner team, meaning the people building the redirect map are the same people who can push a server-side fix the moment monitoring flags a problem. They have a process built around single ownership of the redirect spreadsheet, staged QA checklists before any code touches production, and a defined post-launch monitoring cadence rather than a one-time check.

Urgent remediation, when it’s needed, doesn’t wait on a vendor call.

What Most Migration Advice Gets Wrong

Most migration guides treat the checklist as the finish line. Export your data, build the spreadsheet, test on staging, ship it. That’s necessary, but it isn’t sufficient, and the gap between “followed the checklist” and “kept the traffic” is almost always about accountability, not technique.

Here’s what the evidence actually supports: the technical steps in this article are not hard. Any competent developer can set up a 301 redirect. What’s hard is making sure someone actually checked all several hundred of them before launch, and that the person who wrote the redirect map is still answering emails on day three when something looks wrong. Conventional advice front-loads the audit and treats launch day as the finish. The 30 to 90 day monitoring window is where hangovers actually get caught or missed, and too many checklists give it a single bullet point instead of the structured triage it needs.

If you take one thing from this: prioritize your top 20 to 50 pages obsessively, and assign one human being who owns the redirect map from export to day 90. Everything else is execution detail.

— Online Marketing Experts

Ready to Migrate Without the Guesswork?

If you’re weighing a DIY migration against hiring outside SEO help, know that both paths carry real technical risk without dedicated oversight. WWS – Web Development + SEO handles migrations as one connected process, not a handoff between a web developer and a separate SEO consultant, which is where most redirect maps fall apart. Our in-house, Google and Meta certified team builds the redirect spreadsheet, runs the staging QA, and stays on monitoring through the 90-day window, so a flagged issue gets a same-team fix instead of a support ticket.

That structure is why WWS – Web Development + SEO has completed over 200 successful client partnerships for contractors, restaurants, and service businesses across Des Plaines and the greater Chicago area, most of them needing their site to keep generating calls and leads through the transition, not just survive it. If you’re planning a rebuild, a platform switch, or a full redesign, start with a look at our website design process, or get your current site evaluated through our website SEO services before you touch a single line of code.

Sources

For the technical specifics in this guide, these sources go deeper on each phase: Google’s own site move guidance, the Change of Address tool documentation, Search Engine Land’s migration planning framework, Search Engine Journal’s breakdown of migration hangovers, and Semrush’s phase-by-phase checklist. For a broader pre-launch audit framework, see this website audit checklist.

FAQ

Can a Website Migration Hurt SEO Rankings?

Yes, but only when execution fails, typically from missing redirects, forgotten noindex tags, or broken canonical references. Sites that benchmark performance beforehand and validate redirects on staging generally see minimal, short-lived fluctuation instead of a lasting drop.

How Long Does It Take Rankings to Recover After a Migration?

Minor fluctuations often stabilize within two to three weeks as Google recrawls the new site. A true hangover, caused by unresolved technical errors, can persist for months until the root cause is found and fixed.

Should I Use 301 or 302 Redirects for a Migration?

Use 301 (or 308) redirects for any URL with a permanent new destination, since they pass ranking signal correctly. Reserve 302 for genuinely temporary moves, which rarely apply to a full site migration.

When Should I Use Google’s Change of Address Tool?

Only after a domain or subdomain change, and only once your redirects are confirmed live and working. Filing it too early, before redirects function, defeats its purpose of helping Google prioritize the new site.

How Long Should Redirects Stay Active After Migration?

Keep redirects live for at least 12 to 24 months. Backlinks and cached links update slowly, and removing redirects too soon can strand residual link equity that hasn’t fully transferred yet.