SEO migration checklist

1 Before anything moves: write down what you have

A migration you cannot measure afterwards cannot be judged, and most of the traffic lost in migrations is lost from pages nobody remembered owning. This is the record everything else is checked against.

• Export every URL with impressions from Search Console for the last sixteen months, with its clicks and impressions. This is the list of pages that earn, and it is longer than anyone expects.
• Crawl the whole live site and keep the crawl. It is the only complete record of the URLs, titles, headings, canonicals and internal links you are about to replace.
• Pull the URLs from the server logs as well. Pages that Google still visits but that nothing links to any more only show up here.
• List the pages with backlinks, from the links report in Search Console or a backlink tool. A linked page that is dropped or redirected badly loses value that took years to earn.
• Record the title, meta description, H1, canonical and structured data of every template, so the new site can be compared against it rather than written from memory.
• Take a baseline of speed on real templates over a phone connection, so a slower new site is caught rather than blamed on Google.
• Note every redirect that already exists from earlier migrations. Those old URLs still get crawled and linked, and a new site that forgets them breaks links that were fixed years ago.
• Take a full backup of the old site and its database and keep it somewhere the new one cannot overwrite. Content that was quietly dropped is recoverable only from here.

2 Decide what changes, and change as little as you can

Every change is a risk on its own, and changes compound. The migrations that lose the most move domain, platform, design and URL structure on the same afternoon, so nothing can be blamed for the loss and nothing can be undone alone.

• Keep the URLs if there is any way to. A page that keeps its address keeps its history; a redirect, however good, is a request to Google to transfer that history.
• If URLs must change, decide the new pattern once and write it down: trailing slash or not, lower case, hyphens, and how dates and categories appear. Inconsistency here produces duplicate pages for years.
• Do not change the domain and the platform at the same time unless there is no choice. Do one, let it settle for a few months, then the other, so any loss has one cause.
• Decide, page by page, what is kept, merged or dropped. Merged pages redirect to the page that absorbed them; dropped pages with no equivalent get a 410, not a redirect to the home page.
• Keep the content. A redesign that halves the words on a page halves what it can rank for, and headings that become styled text stop being headings to Google.
• Keep the internal links. New navigation designs routinely drop the links that made the deep pages findable, and those pages lose rankings without a single URL changing.
• Check the new platform can do what the plan needs before committing to it: server-side permanent redirects, editable titles and canonicals, a clean sitemap, and control over robots.txt.
• Keep the image URLs where you can, or map them too. Images that move without redirects lose image search traffic and break every link to a picture.

3 The redirect map, one line per old URL

The redirect map is the migration. Everything else is preparation for it or checking of it, and the faults that empty a site of traffic are almost always in this one file.

• Every URL from the record gets a line: old URL, new URL, or 410. No URL is left to be handled later.
• Each redirect goes to the page that answers the same need, not to the home page and not to a category. Google treats a redirect to an unrelated page as a soft 404, which is the same as no redirect.
• Use permanent redirects done by the server. A temporary redirect, a JavaScript redirect or a meta refresh may pass nothing.
• No chains. If an old URL already redirected somewhere, point it straight at the final destination; every hop leaks a little and long chains are abandoned by the crawler.
• Carry every existing redirect forward. The URLs from the migration before this one still get traffic and links, and dropping their rules breaks them again.
• Handle the variants: http and https, www and bare, upper and lower case, with and without a trailing slash, and parameter URLs that were indexed. Each can be a separate old URL as far as Google is concerned.
• Test every destination in the map against the new build before launch. A redirect pointing at a page that does not exist on the new site is the single commonest fault, and it is worse than no redirect at all.
• Keep the map in version control, or at least in a dated file. In six months, when a page is missing, the map is how you find out what was supposed to happen to it.

4 Staging: the new site before anybody can see it

The new site is checked while it is still private, against the record and against the map. Everything found here is cheap to fix; everything found after launch is not.

• Keep staging out of the index with a noindex header and, better, a password. The danger is not a staging site that is blocked; it is forgetting to unblock it on launch, which is why the launch list starts with that.
• Compare titles, descriptions, H1s and canonicals template by template against the record. A template writing the brand name as every title is the fault that most often ships.
• Compare word counts per page between old and new. A page that lost half its text lost it for a reason somebody should be able to name.
• Check every canonical points at the page itself on the new site, not at the staging domain and not at the old one. A canonical to staging tells Google the real site is the copy nobody can reach.
• Run the redirect map against staging: every old URL, its expected destination, its expected status. Do it with a script, because a map of a thousand lines cannot be tested by clicking.
• Check internal links point at the new URLs directly, not at old URLs that will redirect. Links through redirects work, but they waste crawl and they are how chains begin.
• Check structured data validates and describes what is on the page, and that the sitemap the new platform generates contains only pages that should be indexed.
• Run the full SEO audit checklist on staging. It was written for exactly this: a site that has never been checked, in the order that finds the expensive faults first.
• Check speed on staging against the baseline. A new site that is slower on a phone than the old one is a loss you will otherwise attribute to the migration itself.

5 Launch day

The switch is an afternoon and the checks are an hour, and both are done by somebody who is watching rather than somebody relieved it is over.

• Remove the noindex, the password and any robots.txt block from the new site as the first act of launch, and confirm by fetching a page and reading the headers rather than by remembering.
• Put the redirect map live in the same deployment as the new site. An hour of old URLs returning 404 while the redirects are uploaded is an hour of Google recording that the pages are gone.
• Fetch a sample of old URLs from the record and confirm each answers with a single permanent redirect to the expected destination, which answers 200.
• Check robots.txt, the sitemap and the canonicals on the live site itself. Staging was right; live is what counts.
• Submit the new sitemap in Search Console, and leave the old sitemap in place for a few weeks so Google crawls the old URLs and finds the redirects sooner.
• If the domain changed, verify the new domain in Search Console and use the Change of Address tool. It only works while the old domain is still verified and redirecting, so do not let the old domain lapse.
• Check that the analytics tag fires once per page and that forms, phone links and booking buttons work. A migration that ranks and cannot take an enquiry has still failed.
• Watch the server error log and the 404 log for the rest of the day. The URLs nobody knew about announce themselves here within hours.

6 The first fortnight

A migration that loses traffic usually shows it within days, and the sites that never recover are the ones where nobody looked until the month-end report.

• Check Search Console coverage daily: pages indexed, pages excluded and why, and the redirect and not-found errors. A rising not-found count is the map missing lines.
• Compare impressions per URL against the record, weekly at first. The pages that fell are the pages to look at; the total hides them.
• Fix every 404 the log reveals by adding a line to the map, and fix every chain by pointing the first hop at the end.
• Update the links you control to the new URLs: the Google Business Profile website link, social profiles, email signatures, directories, and any campaigns that point at old addresses.
• Ask the sites that link to your most valuable pages to update their links. Most will not, which is why the redirects stay forever, but the ones that do pass the full value.
• Check Core Web Vitals in Search Console once it has enough data. A slower site shows up here first, and it costs rankings independently of the migration.
• Keep the old domain and hosting alive and redirecting. Letting it expire to save a small fee is how a migration that worked loses everything a year later.

7 Ninety days on: deciding whether it worked

A dip of a few weeks is normal while Google re-crawls and reassigns history. A loss that is still there after three months is a fault, and it is usually one of three.

• Compare clicks and impressions per URL group against the record for the same period last year, not against the month before launch, so seasonality is not mistaken for damage.
• Where a page lost traffic, check its redirect first, then whether its content survived, then whether its internal links did. Those three explain nearly every loss, in that order.
• Where a page is not indexed at all, check for a leftover noindex, a canonical pointing elsewhere or a robots.txt line. Each is a minute to fix and can hide for months.
• Do not remove the redirects. Not after a year, not after five. Old links and old bookmarks do not expire, and the day the map is dropped is the day they all break.
• Write the record for next time: what moved, what was mapped, what broke and how it was found. The next migration is easier only if this one was written down.

Protecting what you build

Getting the visibility is the half everybody sells. Keeping it is the half that decides whether businesses still have customers arriving from Google in three years, and almost nobody writes it down, so here it is.

A migration is the single most common way a healthy site loses its enquiries in a fortnight, and the loss is permanent when nobody is watching the fortnight after.

What actually breaks a business in search

Not usually an algorithm update, whatever the industry press implies. Core updates move positions; these remove you.

What to refuse, however it is sold to you

Every one of these still gets sold, usually by email, usually cheaply, and usually to somebody who does not know it is being done in their name. All of them work for a while.

• Bought links, in any packaging

  Guest post networks, paid directories that exist only to sell links, anything offered by email with a price per link. These are the clearest thing Google acts on manually, the action can arrive years later, and recovery means removing what you paid for and then waiting.

• Reviews you did not earn

  Bought, incentivised, written by staff, or traded with another business. Google removes them, and where the pattern is obvious it suspends the listing rather than the reviews. It is also the one that damages you with customers if it is ever visible.

• Keywords stuffed into the business name

  It moves the map pack for a while, which is exactly why it keeps being sold. It is also the single most common cause of a suspension, and the suspension takes the whole listing rather than the extra words.

• Pages written to have pages

  A page per town you have never worked in, a page per service you do not offer, content generated to fill a content calendar. It does not rank and it drags down what would have.

• Anybody who guarantees a position

  Nobody controls Google’s results. A guarantee means either the terms are meaningless or the method is one of the four above.

The monthly discipline

Twenty minutes a month, and it is the difference between noticing a problem in week one and noticing it in month six.

• Check Search Console coverage once a month and look at the Excluded reasons, not just the errors.
• Watch impressions rather than clicks. Impressions fall first, usually weeks before anybody notices the phone is quieter.
• Open the Business Profile and look for edits the public has suggested and Google has accepted without telling you.
• Reply to every review that arrived since last month, and keep asking, steadily rather than in bursts.
• Before any site change, write down what the URLs are now. After it, check they still resolve.
• Keep one note of what changed and when. Almost every traffic mystery is solved by a change nobody wrote down.
• Re-run the audit checklist once a year, and the first two sections after any redesign, host move or new plugin.

Own your own accounts

The domain, the hosting, the Google Business Profile, Search Console and Analytics should all be registered in the business’s name with the business’s own email, and anybody working on them should have access granted rather than ownership transferred. It costs nothing to set up that way and it is close to impossible to unwind afterwards. If any of those are currently in somebody else’s name, that is worth fixing this week whether or not anything is wrong.

This site is a migration

The site you are reading moved from WordPress to a static build in September 2026. Every old URL was inventoried from Search Console and the server, given a destination or an honest 410, and the build refuses to finish if any redirect points at a page that does not exist. That last rule exists because the fault it catches is the one this checklist warns about most.

Using this as a template

Copy the seven headings into a sheet, one row per step, with a column for who owns it and a column for the evidence: the export, the crawl file, the tested map, the header you fetched. A migration plan without evidence is a list of intentions, and the evidence is what settles the argument when traffic moves.

If you would rather it was done for you

The same list, run by us alongside your developers, with the redirect map and the testing as our responsibility and the record handed over whether or not you go on to anything else. Scoped on a call before anything starts.

• SEO migration services
• Technical SEO services
• SEO audit checklist
• All guides