Site migration checklist: 13 items for a site that already ranks

In an audit of a 312-page recipe site, 239 pages changed category. Nobody in that project called it a migration. On most content platforms the category sits inside the URL, so what was described in the meeting as a cleanup was about to change 239 of 312 addresses, and no redirect map existed because nothing in the language of the project suggested one was needed. That is the shape of this problem, and it is why a migration is not a launch with more steps. It is a different kind of project, because this time there is something to lose.

Quick answer

• The redirect map is the project, not an item inside it. Every old URL gets a destination decided on its own, and the criterion is equivalent content rather than a similar-looking path.
• One variable per migration. Google's site move guide puts it in seven words: "Change only one thing at a time."
• The URLs with no equivalent are where the loss actually happens, and the size of that loss is knowable before anything moves. It is the sum of impressions on the rows whose destination cell is still empty.
• The first drop is expected and the recovery is not guaranteed. The most cited public measurement of recovery has been republished three times by the same author, and its average went from 229 days to 523 days as the sample grew.

What should a site migration checklist cover?

A site migration checklist covers what stops being possible once the old site comes down: the URL inventory with its impressions, the redirect map decided page by page, and a destination for URLs with no equivalent. A domain change adds verification of both Search Console properties; a CMS change adds canonical checks; a redesign keeping its URLs adds neither.

A migration is not a launch with extra steps

The model that produces most of the damage treats a migration as a launch with a redirect task bolted on the end. Under that model the right document is the launch checklist ordered by what cannot be undone, with redirects sitting somewhere around item three of fourteen, between the analytics tags and the sitemap. The list is not wrong. It is answering a different question.

A launch starts with an empty history. A migration starts with a full one, and the entire value of the operation is transfer rather than construction. What a domain accumulated over years does not live in the files that get copied. It lives in associations between specific URLs and specific queries, plus the links other people pointed at those exact addresses, and none of that moves by itself.

So the deliverable and the asset are two different things. The new site is the deliverable, and it is the easy half.

That reframing changes what a redirect is. It is not a sign saying the site moved. It is a claim of equivalence: this address answers what the other address answered. The claim can be false, and a false claim costs more than no claim at all, because a redirect to a page that does not answer the old query returns HTTP 200 and hides the loss behind a page that looks perfectly healthy.

Before: the six items that stop being possible

These depend on the old site still being reachable. Once it starts redirecting it no longer shows its own structure, and each of these six turns into an exercise in memory.

1. The inventory, taken as a fixed cohort

Every URL that brought impressions in the last twelve months, with its clicks, its impressions and its median position. The export takes minutes once the property is connected, and setting up Search Console is the prerequisite when it is not.

The word carrying the weight here is cohort. A screenshot of a dashboard is not a baseline, because in six weeks the comparison will run against a different set of queries and the mix alone will move the average. A frozen list of the queries that mattered on a stated date is a baseline. That difference decides whether the conversation after the migration is evidence or opinion.

One detail catches people who measure early: Search Console backfills for days after a period closes. On a site I operate, the seven-month total read 283,306 impressions when queried on 10 August 2026 and 298,019 when queried on 13 August 2026, a difference of five per cent on months that were already closed. Both figures were correct on their date. A migration week measured on day two moves under your feet.

2. A crawl of the old site, saved as a file

The Search Console export only contains URLs that earned impressions. The crawl contains the rest: the pages nobody found, the parameter variants, the paginated archives, the tag pages a plugin generated in 2019 that nobody has opened since.

Those pages carry almost no traffic and they are still part of the map, because some of them hold internal links and a few hold external ones. In the 312-page audit, 79 per cent of the internal links that existed were piled into the footer template, which means the link structure of that site was effectively one file. A replatform rewrites that file wholesale, and the links inside the prose are the ones that quietly keep pointing at the old addresses.

3. The redirect map, decided one URL at a time

Google's guidance here is unusually direct: "Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site." The reason is mechanical rather than punitive. The homepage does not answer the queries those URLs answered, so the equivalence being declared is false and the accumulated signal has nobody to inherit it.

What changes with scale is not the criterion. It is how many URLs get an individual decision:

• Under about 200 URLs. Every row gets a decision by hand, and the whole map fits in an afternoon.
• A few thousand. The rows carrying most impressions get hand decisions and the tail gets pattern rules. A rule is a hypothesis about equivalence, which is acceptable as long as a sample from each rule is opened and checked.
• Tens of thousands. Rules everywhere, hand decisions only on the tranche carrying the bulk of impressions, and the map declared as partial. Nobody reviews forty thousand rows, and a map that pretends otherwise is worse than one that states its own limits.

4. The URLs with no equivalent, which is where the loss lives

Almost no published checklist covers this, and it is the item that decides what a migration costs. Some old URLs have no counterpart on the new site. Not a hard one to find: none at all.

The documentation covers the case in one line, and the answer is not a redirect: "Provide errors for deleted or merged content, if you're not moving to the new site all your old content, make sure those URLs correctly return an HTTP 404 or 410 error response code on the new site." Sending them somewhere plausible instead is the failure this whole page is about, because it converts a visible loss into an invisible one.

Three situations hide under the same empty cell, and they are not the same decision:

• The content is being retired on purpose. A 410 is honest, and the impressions that URL brought are gone by choice. Choice is the operative word, and it belongs before the migration rather than after it.
• The content is being merged into a broader page. The redirect is correct only if the merged page actually contains what the old one answered. A merge that drops a section is a redirect to a page that cannot answer, dressed as a move.
• There is no equivalent yet, and there could be. This is the one nobody schedules, and it is the only one of the three where writing a page before the deploy changes the outcome.

The useful part is that this loss is measurable in advance. The inventory filtered to the rows with an empty destination, with their impressions added up, gives the price of the migration in the only currency that matters. Producing that number takes an hour. Most projects meet it eight weeks later, in the shape of an organic traffic drop nobody can explain.

5. One variable per migration

Google documents this and hardly any checklist repeats it: "Change only one thing at a time. Plan your changes to your site one after the other, not everything at the same time. For example, if you want to move your site to a new domain name, change your content management system (CMS), and update your site to use a new layout, do them one at a time: move to a new domain, then change your site's layout."

The cost of ignoring it is not a penalty. It is the loss of attribution. A site that changes domain, platform, template and URL structure in one deploy and then falls has four candidate causes plus every combination of them, and no stretch of its history where only one thing moved. The diagnosis turns into an argument between the people who built it and the people who paid for it, and arguments get settled by whoever sounds more certain rather than by evidence.

The interference runs deeper than rankings. A new template changes layout, image weight and script load, so the Core Web Vitals report in Search Console starts a new story on the same day the URLs change, and neither metric can then be used to explain the other.

Sequencing costs calendar time and buys certainty. Domain first with the structure held constant, then a wait for the history to settle, then the template.

6. Both properties verified, and what the change of address cannot do

The site move documentation asks for the old and the new site to be verified, including every variant: the www and non-www forms, and the HTTP and HTTPS forms where they exist. This item arrives late more often than anything else on the list, because the old domain is frequently verified inside the account of whoever built the site eight years ago, which is one of the reasons choosing who runs the work is a decision with a long tail.

The change of address tool has boundaries worth knowing before the plan is written. It works at domain level only, so a move from one path to another inside the same site cannot use it. It does not cover moving between www and non-www on the same domain, and it does not cover an HTTP to HTTPS change. Two of the three operations people commonly describe as migrations are therefore not change of address cases at all.

During: the four items whose deadline is hours, not weeks

Everything in this group is recoverable, and every day it stays wrong is a day of wrong pages in the index. On a site that is not migrating at all, the same items get ordered differently, by what the site can prove is costing something: the technical SEO checklist. None of the four announces itself.

7. One hop, to a page that returns 200

Each old URL resolves in a single redirect to a destination that answers 200, rather than to another redirect. Chains work for visitors and degrade for crawling, and the deeper problem is maintenance: a chain assembled across two migrations depends on rules nobody documented, and the day somebody prunes the oldest rule the middle of the chain disappears.

8. Canonicals and indexing directives, read on the served page

Two failures dominate this step and both return 200. The first is a canonical tag carried over with the old domain inside it, so the new page declares that the correct address is the old one, which redirects back to the new one. The second is the noindex from the staging environment travelling to production along with everything else. Neither produces an error anywhere, which is why they surface weeks later in the page indexing report rather than on launch day. The full catalogue of reasons a page stays out of the index sits in why a page is not indexed.

The check that catches both takes seconds and has to happen on the HTML the server returns, not in the admin panel.

9. Internal links rewritten, not left to the redirects

The site move guidance is explicit about this as well: "Internal links: based on the URL mapping you previously created, replace all URLs that pointed to your own pages." Redirects make the old links work, so nobody updates them, and the internal structure of the whole site ends up passing through an intermediate hop that survives at the mercy of a configuration file.

This is the item separating a migration that ends from one that never quite does. Link structure is worth more than most of what gets prioritised above it, which is the argument what SEO is and what it is for makes at length.

10. The sitemap, and the change of address itself

The sitemap lists new URLs and only new URLs. One that still carries the old structure teaches the wrong map at the exact moment the crawler is relearning the site. Filing the change of address, where the move is domain level, is a two-minute action with a documented effect: Google states that its actions continue for 180 days after the migration is started in Search Console.

After: the three items nobody schedules

A migration is a period rather than an event, and these three are what turn it into one. None of them has a due date.

11. Both curves at once

The documented instruction for the monitoring phase covers both sites: "Monitor how the user and crawler traffic changes on the new site and also the old site. Ideally the traffic on the old site will go down, while on the new site the traffic goes up." The crossing of those two lines is the observable progress of a migration, and it says more than any single number, because a new site rising while the old one holds steady means the redirects are not being followed.

12. The cohort, monthly, by median position

The comparison that answers the question is the frozen query list from item one, re-measured monthly rather than daily and judged by median position rather than average. An average moves on its own with the query mix, so a site can improve in every query that matters and still show a worse average.

One caveat applies to any baseline taken before 27 April 2026. Google recorded impressions, click-through rate and average position inaccurately between 13 May 2025 and that date, states that clicks were not affected, and does not correct historical data. A migration whose before and after straddle that boundary is comparing two recording regimes, so clicks are the column that survives the comparison intact.

13. The references you do not control

Redirects cover the links on your own site. They do not cover directory entries, marketplace profiles and citations carrying the old address as text rather than as a link, and those get updated one account at a time by whoever holds the password. For a business with a physical address the count runs into dozens, which is how local citations and NAP consistency becomes part of a domain migration whether or not anyone planned for it.

What the published numbers on recovery actually say

The figures circulating for traffic loss after a migration run from twenty to sixty per cent depending on who is selling the recovery, and none of the ones I checked traces back to a study with a stated sample. They are not measurements. They are the range of what sounds alarming enough to be repeated.

One measurement does have a methods section, and its history is more instructive than its headline. Dan Taylor has published the same analysis three times, each time with a larger sample, measuring how long a new domain took to reach the estimated organic traffic of the old one:

The average recovery time more than doubled between the first two iterations. Same author, same question, same method, and the number moved that far because the sample grew from 171 cases to 892. A figure that unstable under its own author's scrutiny is not one to quote as a forecast, and the version worth quoting is the median rather than the mean, because a distribution whose mean sits 185 days above its median is being dragged by its tail.

Two caveats belong with those rows. The sample is self-selected, drawn from migrations the author performed plus cases crowdsourced from the SEO community, so it is a sample of migrations people remembered well enough to submit. And the traffic figures come from third-party estimates rather than from Search Console, which means recovery there is defined against a model of traffic and not against the traffic itself.

What Google offers instead is a shape rather than a number: "For medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones (and for larger sites, even longer)."

When not to migrate at all

• When the problem is clicks and not positions. In that 312-page audit one page held position 1 for its query and took zero clicks, because the title Google displayed did not contain the name of the dish anyone was searching for. A new platform does not fix a title, and that repair belongs in the ordinary run of an SEO checklist for a business with no marketing team.
• When a core update is rolling out. Google confirmed two core updates in 2026, on 27 March with a rollout of 12 days and on 21 May with one of 11 days and 21 hours. A migration inside that window blends two causes that nobody separates afterwards.
• When nobody will own the redirects afterwards. The site move guidance asks for them to be kept "for as long as possible, generally at least 1 year", and a map retired early returns the site to where it started with the work already paid for.
• When the budget for the new site has eaten the budget for everything after it. The ongoing work produces the result, and what SEO actually costs a small business is the arithmetic deciding whether the migration was affordable in the first place.
• When the reason is that the current site feels dated. That is a legitimate reason to redesign and a poor reason to change addresses, and the two decisions are separable, which is the entire argument of item five.

Mistakes that repeat

• Treating the redirect map as one line on a checklist. It holds more decisions than anything else in the project, and the estimate that treats it as an afternoon is the estimate that fails.
• Redirecting the leftovers to the homepage. It converts a measurable loss into an invisible one, and each of those URLs starts returning a page that cannot answer the query that brought it.
• Changing domain, platform and template in one deploy. Four candidate causes, no attributable result, and a diagnosis that becomes an argument.
• Skipping the inventory because the site is small. Small sites migrate faster and lose the same proportion, and the inventory takes minutes precisely because the site is small.
• Leaving internal links pointing at the old URLs. The structure then depends on a redirect rule that somebody will eventually prune.
• Judging the outcome on a rolling average. The query mix moves the average by itself, so the number can fall while every query that matters improves.

Data and transparency

The quotations on redirect duration, one-to-one mapping, changing one thing at a time, error codes for removed content, internal link replacement and traffic monitoring come from Google's site move with URL changes documentation, opened on 5 September 2026. The 180 days of continued signal handling and the limits of the change of address tool come from its Search Console help page, opened the same day. The two pages give different minimums for how long to keep redirects, at least 180 days on one and generally at least a year on the other, and both are quoted here as written rather than reconciled into a single number.

The recovery figures are attributed to their publications by name, sample and date: 171 migrations in the 2023 study, 892 in the Search Engine Journal version of 8 January 2025 and 1,052 in the SALT.agency version of 26 June 2026. No percentage of traffic loss is asserted here, because the ranges in circulation do not name a study or a sample. One arithmetic note for anyone opening the 2026 version: its title says 27 per cent recover within 90 days, and the two buckets that would produce that figure add up to 23 per cent.

The audit figures come from my own 2026 work on a recipe site of 312 pages in WordPress. It is client work, so the site is not named and the numbers are rounded: 239 pages recategorised, 79 per cent of internal links concentrated in the footer, and one page at position 1 with zero clicks. The Search Console backfill comparison of 10 and 13 August 2026 and the data anomaly window of 13 May 2025 to 27 April 2026 come from Search Console itself and from its data anomalies page. The general criterion comes from audit work across a portfolio recording more than 300 million impressions a year in Google, on the sites I operate. Verified as of August 2026.

Primary sources, opened on 5 September 2026: Google's site move with URL changes documentation, the change of address help page and the Search Engine Journal migration study.

What this changes

The uncomfortable part of ordering a migration this way is that the expensive decisions all happen before anybody builds anything, and none of them look like work. An inventory is a spreadsheet. A destination column is a spreadsheet. The decision to move the domain this quarter and the template next quarter is one sentence in a document, and it is probably the most valuable thing on this page.

Meanwhile the visible half, the new site, is the part that gets the budget, the meetings and the approval. It is also the half that would have been fine either way.

So the question predicting the outcome is not how good the new site is. It is which URLs have an empty destination cell, how many impressions those rows add up to, and whether anybody has said out loud that the plan is to lose them.

Frequently asked questions