Site migration SEO checklist for large sites (2026)

A site migration SEO checklist for a large site runs in four gated phases. Map every old URL that earns traffic, links or conversions to one final destination. Test it on a locked staging site. Verify redirects, robots rules, canonicals, sitemaps and tracking on launch day. Then watch the old URLs as cohorts for 90 days, with a rollback trigger agreed in advance. On a big site, most of the risk sits in governance. Each gate needs a named owner who signs it off before the next one opens.

I'm Brenden House, and I run Searchmaxxed, an SEO and AI SEO agency. Most checklists on page one suit a small site. This is the version we run on large sites. There, the redirect map can run to tens of thousands of rows, and four separate teams can each stop a launch.

In summary

• Build the URL map from five sources. A sitemap alone misses old pages that still earn links and clicks.
• Give every legacy URL one of seven written states, from "retain" to "retire with a 410". No state, no launch.
• Test redirects on the server that will run them. A tidy spreadsheet proves nothing.
• Watch matched 7-day, 28-day and 90-day windows for each cohort of old URLs, because a sitewide traffic line hides the pages that broke.
• Keep redirects for at least a year. That's Google's advice, and the old domain should stay registered too.

The timings are my planning defaults for a site with tens of thousands of URLs. Smaller moves compress them.

What is a site migration in SEO?

A site migration is any change to the URLs, platform, domain, structure or templates that search engines already know. Migration SEO protects the rankings, links and conversions those old URLs earned, so the new site starts with them instead of from zero.

There are five kinds. Each one carries a different risk.

Large organisations love to bundle two or three of these into one project. Google's site move guidance says to "change only one thing at a time", for example the domain first and the layout later. Every extra change makes a loss harder to trace.

Google's Change of Address tool covers moves between domains or subdomains, so HTTPS moves and www changes on one domain skip it. Redirects do that job.

Why do large site migrations lose organic traffic?

Large migrations lose traffic for ordinary reasons. Old URLs go unredirected, staging rules leak into production, internal links point at redirects, and templates drop the elements that ranked. Scale turns each small fault into thousands of broken pages.

Even good work wobbles. Google's site move guidance warns of "ranking fluctuations while Google recrawls and reindexes your site". For medium sites, it says, "it can take a few weeks or more" before the new URLs show, "and for larger sites, even longer".

The faults that turn a wobble into a loss repeat across projects:

1. Missing URLs. Teams map what the sitemap lists. They miss old campaign pages, PDFs and retired product URLs that still hold links.
2. Staging rules shipped live. A noindex tag or a robots.txt block from staging reaches production, and it sits first on Google's own list of site move mistakes.
3. Template drift. The new CMS writes generic titles, drops canonicals or only renders key copy in the browser.
4. Content cut in the redesign. A 2,000-word guide becomes a 300-word card. Every search it used to answer leaves with it, and so do the links that pointed at the long version of the page.
5. Broken tracking. Conversions stop counting, so nobody can tell whether the drop in traffic is real or a reporting fault.

All five are cheap to catch before launch and expensive to find afterwards. Hence the gates.

Who should sign off a site migration?

Each phase needs one named owner and one written sign-off before the next phase starts. On large sites, give the SEO lead a veto at the launch gate, because no other team can see what a broken redirect costs.

Here's the sign-off matrix I'd put in front of a steering group. R does the work and A signs it off. C gets a say before anything is final, and anyone marked I hears the outcome after the owner signs it.

Three governance rules save the most pain:

• Freeze the candidate. Everyone reviews one fixed build, and if anyone changes it during sign-off, even by a single line, every earlier check starts again.
• Write the rollback trigger before launch. Name the cohort, the size of drop and the time window that sends you back. Arguing about it on day three burns the window.
• Keep the old system alive. The old platform, domain, analytics property and redirect history all stay until the new site checks out and the rollback window has closed.

Public-sector bodies and listed companies add procurement, security reviews and change-board dates, and each of those can hold a launch for weeks. Put them on the plan as gates with owners.

How do you map URLs at scale?

Build one register of every legacy URL from at least five sources. Give each URL a written disposition, then redirect it to one final destination in one hop. On a large site, that register is the migration.

Step 1: build the inventory from five sources

No single source has them all. Pull from all five and merge them on a normalised path:

Add server logs if you can get them, because they show the old URLs Googlebot still asks for long after your team forgot them.

Then give the steering group three numbers: each source's raw count, the overlap and the union. "We have 41,000 URLs" means nothing. Nobody can tell whether that includes 9,000 parameter duplicates or a docs subdomain someone forgot about.

Step 2: give every URL one disposition

We use seven states. A URL with no state blocks the launch.

Back every non-retain decision with evidence. Look at clicks, impressions, conversions, linking domains and what the page says. Never send everything to the homepage. It drops people somewhere irrelevant and throws away what the page was about.

Step 3: match old to new, highest value first

Split the register into three value tiers before anyone starts matching.

• Tier one is the few hundred URLs carrying most of the clicks, links and conversions. A person maps each one by hand and checks the new page answers the same search.
• Tier two maps by pattern rules, such as /products/{sku} to /p/{sku}.
• Tier three is the long tail. Rules match it, and someone spot-checks a sample.

Google asks you to move embedded content as well: "videos, images, JavaScript, and CSS files". Images and PDFs are where big maps leak most.

Step 4: write the redirect rules

Use server-side permanent redirects. Google lists 301 and 308 as permanent, while 302 and 307 are temporary and don't signal that the target should be canonical. Googlebot can follow up to 10 hops. Google still advises redirecting straight to the final page, and otherwise keeping chains "ideally no more than 3 and fewer than 5".

Fold old redirects into the new map. A URL that already redirected twice on the old site should reach its final page in a single step.

A worked example

Take a B2B SaaS company merging three things onto one new platform: its marketing site, its docs subdomain and an acquired brand's domain. These are example figures. The inventory finds 46,000 raw URLs, and 31,000 once duplicates go. About 600 make tier one.

Each part of the estate needs a different treatment, and the mistakes usually come from treating all three the same way. The docs subdomain moves on path rules. The acquired domain needs its own Change of Address in Search Console, and its product pages overlap with the parent brand's. Those get consolidated page by page, keeping whichever version ranks for the search.

What should you check on staging before launch?

Lock the staging site, crawl it and compare the crawl with the live site, template by template. Then run the redirect map against the staging server itself, and hold the launch until every difference in the crawl has a written decision.

Work through this list before anyone books the launch date:

1. Lock it properly. Put staging behind a login, or send an X-Robots-Tag: noindex header on every response. A robots.txt block alone can stop crawlers from ever seeing a noindex.
2. Crawl old and new, then diff them. Compare status codes, title tags, meta descriptions, H1s, canonicals, word counts and internal links for each template.
3. Check rendering. Fetch the key templates with JavaScript turned off and read what's left. If the main copy, links or schema only appear after scripts run, fix it now.
4. Match structured data to the page. Schema should describe what the visible page says.
5. Carry hreflang across. International sites need every alternate URL updated, in both directions.
6. Point internal links at final URLs. Navigation, footers, related links and body copy should never link to a redirect.
7. Test every redirect on the server. Confirm one hop, the right target and the right status code for the full map, including encoded and Unicode paths.
8. Confirm unknown URLs still 404. A catch-all that returns 200 for any path creates thousands of soft 404s.
9. Measure speed on the templates that earn. Core Web Vitals on the homepage tell you little about product and solution pages.
10. Test tracking events by name. Fire every form and conversion on staging, then confirm GA4 counts each one as a key event.

Don't skip the last one. Here's one from a GA4 audit we ran for a client, and it had nothing to do with a migration. A client's four enquiry types never counted as conversions. Their event names ran 41 to 50 characters; GA4 cuts at 40. The 40-character "career" event counted every time. Nobody had noticed, because the events still showed up.

Now picture a fault like that surfacing on the morning of launch, with the steering group watching the conversion chart fall to zero. The team would lose a week blaming the redirects.

Prepare three launch files on staging too: a production robots.txt, a sitemap of new URLs and a sitemap of the old URLs. Google suggests submitting both after the move. You'll watch one empty as the other fills.

What should you verify on migration launch day?

On launch day, check redirects, robots rules, indexing directives, canonicals, sitemaps and tracking on the live domain, in that order. Google suggests timing the move for a traffic dip. Tier one goes first.

For domain moves, Google's Change of Address help says to cover "all subdomain variants of the old domain, including www and non-www". IndexNow takes redirected and deleted URLs as well as new ones, up to 10,000 per request. We ping it and resubmit the sitemap on every release of our own site.

Roll back if a go/no-go rule fails and nobody can fix it within hours, even when the new site looks fine in a browser. A day-one rollback costs far less than two weeks of broken redirects.

What should you monitor in the 90 days after a site migration?

Monitor old URLs as cohorts, not as one sitewide total. Compare each cohort's clicks, indexing and conversions with the matching window before launch, at 7, 28 and 90 days. Fix what broke in week one, and judge the whole migration at day 90.

We use the same three windows to measure all our work. Seven days catches faults. Twenty-eight days supports monthly decisions, and ninety days shows which way the migration is heading.

Some of these jobs run alongside those windows, and some outlast them:

• Keep redirects for at least a year. Google says that gives it time "to transfer all signals to the new URLs".
• Keep the old domain. Google recommends paying for it "for at least a year" so no one else can buy and use it.
• Update the links you control. That means profiles, partner pages, email footers, docs and links inside your product.
• Chase your best backlinks. Start with the linking sites that send real visits.
• Re-audit at day 30. Crawl the whole live site again, because the fixes you rushed out in week one often break something nobody was watching.

A Change of Address notice runs for 180 days. Google forwards signals from the old site for that whole period, so keep every redirect and the old domain in place.

How long does it take to recover SEO after a migration?

A clean migration on a medium site usually settles within a few weeks to a few months. Large domain moves can take far longer. Search Engine Land's migration guide says big sites with domain changes "may need as much as a year". Its example: Wise took about eight months to get back to its previous traffic.

Discovery can be quick. Here's a launch of our own. We launched a new site with 161 guides, each built for one search from the live results and People Also Ask. We submitted the sitemap and pinged IndexNow. No paid indexer. About 25 hours after Google's first crawl, 203 of 228 URLs were indexed. Indexed isn't ranked, though: 5,198 impressions in ten days and 5 clicks.

That was a brand-new domain with nothing to lose. A migration has a harder job, because it has to win back rankings the old URLs already held.

Does a site migration affect AI Overviews and ChatGPT answers?

Yes. AI answers cite URLs, and a migration changes them. For AI Overviews and AI Mode, Google's AI features guidance says: "There are no additional technical requirements." So the same redirect map protects both.

Add one step to the benchmark. Before launch, run the 20 to 50 buyer questions that matter most in ChatGPT, Gemini, Perplexity and Google's AI Overviews. Note which of your URLs each answer cites, add them to tier one, and rerun the same questions at day 28 and day 90.

Other engines keep their own indexes. That's why the Bing sitemap and IndexNow steps matter here, and IndexNow says its job includes helping "keep your content current in AI-powered search results".

How much does an SEO migration cost?

SEO migration cost depends on URL count, how many migration types you combine and how much content changes. StudioHawk's SEO pricing guide lists domain or platform migrations at A$3,000 to A$10,000 as a one-off project (GST not stated; read 27 October 2026, AEST).

Large estates tend to need more than a one-off project. Four things drive the price: the size of the register, the tier-one pages to map by hand, the staging rounds and who builds the redirects. Ask every provider whether the quote covers the 90 days after launch. That's where most recovery work happens.

Where does Searchmaxxed fit?

Searchmaxxed is an SEO and AI SEO agency for enterprise, B2B SaaS, venture-backed, manufacturing and public-sector companies. On a migration, we run the technical SEO end to end. That covers the URL register, redirect rules, staging checks, launch verification and 90 days of monitoring. We build the pages and fixes ourselves.

Our technical SEO service covers crawl, rendering, indexing, redirects, sitemaps, canonicals and schema. On large estates, enterprise SEO is where we fix templates that change thousands of pages at once. Is your current design worth keeping? Then our Agentic Migration moves it onto your own repository and hosting without a redesign, and hardens speed, schema and indexing on the way.

Here's how we run it. We build on an Agentic Website that you own: your repository, hosting, content and data. AI agents pull your Search Console and GA4 data and crawl the old and new versions. They also check what Google and AI answers show for your searches. We use that data to decide what to fix first. Then we ship it, check the live result and measure it in matched windows.

After the move, a managed package keeps the work going:

Searchmaxxed's work has generated more than A$10 million in revenue through search for its clients.

Is Searchmaxxed right for your migration?

We suit marketing and growth teams who want one team to plan the SEO side, build the fixes and stay for the 90 days after. We're the wrong call if you only need a redirect spreadsheet reviewed, or if your own engineers must write every line of code.

Mostly in the right-hand column? A one-off migration audit from a specialist will serve you better.

Still unsure? Our AI SEO Audit takes five business days and shows what your site is doing to itself before you move it.

Frequently asked questions

What should you do next?

Export the pages report from Search Console today, over the longest date range it offers. Count the URLs with clicks that your new sitemap doesn't include, because that number is the size of your redirect problem. If you'd like us to run the migration with you, let's talk pricing.