How a Site Migration Should Run

What a migration actually is, and which kind you are doing

The word covers several different projects with different risk profiles, and half the confusion in migration planning comes from not naming which one is happening.

• URLs change — a new domain, a new URL structure, a platform move, or a restructure of the information architecture. This is the high-risk case and it is what the runbook below addresses.
• URLs stay the same — a hosting move, an IP change, or a CMS swap that preserves every path. Lower risk, but not zero, and Google publishes separate guidance for it under the heading of changing your web hosting. Read that documentation directly before planning one; the specifics differ from the URL-changing case and are not interchangeable.
• HTTP to HTTPS — a URL change technically, with one useful exception noted below.

The other thing to establish early is what the migration is for. A move driven by a commercial or platform requirement has a fixed date and the search work has to fit around it. A move driven by an SEO goal should be interrogated, because restructuring URLs for tidiness carries real risk and rarely repays it.

Before anything moves: the baseline

This step is what makes every later argument answerable. Without it, the post-launch conversation about whether traffic fell becomes a matter of competing recollections.

• A complete URL inventory, assembled from four sources because each misses what the others catch: a full crawl, the XML sitemaps, server logs where obtainable, and Search Console. Logs are the source that reveals URLs still being requested and still earning traffic while linked from nowhere.
• Search Console performance data, exported now. Retention is sixteen months and both the interface and its spreadsheet export cap at 1,000 rows. Whatever is not exported before the move cannot be recovered later in the shape you will want it. Export queries, pages, countries and devices.
• A ranking snapshot, understood as a diagnostic sample rather than a scoreboard, since results are personalized, localized and device-dependent.
• Core Web Vitals field data at the 75th percentile, split by device, so that a slower new site can be identified as slower rather than argued about.
• Revenue and conversions by URL and by template. This is what turns the mapping from an exercise in tidiness into a commercial one: the pages that earn get checked first, on launch day and every day after.
• The current index state — indexed counts from the Page Indexing report, so the post-launch recovery curve has a starting point.

The URL mapping, one row per URL

The mapping is a table with one row for every URL that exists today and the URL it will become. It is tedious, it is the thing everyone tries to automate away, and the automation is where the losses come from.

Three rules carry most of the value. No unmapped URL that currently returns 200. Every live URL either has a destination or an explicit, recorded decision to be removed — in which case it returns 404 or 410 deliberately, which Google treats as a strong signal not to crawl it again. No dumping to the homepage. Redirecting a retired section to the root because no equivalent exists discards whatever that page had earned, and a deliberate 404 is more honest and more useful to a visitor. No pattern rule ships without spot-checking its output. Regular-expression rules are efficient and they fail silently on edge cases: trailing slashes, uppercase paths, query strings, encoded characters, and legacy URLs from two platforms ago that are still receiving links.

Sort the mapping by revenue and by organic clicks before review, and review the top of that list by hand. Every row deserves to be right; the rows at the top deserve a human being's attention.

Redirects: type, hops, and how long they stay

Google recommends HTTP permanent redirects where possible, naming both 301 and 308. The 308 is routinely omitted by practitioners and is the one that preserves the request method, which matters on some platforms. A 302 signals a temporary move and is the wrong signal for a permanent one.

Hop count is as important as the code. Googlebot follows up to ten hops, but Google advises redirecting to the final destination directly. Chains are built accidentally, by layering a new rule on top of rules from previous migrations, and they should be collapsed to a single hop before launch rather than discovered afterward.

Duration is where most teams underestimate. Google's guidance is to keep redirects for as long as possible, generally at least one year, and to consider keeping them indefinitely from a visitor's perspective. Treat one year as the floor, not the target. Old links live in emails, printed material, third-party sites and bookmarks far longer than anyone expects, and retaining a redirect map costs nearly nothing compared with discovering which references were still live after removing it.

Redirects should be server-side. And internal links get rewritten from the mapping rather than left to resolve through redirects — every internal link pointing at a redirected URL is a needless hop for both visitors and crawlers.

Staging: where migrations are won and lost

Crawl the staging environment with the mapping applied and the redirect rules in place. What you are testing is not whether the new site looks right; it is whether every row of the mapping resolves in one hop to a 200.

Then confirm two opposite things, and note that they are in tension, which is exactly why this fails so often. Staging must not be indexable while it is staging — usually via authentication rather than noindex, since authentication cannot be forgotten. And whatever blocks it must be removed at launch. Shipping the staging blocker to production is the single most common catastrophic migration failure, and it produces a site that ranks for nothing within days while everyone congratulates each other on a smooth launch.

Also validate on staging, per template: canonical tags pointing at new URLs rather than old ones; hreflang annotations rewritten to new URLs with return links intact, since a migration silently breaks every one of them otherwise; structured data still present and valid; analytics and conversion tracking firing; and rendered HTML containing the content, checked on the new front end rather than assumed from the old one.

Build the rollback plan here too, with a decision rule attached — what specifically has to be true for a rollback to be triggered, who decides, and how long it takes. A rollback plan without a threshold is a sentence in a document, not a plan.

Launch day, in order

Sequence the day and assign each item to a named person before it starts. The checks are quick; the coordination is what fails.

1. Remove the staging blocker and verify by fetching robots.txt in a browser and confirming it reads as intended in production.
2. Test redirects across every template, not a sample of ten URLs from one section. Include the highest-revenue URLs from the sorted mapping by hand.
3. Sweep status codes for chains, loops and unexpected 404s. Any chain found today is one hop cheaper to fix today than next month.
4. Verify canonicals and hreflang on the live site, per template.
5. Submit the new sitemap in Search Console.
6. Confirm analytics and conversion tracking are firing on the new URLs. Tracking that breaks at launch produces an apparent traffic collapse that is not real, and it will cost you a week of misdirected panic.
7. Submit the Change of Address tool where the domain changed. It is required for domain migrations and must be submitted for all subdomains and both the www and non-www variants. It is explicitly not needed for an HTTP to HTTPS move.
8. Watch server logs and error rates for the first hours. A rise in 5xx responses under crawl load is both a visitor problem and a signal that reduces crawl capacity.

The monitoring window afterward

Monitoring means comparing against the dated baseline, not against a feeling. Four instruments, read on a schedule for at least a month.

Page Indexing — new URLs should be entering the index while old ones fall out. That crossover is the clearest picture of progress available, and its shape tells you whether the mapping was complete.

Crawl Stats — host status across robots.txt fetch, DNS and server connectivity, plus the response-code mix. A rise in 5xx or 429 during heavy post-launch crawling reduces crawl capacity exactly when you need it most.

Search Console Performance — by page and by query, compared with the exported baseline. Expect movement, and read it at the template level, because a change concentrated in one template is a mapping or rendering problem you can still fix.

Server logs and redirect error reports — the highest-resolution view of what crawlers are actually requesting, including old URLs nobody mapped.

Set the expectation in advance: Google's own estimate is that a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer. Some fluctuation during that window is normal. What is not normal is a single template flat at zero, and that is the pattern to escalate on immediately rather than wait out.

When the move has already happened badly

Plenty of migrations arrive as a post-mortem. The sequence still applies, run backwards, and it is usually recoverable if the old URL list can be reconstructed.

Rebuild the inventory of what used to exist, from whatever survives: Search Console's sixteen-month history, analytics landing page reports, server logs from before the move, the old sitemap if a copy exists, and external link data. Crawl the live site and identify which old URLs now return 404, land on the homepage, or resolve through chains. Map those to real destinations, prioritized by what they used to earn. Fix the chains to single hops. Check whether a staging blocker or stray noindex shipped, because it is the first thing to rule out and the fastest to fix.

Be honest about what recovery means. Google's position on changes after a drop is that some can take effect in a few days while others could take several months, and there is no guarantee that changes you make will result in noticeable impact. Restoring the redirects restores the signal path; it does not entitle anyone to the previous position. The full documented process is worth reading at source: Google's site move with URL changes guidance is the reference this runbook is built against.

Frequently Asked Questions

Published 2026-08-11