What Is a Site Migration SEO Checklist?
A checklist for a migration is worth having for its sequence rather than its contents. Most failures are not things somebody forgot. They are things done in the wrong order, at a point where doing them was no longer useful, which is why this is organised by stage.
What A Checklist Is Actually For
Every item on a migration checklist is obvious in isolation. Record the old site. Map the addresses. Test the redirects. Nobody reads any of those and disagrees. The failures happen because of when they were done rather than whether.
The shape of a typical failure. Right task, wrong week.
The mapping is produced after the new site is finished, so the addresses are matched to whatever happens to exist. The benchmark is taken after launch, so it records the new site rather than the old one. Both tasks were completed. Neither was useful.
Why order matters more here than elsewhere. Some doors close.
Most project tasks can be done late at some cost. A few of these cannot be done late at all, because the thing they operate on has stopped existing. That is a different category of deadline.
What this page is and is not. Decisions, not commands.
Each stage below describes what has to be true at that point and who confirms it. It does not describe how to make any of it true, because that is the job of whoever is building. A checklist that turns into instructions gets used by somebody who should not be using it.
How to use it. Block ten.
Its highest value is as a shared document rather than a private one.
Before You Agree To Anything
Four things should be settled before a proposal is signed. All four are conversations rather than work, all considerably harder to raise once a project is underway.
What type of migration this is. Named explicitly.
Whether the domain is changing, the platform, the addresses, the design, the content, perhaps several of those. A proposal that does not say is a proposal nobody has read for this.
What is actually changing. Written down.
Specifically whether addresses will differ afterwards. If nobody can answer that at proposal stage, that is the first thing to resolve.
Who owns the search side. One named person.
Not a company, a person. This is the cheapest control available and the one most projects skip.
Whether it should happen at all. The uncomfortable one.
Some migrations solve a real problem. Others are a preference that has acquired a budget. That test is set out in when should you migrate a website.
Before Anything Is Built
This is the record stage. It is the one place on this page where being late is not recoverable at any price. Everything here depends on the current site still existing.
A full crawl. Every address and what is on it.
Not a list of pages from memory or from a menu. Everything that resolves, captured as it currently stands.
A performance benchmark. How the site does now.
Visibility, traffic by page and whatever the business actually counts. This is what recovery is measured against later. Without it, every later conversation is an exchange of impressions.
An inventory of addresses. Including the forgotten ones.
Old campaign addresses, superseded pages and the accumulated redirects from previous migrations. These are frequently the addresses carrying the oldest external links.
A record of what currently ranks. Page by page.
Which addresses carry the value, so that afterwards you know which to check first. The full treatment is in site audit before migration.
While It Is Being Built
Three things run alongside the build. Each is easier to influence now than after the build is finished, which is the argument for starting them early rather than treating them as pre-launch tasks.
The mapping. Started as soon as the crawl exists.
Building it now means the new structure can be shaped to preserve value. Building it later means matching old addresses to whatever the new site happens to have, which is a worse outcome reached by the same amount of work. The detail is in URL mapping for a site migration.
Staging protection. Confirmed to exist.
The site being built should not be discoverable. This matters twice. Once now, so it is not indexed, then again at launch, when the protection has to come off.
What the new build preserves. The check nobody runs.
Whether content survived, whether internal links point at final addresses and whether page-level markup came across. Content loss during a rebuild is the most common invisible cause of ranking loss. It is much cheaper to catch while pages are still being made than to argue about afterwards.
The Week Before Launch
Everything found this week is inexpensive to correct. Everything found the week after is not, which is what makes this the highest value week in the project.
Redirects tested against the map. Not sampled.
The map is a plan until it has been checked against what was actually built. On a site of any size, testing a handful of pages tells you almost nothing, because the failures cluster in the address types nobody thought about.
Staging protections confirmed. And confirmed again.
Established now so that removing them is a known task on launch day rather than something somebody remembers afterwards.
What the new site will tell crawlers. Checked before it says it.
The instructions the site gives about access and indexing, verified while it is still private and still changeable.
Who is watching afterwards. Agreed, not assumed.
Named people, named times, plus an agreement about what warrants acting rather than observing.
Launch Day
A short list of things that must be verified within hours of going live. These are the checks that separate an inconvenience from a disaster. Every one of them takes moments.
What the live site is telling crawlers. The first check, before anything else.
Whether access is blocked and whether the site is asking not to be indexed. Both are one line long, both make a perfect site invisible and neither produces any symptom a person looking at the site would notice. Our crawl and indexing guide covers why these two are the classic disasters.
Whether the redirects are behaving. On real addresses.
Testing against the live site rather than the staging one, because the environments can differ in ways nobody predicted.
Whether anything critical is broken. The obvious sweep.
Forms, checkout, search, contact routes. Visible failures are the ones customers report and the ones easiest to fix, so they are worth clearing quickly.
Why the timing is so tight. Discovery starts immediately.
Finding a blocking instruction within the hour is an inconvenience. Finding it three weeks later is a different conversation entirely.
The First Week
Four things belong in the first week. None is urgent in the way launch day is. They are the tasks that speed up everything that follows.
Notification. Telling the places that need telling.
Notification supports the process rather than triggering it, since the redirects are what actually communicate the move. It still accelerates things and it is quick.
Sitemaps. New ones submitted, old ones left in place for now.
The old addresses need to be revisited so their redirects are found, which is why deleting the old sitemap on day one is a small mistake with a slow cost.
Monitoring started. With the benchmark alongside.
Comparing against how the old site performed rather than against last month, which was a different site.
The first pass at errors. Whatever has surfaced.
Addresses that were missed, redirects pointing somewhere unintended and internal links still aimed at old addresses. Internal links are the cheapest of these to fix and the best return available this week.
The First Three Months
This heading describes how long somebody should still be paying attention. It is not a period by which anything is promised to have happened. It should not be presented to anybody as one.
What is actually happening. Gradual discovery.
Old addresses are revisited over time rather than all at once, redirects are found as that happens and the new addresses are assessed. Larger sites take longer simply because there is more to get through.
What to watch for. Shape rather than level.
Whether performance is declining, flat or returning. The direction is informative. A single reading on a single day is not.
Where the line sits. The judgement that matters.
A decline that stabilises and slowly returns is settling. One that deepens, else stays completely flat with no movement in either direction, is worth investigating rather than waiting out.
Why no period is given. It depends on the site.
Size, how much changed and how often the site is visited all move it. Anybody offering a fixed timescale is describing a different site. The shapes are set out in our guides on processing time and recovery.
What People Miss Most Often
These four account for a disproportionate share of the problems we see. Each is entirely preventable with the checklist above.
Internal links still pointing at old addresses. Hidden by the redirects.
The links work, so nobody notices. They are routing through a redirect they should not need, sitting within the site's own control to correct.
Content dropped in the rebuild. Invisible without the crawl.
Shorter pages and missing sections leave no error anywhere. This is why block three exists.
Staging protections shipped to live. The catastrophic one.
Covered on launch day for a reason. It is the single most damaging thing that can happen and the quickest to rule out.
Nobody watching after week two. The organisational one.
Attention ends before the effects appear. The catalogue of the rest is in common site migration mistakes.
Using This With A Developer
This checklist is most useful as a shared document between whoever builds the site and whoever is responsible for search. Handed over early, it prevents the argument that otherwise happens later.
Why sharing it works. It removes the ambiguity.
The gap described throughout this cluster is that each party assumes the other has search covered. A document both have seen turns that assumption into an allocation.
When to hand it over. At proposal stage.
Before the build is scoped, so the tasks are inside the quotation rather than requested afterwards as additions. A developer asked to test every redirect the week before launch, having not priced it, is being asked for a favour.
How it reads to a good developer. Helpfully.
Most are glad to be told what search actually needs, because the alternative is being blamed later for something nobody specified. A defensive reaction to a checklist is itself informative.
What it is not. A specification for doing the work.
It says what must be true, not how to achieve it. How belongs to whoever is building. The planning stage sits in how to plan a site migration. The full series is on the website migration guide.
Right task,
wrong week,
no use.
The stages worked in order because most failures are timing rather than omission, the record taken while the old site still exists, the two launch day checks done within the hour, the checklist shared with whoever builds at proposal stage, with nothing published that would let somebody attempt it unsupported.
What a migration engagement covers:
A migration is a one-off project rather than a monthly service, so it is scoped and quoted against the size of the site and how much is changing at once.
Every guide.
One practice.
What a migration is, the types, when to do it, planning, the checklist, auditing, mapping, redirects, internal links, tags, downtime, crawling, structured data, performance, notifying, monitoring, recovery and the mistakes.
