Website migration SEO checklist

Short answer. Inventory every URL that exists, ranks or has links. Map each one to its new equivalent and redirect it with a single server-side 301 or 308, directly to the final page. Keep the content the same on launch day; improve it later. If the domain changes, verify both properties in Search Console and use the Change of Address tool. Submit the new sitemap, keep the redirects for at least a year, and watch Search Console weekly for twelve weeks. Details and sources below.

What counts as a migration, and what each one needs

The word covers six different projects. Decide which you are doing before you plan anything, because the tooling differs.

Mixing two of these in one launch doubles the number of things that can go wrong and halves your ability to see which one did. Google’s guidance for small and medium sites is to move all URLs at the same time rather than one section at a time; large sites can move in sections to make problems easier to find. Either way, do not combine a domain change with a redesign and a new CMS in one weekend if you can avoid it.

Before: the inventory

A migration is a mapping exercise, so the inventory is the project. You need the complete list of URLs that exist today, from every source, because each source finds URLs the others miss.

1. A full crawl of the live site, following internal links, including images, PDFs and paginated pages.
2. Every URL in your XML sitemaps.
3. Search Console: the Performance report’s pages (everything that received an impression in the longest range available) and the Page indexing report’s indexed list.
4. Analytics: every landing page with a session in the last year.
5. The Links report in Search Console: every URL other sites link to. These carry the most value and must be mapped by hand.
6. Server logs if you can get them: URLs Googlebot requests that you have forgotten exist, including old campaign pages and parameter variants.

Deduplicate the union of those lists. The result is the left-hand column of your redirect map. Record for each URL its clicks, its impressions, its inbound links and whether it is indexed, so you can prioritise and so you can measure afterwards. The baseline steps in the redesign checklist cover the same ground from the content side.

The redirect map

One row per old URL, with its new URL. The rules come from Google’s redirect documentation and its site move guidance:

Build the map in a spreadsheet, then turn it into configuration (server rules, a platform’s redirect manager, or a middleware file) and test it with a script that requests every old URL and records the status chain. Clicking a few links is not a test. Update internal links to point at the new URLs directly, so your own site is not relying on its own redirects; Google’s site move guidance notes redirects slow users down, and the fewer the better.

Get your free SEO auditMigrating soon? The free SEO audit gives you a baseline of what ranks and which URLs carry links, written by a person within two working days.

Platform specifics: Shopify, WordPress and headless

Moving to Shopify

Shopify fixes the top-level paths: products live under /products/, categories under /collections/, static pages under /pages/ and posts under /blogs/. A WooCommerce store with /shop/blue-widget/ cannot keep that URL, so every product, category and post needs a mapped redirect. Shopify’s redirect manager handles one-to-one rules; build the full list before you import a single product. Our ecommerce SEO service runs these moves with the map as the first deliverable.

Moving to or within WordPress

Permalink settings decide the whole URL structure in one click, which is the danger. Match the old structure where you can, decide trailing-slash behaviour once, and check that category and tag archives, author pages and attachment pages either match the old site or are redirected or set to noindex deliberately.

Moving to a headless or static build

Content is rendered at build time or by a framework, so check that the HTML Google receives contains the text and links, that trailing slashes and casing match the map, and that the redirect rules live in the hosting layer where they return proper status codes. This site is built that way, and its redirect map is a versioned file checked on every build.

Moving hosts only

No URLs change, so no redirects. Google’s guidance for moves without URL changes is to test a copy of the site on the new host, verify that Googlebot can reach it (firewalls and denial-of-service protection are the usual blockers), lower your DNS TTL in advance, switch, monitor both servers’ logs, and keep the old host running until traffic has moved.

Search Console and the Change of Address tool

For a domain or subdomain change, Google provides a tool that tells it to prefer the new site and to forward signals. Its requirements, from the Change of Address help page: both the old and new sites must be verified properties, the old home page must redirect to the new one with a permanent redirect, and the tool moves all protocol and host variants of the source, so verify each of them. Once submitted, Search Console shows a move-in-progress notice on the affected properties for 180 days, and the forwarding of signals continues for 180 days after you start the migration.

Google is explicit that the tool is not needed for HTTP-to-HTTPS moves or for www changes, and it does nothing for a platform change on the same domain. For those, the redirects and a fresh sitemap do the work.

• Keep the old property verified for at least a year; you will need it to read the redirect errors and to see traffic draining.
• Submit a new sitemap containing only new URLs on the new property, then remove the old sitemap after launch; Google’s site move guidance describes this sequence.
• Use URL Inspection on the top twenty new URLs to confirm they are indexable and render correctly.
• Watch the Page indexing report on both properties: redirects should rise on the old one and indexed pages on the new.

The launch sequence

Launch midweek, in the morning, with the developer, the SEO owner and whoever controls DNS all available for the rest of the day. Change nothing about the content on launch day: a migration is a move, and every improvement you bundle with it hides the cause of any drop.

1. Freeze content on the old site 48 hours before. Run the final crawl and export it as the launch baseline.
2. Deploy the new site with noindex and password protection still on. Run the redirect test script against the staging host.
3. Lower DNS TTL in advance if the host changes.
4. Switch: DNS, then remove password protection and the noindex rule. Read the live robots.txt in a browser.
5. Run the redirect script against the live domain. Fix any 404, chain or loop before anything else.
6. Check canonicals on twenty pages: self-referencing, on the new domain and protocol.
7. Submit the new sitemap. For a domain change, submit the Change of Address.
8. URL Inspection on the top twenty pages; request indexing for the home page and the top five.
9. Confirm analytics, consent and conversion tracking on a test enquiry or order.
10. Run a full crawl of the new site and diff it against the baseline: titles, H1s, word counts, status codes, internal link counts, structured data (the schema guide lists what to check).
11. Write the launch time in the shared log. Annotate every chart with it.

The twelve-week watch list

Google’s own expectation is that for a medium-sized site it can take a few weeks or more for the new URLs to be gradually shown, with larger sites taking longer and no fixed crawl frequency. Plan twelve weeks of weekly checks and judge the move at the end, not after a nervous Friday.

The pattern to fear is a specific one: a group of pages whose impressions fall while everything else transfers. That is a mapping fault (the redirect goes to the wrong place or is temporary), a parity fault (the new page lost the content that answered the query) or a technical fault (the template is blocked or broken). Check in that order.

When to get help, and what help should look like

A migration is one of the few SEO projects with a fixed deadline and a binary outcome, which is why it is worth paying for if your site is large, your URLs are changing or the platform is new to your team. Our SEO migration service delivers the inventory, the map, the test scripts and the twelve-week watch as a defined project, and it works alongside whichever developer is building the new site. Whoever you use, ask for the redirect map and the test results as deliverables, not for a promise that "rankings will be fine". Not ready to talk? Score your own site in five minutes before and after the move.