The Website Migration Checklist That Protects Rankings
The redirect map is the artefact that decides whether a migration holds. Everything else is preparation for writing it, or evidence that you wrote it correctly.
On This Page
The migration went live on a Thursday. By Monday the traffic graph had a cliff in it, and the review found the cause in about ten minutes. The redirect map covered the pages in the navigation and almost nothing else. A large part of the old site had no entry at all, because the URL list had been exported from the CMS and from nowhere else, and the CMS had never known about the campaign pages, the old category filters, or the posts from the platform before last.
That is the ordinary way website migration SEO fails. Not dramatically. The redirect map is the artefact that decides whether a migration holds, and it usually fails because it was assembled from the most convenient source rather than from every source.
Everything below is organised into four phases: inventory, mapping, launch, and the thirty-day watch. The order matters more than the individual items, because each phase produces the input the next one needs. Skip inventory and your map is incomplete. Skip mapping and your launch is improvisation. Skip the watch and you will find the gap when somebody asks why the quarter looks like that.
"Migration" here covers more than a domain change. A protocol change, a URL restructure, a replatform, a redesign that alters paths, a consolidation of several sites into one, or a split of one into several: all of them move addresses, and all of them need the same discipline. The work is the same whether it runs in-house or as a planned migration project, and the failure modes do not care who is holding the spreadsheet.
Website migration SEO comes down to the redirect map
A redirect map is a row for every old URL, carrying its destination, the status code it should return, and the reason somebody chose that destination. It is not the same thing as a set of rewrite rules. Rules are how you implement the map; the map is how you verify it. Teams that skip straight to rules end up with something that cannot be checked, because a regular expression tells you what it matched and never tells you what it missed.
Pattern rules are fine as an implementation, and on a large site they are the only sane implementation. But they cover the pattern and miss the exceptions, and the exceptions are disproportionately where the links point: the one post that got picked up widely, the campaign URL printed on something, the legacy path from two platforms ago. Build the map first, then write rules that satisfy it, then test the rules against the map. That last step is the one people describe as unnecessary right up until the week it would have saved them.
A migration is not a launch. It is a promise that every address you ever published still leads somewhere true.
Phase one: inventory every URL, not every page
Pages and URLs are different sets, and the difference is where migrations go wrong. One page can have a dozen addresses: with and without a trailing slash, with tracking parameters, with a filter applied, on the old protocol, on the www variant, in a paginated series. Inventory the addresses.
Where the URL list actually comes from
No single source is complete, which is why the first mistake is trusting one. Pull from all of these and merge them: the CMS export, every XML sitemap including the stale ones nobody has regenerated, a full crawl of the live site, analytics landing-page reports going back as far as the data does, the search-performance report from your webmaster tools, backlink data for pages that earn links, and the redirect configuration already in place from the last migration.
Then pull server logs, which most teams omit and which are the only source describing what is actually requested rather than what somebody published. Logs surface the addresses no CMS knows about: parameter variants, old feed paths, files linked from a PDF, and the endpoints a partner integration has been calling quietly for years. If you can only add one source to your usual process, add this one.
What to record against each URL
- Current status code. A URL already returning 404 or already redirecting needs a different decision from a live 200.
- Canonical and index directives. A page never meant to be indexed does not need preserving, but it does need a deliberate answer.
- Template or page type. This is what lets you map by rule later instead of by hand, so record it even when it seems obvious.
- Whether it earns anything. Entrances, conversions, referring domains. Pages that earn something get a hand-checked destination.
- Title, heading and structured data type. You will need these to confirm the new page carries what the old one did.
This is the same evidence base an SEO audit produces, which is why running one immediately before a migration is cheaper than running one immediately after. Before launch it is a plan. After launch it is a postmortem with the same page count and a worse mood.
Phase two: mapping, and the rules that keep it honest
Mapping is a long series of judgements, and judgements need rules or they drift by the third hour. These are the ones we hold to.
One hop, always. Old URL to final destination, directly. Chains accumulate quietly across successive migrations, and a chain that passes through two intermediate hosts is slower for users, weaker as a signal, and fragile in a way nobody notices until an intermediate rule is deleted. When you inherit existing redirects, flatten them into your new map rather than layering on top of them.
Map like for like where an equivalent exists, and to the nearest relevant parent where it does not. Never to the home page. A mass redirect to the home page tends to be treated as a soft error rather than a move, it tells the visitor nothing, and it is a way of avoiding the decision rather than making it. Where nothing relevant survives, a genuine 410 is a legitimate and honest destination.
| Old URL type | Map it to | Do not map it to |
|---|---|---|
| Product page, item discontinued | The closest surviving product, or its category | The home page |
| Category that no longer exists | The nearest surviving parent category | An internal search results page |
| Post consolidated into a longer piece | The section of the new piece that replaces it | The blog index |
| Page two onwards of a series | The equivalent page of the new series | Page one of the series |
| URL with tracking or filter parameters | The clean canonical equivalent | A 404, unless it was never valid |
| Page with no equivalent at all | A relevant parent, or a deliberate 410 | Anything chosen to avoid a decision |
| Old feed, sitemap or asset path | The new equivalent path | The nearest HTML page |
Give every row a reason. It costs a column and it saves an argument, because in six months somebody will ask why a page that used to rank now points where it points, and "it was in the spreadsheet" is not an answer. Consolidation rows need the most care: when three thin pages become one strong one, the survivor has to genuinely answer the query each of them answered, or you have not consolidated anything. You have deleted two pages and redirected to a third.
If the migration also changes where content lives, the shape of that content decides how mechanical the mapping can be. Content stored as typed fields produces a URL set you can derive; content stored as pasted markup produces one you have to read. A workspace like Acrosite takes the structured route: it generates the required files, commits them to GitHub and triggers the configured deployment, so the addresses follow from the content model rather than from whatever a previous editor typed into a slug field.
The three things people forget
Every migration review we have run has found at least one of these, and usually two. They are forgotten for the same reason: none of them appear in the sitemap somebody used as the source of truth.
Parameters
Query strings carry filters, sorts, tracking, sessions, print views and pagination, and older platforms served real content on them constantly. Two failures follow. A rule that strips parameters on redirect destroys campaign attribution for every link already in circulation, so a click from a newsletter sent last year arrives untracked. A rule that preserves them blindly can generate an unbounded set of parameterised addresses on a new site that never intended to have any.
Decide per parameter, not globally. Tracking parameters should usually pass through to the clean destination. Filter and sort parameters should resolve to whatever the new site considers canonical for that view. Session identifiers should not survive at all. Write the decisions down beside the map, because this is the part that gets re-litigated at launch when somebody notices a report has gone quiet.
Paginated series
Blog archives, category listings and product grids all run in series, and every page after the first is treated as expendable right up to the moment it matters. Those pages hold the crawl path to older content. Collapsing an entire series onto page one leaves deep pages reachable only through a sitemap, which is a slower and weaker route than a link.
Where the series survives, map page for page. Where it does not, map to the closest equivalent listing and make sure the deep items are still linked from somewhere real. And check the sequence itself on the new site: a series that renders correctly on page one and 404s on page nine is a defect nobody finds by browsing, because nobody browses to page nine.
Internal links still pointing at old URLs
Redirects exist for links you do not control. Internal links you do control, so leaving them pointing at old addresses means paying a redirect hop on every crawl and every click, permanently, for no reason. Search and replace across body content is the easy half. The hard half is everywhere else: navigation, footers, hard-coded component links, canonical tags, hreflang annotations, structured data URL properties, feeds, and any absolute URL sitting in an email template. Internal linking is already the cheapest work nobody schedules, and a migration is the one week when it is unavoidable.
Phase three: the launch sequence
Run these in order on cut-over day. The sequence exists because several of them are only verifiable once the one before it is true.
- Freeze content and URL changes. A map validated against a moving site is not validated. Announce the freeze earlier than you think you need to.
- Confirm the staging block is gone. Check the live robots.txt and the meta directives on the live domain by fetching them, not by trusting the deployment note.
- Deploy redirects with the new site, then test the full map. Every row, not a sample. Record the status code and the final destination, and fail the launch on any chain or loop.
- Publish the new XML sitemap, and a temporary one of old URLs. The second helps crawlers reach the redirects sooner. Retire it once the old addresses have been processed.
- Fix every absolute URL in the templates. Canonicals, hreflang, structured data, feeds, Open Graph tags and the logo link in the email footer nobody owns.
- Verify analytics and conversion tracking on the new templates. Do this before traffic arrives, not after somebody notices a week of missing form submissions.
- Tell the search engines the site moved. Use the change-of-address tooling for a domain move, and make sure both properties are verified beforehand.
- Keep the old host able to serve redirects. For a domain change this is the entire mechanism. Budget for it well past the point where it feels necessary.
The most common self-inflicted migration failure is a staging environment’s crawl block reaching production, or a production block left in place from the build. Fetch the live file after cut-over and read it with your own eyes. Then check the meta directives on a handful of live templates, because the two fail in different places and hide from each other. Set a reminder to check both again a week later, after the next deployment has run.
Phase four: the thirty-day watch
The launch is the least informative day. What matters is the month after it, watched in a specific order, because the cheapest signals also happen to be the most diagnostic.
Start with server logs. They tell you what crawlers are requesting, which old URLs are still being hit, and which of those return something other than a single clean redirect. A 404 in the logs is a row missing from your map, and it is far easier to fix in the first week than in the sixth. Then move to the indexing reports: how many new URLs are known, how many are indexed, and what reason is given for the ones that are not.
Re-run the full redirect test weekly for the first month, because deployments overwrite rules and nobody means to. Check the pages that previously earned rich results, since structured data only earns something when the right types are emitted and a template rebuild drops them silently. Then look at field performance rather than lab scores, because a new platform changes real-world timings in ways a synthetic test flatters; the argument for which numbers deserve chasing is in are Core Web Vitals still worth chasing.
Last, watch the things that pay. Form submissions, enquiry quality and the routing behind them all break quietly during a replatform, and a form that posts successfully into nowhere looks identical to one that works. Our parent company makes the case for treating that form as an instrument rather than a widget in a form is a triage instrument, and a migration is exactly when that stops being theoretical.
When the numbers dip anyway
Some movement after a migration is normal even when the work was clean, because new addresses have to be crawled, evaluated and reconciled against everything that pointed at the old ones. The useful question is not whether there is a dip. It is whether the dip has a mechanical cause you can find.
Three checks, in order, settle most of it. Does the old URL return a single redirect straight to the intended destination? Is the destination indexable, and has it actually been indexed? Does the destination page carry the content that earned the old ranking, including the headings, the depth and the internal links pointing into it? If all three answer yes and performance is still down, the cause is almost always the third one in disguise: a consolidation removed something the page was answering, or a template rebuild quietly shortened the copy.
A migration that also rewrites content, changes the information architecture and launches a new brand is several changes measured on one graph, and afterwards nobody can attribute the result to any of them. Sometimes that is still the right call, because running the work separately costs more than the ambiguity does. Make it a decision rather than an accident, and write down what you expect from each part before launch so the argument afterwards has evidence in it.
When the brand work and the build genuinely have to move together, the sequencing deserves its own thought, and our parent company has written about it in when brand and build run together. The short version is that combining them is defensible and combining them by accident is not.
Where we would start, and when to change URLs anyway
Our default position is unfashionable and we hold it firmly: if you can migrate without changing URLs, change nothing. A replatform that keeps every address is a technical project with a small search risk. A replatform that also restructures paths is two projects, and the second one carries all the danger. Redesign the templates, move the hosting, replace the CMS, and leave the addresses where they are.
The reversal, and it is a common one: when the URL structure is itself the problem, keeping it is the more expensive choice. Duplicate paths for the same content, parameters serving as primary navigation, no hierarchy a human could describe, or a structure that encodes a business the company no longer runs. In that case change it once, deliberately, with a complete map, and never in increments. Half a restructure is the worst of both, and it is the state most sites we inherit for technical SEO work are already in.
One honest limitation worth stating plainly. A perfect map protects what the old site earned; it cannot manufacture more. If a migration is being justified by an expected improvement in search performance, that improvement has to come from something specific on the new site: pages that answer queries the old ones did not, an architecture that concentrates rather than scatters, faster real-world delivery. Migration hygiene is the floor, not the ceiling, and confusing the two is how a technically flawless launch ends up being described as a disappointment.
If the move is part of a wider rebuild rather than a lift and shift, it belongs in a website transformation plan where the content model, the templates and the redirect map are designed together rather than in sequence. And if you are already mid-migration and something is not behaving, send us the URL list and what you are seeing. The logs usually answer it faster than the dashboards do.
Common questions.
How do I know whether my site migration has recovered?
Judge it by three signals rather than by the calendar. Server logs should show old URLs returning a single clean redirect and few unresolved 404s. Indexing reports should show the new addresses known and indexed, with reasons given for any that are not. Search performance should be compared page by page against the equivalent old URL, not as one site-wide total, which hides both recoveries and losses.
Should I use 301 or 302 redirects when migrating a website?
Use 301 for a permanent move, which is what a migration is. A 302 signals that the original address will return, so search engines may keep the old URL in their index and treat the change as temporary. Reserve 302 for genuinely temporary situations such as a maintenance page or a short-lived campaign diversion, and check that your platform is not quietly defaulting to it.
Can I redirect old pages to the home page?
Avoid it. Large numbers of redirects to the home page are commonly treated as soft errors rather than as a move, so the signals attached to the old page are unlikely to carry across, and the visitor arrives somewhere that does not answer what they clicked for. Redirect to the closest relevant page instead, and where nothing relevant exists, return a deliberate 410 rather than a misleading destination.
What is a redirect chain and why does it matter?
A redirect chain is an old URL that redirects to another redirect before reaching a final destination. Chains slow every request, waste crawl effort, and break entirely if an intermediate rule is later removed, which is exactly what happens during the next migration. Flatten inherited redirects so each old address points straight at its final destination in one hop, and test for chains before launch rather than after.
Do I need to keep the old XML sitemap after a migration?
Publish a temporary sitemap of the old URLs alongside the new one at launch. It helps crawlers reach the redirects sooner than they would by following links alone, which shortens the period where old addresses are still being served from an index. Retire that temporary sitemap once the old addresses have been processed, and make sure the new sitemap lists only canonical, indexable URLs.
Should I redesign and change URLs at the same time?
Only if you accept that you will not be able to attribute the outcome. Changing templates, content and addresses together means any change in performance has several plausible causes and no clean comparison. Sometimes the combined project is still cheaper than running two, in which case make it a deliberate choice, write down what you expect from each part beforehand, and keep the redirect map complete regardless.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.