Enterprise Site Migration: The SEO Checklist
A step-by-step checklist for migrating a large site without losing organic traffic, from redirect mapping to the monitoring window after launch.
An enterprise site migration is any change that rewrites URLs across a large site at once: a new domain, a platform switch, a URL restructure, or several brand sites merging into one. Handled well, organic traffic dips briefly and recovers within weeks. Handled poorly, it can take the better part of a year to earn back rankings you already had.
This is one piece of running enterprise SEO properly: the governance, team structure and technical discipline a large site needs, of which a migration is the highest-risk single event.
On this page
What actually counts as an enterprise site migration?
Anything that rewrites, moves or removes URLs on a site large enough that nobody can fix the fallout by hand. Five triggers cover most of them: a domain change, a CMS or platform switch, an HTTP-to-HTTPS or subdomain consolidation, a URL structure change such as dropping or adding category folders, and a brand or acquisition consolidation where several sites become one.
A visual redesign that keeps every URL identical is not a migration in this sense. The SEO risk comes specifically from the URL changing under a page Google has already indexed, not from the page looking different, so a redesign alone belongs on a much shorter checklist than the one below.
If your trigger is really "several brand sites becoming one," read multi-brand SEO alongside this piece — the consolidation decision comes first, and the migration below is how you execute it once it's made.
The same checklist applies whether you are moving a hundred thousand URLs or several million — it's the same fundamentals as SEO for large websites generally, applied to the one event where getting them wrong is most visible; only the tooling around it changes. A team migrating a few thousand pages can track the redirect map in a spreadsheet and review it by eye. A team migrating several million pages needs the map generated and validated by script, because no reviewer can eyeball that many rows, and a single systematic error in a generation rule can silently misroute a large share of the site.
What actually causes the traffic loss after a migration?
Almost never the new design. It is a small number of mechanical failures repeated across thousands of URLs: a redirect map with gaps, so some fraction of old URLs return a 404 instead of forwarding; redirect chains, where the old URL forwards to another old URL instead of straight to the new one; and internal links inside the new templates that still point at the old paths, which quietly tells Google the migration is not complete.
A slower, quieter failure is losing internal link equity: if the new site's navigation and footer stop linking to pages the old one linked to constantly, those pages lose the internal signal that helped them rank, even though the redirect itself works fine.
Canonical tags and hreflang annotations fail the same way and get noticed even later. If a template change drops the canonical tag or points it at the wrong URL, or an hreflang set loses one of its language variants, nothing errors and nothing looks broken in a browser — the first sign is usually a slow decline in a specific market's traffic weeks after everyone has stopped watching the migration closely.
How do you map redirects for a large site?
Row by row wherever you can afford it, template rules only where the pattern is genuinely uniform. The three approaches trade accuracy for effort, and most enterprise migrations use a mix, weighted by how much organic traffic a group of pages is worth.
| Approach | Best for | Risk |
|---|---|---|
| 1:1 manual mapping | Your highest-traffic and highest-value pages | Slow; needs a dedicated tracker and owner |
| Pattern-based template rules | Large, genuinely uniform sections, like paginated listings | Silently wrong for the pages that don't fit the pattern |
| Catch-all fallback to a parent page | The long tail nobody will ever map by hand | Loses ranking value; use only after the two above are exhausted |
Whichever mix you use, the map needs one row per old URL with a mapped destination, a redirect type, and a status column your team updates as each one goes live. A spreadsheet is enough at ten thousand rows; past that, most teams put it in the same tracker they use for the rest of the enterprise SEO programme, so it survives the migration project ending.
What should be in the pre-launch checklist?
Everything that is expensive to fix after cutover and cheap to fix before it. The list below is the order we run it in with clients, and none of the steps is optional on a migration past a few thousand URLs.
Crawl the old site completely
You cannot build a complete redirect map from a sitemap alone; a full crawl catches orphaned pages, parameter variants and old URLs that still carry backlinks.
Build the redirect map and get it reviewed
A second person checks the map against the crawl, specifically hunting for rows with no destination and destinations that are themselves redirects.
Stage the new site behind a password, not a blanket noindex
A `noindex` tag left on by accident at launch is the single most common cause of a migration going badly wrong; a password wall cannot make that mistake.
Update internal links to point at final URLs
Every internal link should go straight to the new URL, not through a redirect, before launch — redirects are for external and historical links, not your own navigation.
Prepare the new sitemap and hold it for launch day
Submit it the moment the new site is live, not before, so it never points at pages that don't exist yet.
Test the redirect map before launch by requesting the full list of old URLs against the staging environment and recording the status code and destination for each one, rather than clicking around by hand. Clicking finds the pages you remember to check; a scripted test finds the ones you forgot existed, which on a large site is most of them.
Our technical SEO service runs this checklist end to end for clients mid-migration, including the redirect-map review, if you'd rather have a second team building and checking it alongside yours.
How long should you monitor after launch?
Longer than most project plans allow for. Google's own migration guidance is to keep every old-URL redirect live for at least a year, because recrawling and reprocessing a large site's worth of changed URLs takes far longer than the launch itself [1].
at least a year of redirects
Set three checkpoints rather than one. At 48 hours, confirm the redirect map is actually live and returning the right status codes — a broken deploy step here is common and easy to catch. At two weeks, compare crawl stats and indexed-page counts against your pre-migration baseline. At ninety days, compare organic traffic and rankings for your top pages by pre-migration value, because that is roughly how long a large site takes to fully reprocess.
Server log files are the most reliable early signal, because they show what a crawler actually requested, not what your analytics tool decided to report. If the crawl rate on the new domain has not caught up to the old one's within the first couple of weeks, that is worth investigating immediately rather than waiting for the traffic numbers to confirm what the logs already showed.
Who owns the migration on the SEO side?
One named person, even when the migration itself is an engineering-led project. Without a single SEO owner, the redirect map review, the launch-day verification and the monitoring checkpoints each drift to whoever remembers, which on a project with a hard launch date means they drift to nobody.
That owner does not need to write the redirect rules themselves, but they do need the authority to delay a launch over a mapping gap. If your organization does not yet have a clear answer for who that person is, SEO team structure covers how to define the role before your next migration, not during it.
The owner also needs a direct line to engineering, because most migration defects are fixed in code, not in an SEO tool. Write the redirect rules and the canonical-tag requirements as tickets in the same system engineering already uses, with acceptance criteria an engineer can verify without SEO knowledge, and the fixes land far faster than they would as a comment on a shared document nobody on the build team reads daily.
How do you know the migration worked?
Against the baseline you took before, not against a general sense of whether traffic "looks okay." Pull organic sessions, indexed-page count, and rankings for your top fifty pages by pre-migration value, and compare each one at 48 hours, two weeks and ninety days.
A short dip in the first two weeks with a clear recovery trend is normal and expected — that is Google reprocessing the site, not a sign anything is wrong. A dip that has not started recovering by week six is worth an audit rather than another week of waiting, since the fix is almost always one specific mapping gap rather than something structural.
Spot-check the Page Indexing report in Search Console for the "Not found (404)" and "Page with redirect" categories specifically, since a spike in either one usually points straight at the failure. Pair that with a manual check of ten or twenty of your highest-value old URLs, confirming each one redirects to a live, correct page in one hop rather than a chain — the automated report tells you something is wrong faster than traffic will, and the manual check tells you exactly where.
Questions people also ask
Will an enterprise site migration always hurt rankings?
Some fluctuation is normal while Google recrawls and re-evaluates every changed URL, but a well-mapped migration usually recovers within a few weeks. Sustained loss almost always traces back to a mapping gap, a lost redirect chain, or content that changed at the same time as the URLs.
Can we change the URL structure and the design at the same time?
You can, but it makes any problem harder to diagnose, because you no longer know whether a drop came from the URL change, the content change, or the design change. Separating them costs more calendar time and saves debugging time later.
How many redirects is too many for one migration?
There is no hard ceiling; sites with several million URLs redirect successfully. The risk is not the count, it is coverage: every old URL needs a mapped destination, not a guess.
Do we need to keep the old domain after a domain change?
Yes, for as long as you keep the redirects live. Letting the old domain's registration or hosting lapse breaks every redirect on it at once, which looks to Google exactly like the destination pages disappeared.
Sources
- Site Moves and Migrations — Google Search Central (checked 23 September 2026)
- Redirects and Google Search — Google Search Central (checked 23 September 2026)
Get a second set of eyes on your migration plan before you cut over
Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.
Who wrote this
Ibrahem HelalCo-founder
Leads strategy and delivery.
Works on: SEO, GEO
Reviewed before publishing by Jeremy Zava, Co-founder.
- Enterprise SEO: the buyer's guide for 2026Enterprise SEO is search work for large sites and large teams: what it covers, what it costs, who owns it, and how to prove it pays back.
- How to Run an Enterprise SEO AuditWhat an SEO audit needs to cover on a site with tens of thousands of pages, why crawl budget becomes a real constraint, and what to fix first.
- Multi-Brand SEO: A Practical PlaybookHow to run SEO across a portfolio of brand sites without them competing against each other, from domain strategy to shared structured data.
- SEO for large websites: a practical guideHow SEO changes on a large website: crawl budget, duplicate content, faceted navigation, JavaScript rendering, internal links and log files, in practice.