Website Migration Checklist: 40 SEO Checks

A site move keeps its rankings when each old URL answers with one permanent redirect to its closest new page, the new site can be crawled and indexed, and you can prove both before and after the switch. The 40 checks below are in the order they need to happen, from the first crawl of the old site to the day you finally shut the old server down.

By Rai Ansar, who has completed 700+ website migrations with no downtime. Written 15 October 2026 and checked that day against Google's site-move documentation (last updated 20 August 2026).

Two files to take with you

  • redirect-map-template.csv: the redirect map with example rows for an exact match, a pattern rule, a merged page and a removed page.
  • check-redirects.sh: reads that CSV and checks every row against the live site. Needs only bash and curl.

The checklist below uses real checkboxes. Ticks are not saved when you leave the page, so print it or copy it into your project tracker.

What decides whether rankings survive

Google's own guide to moving a site comes down to five steps: review best practice, prepare and test the new site, build a mapping from old URLs to new ones, start the move by redirecting on the server, and monitor both sites. Four details from it do most of the work in practice.

  • Permanent redirects keep the signal. Google states that 301 and other permanent redirects don't cause a loss in PageRank. A 302 or 307 tells it to keep showing the source page.
  • Relevance beats convenience. Sending many old URLs to one unrelated page, usually the home page, risks them being treated as soft 404s. Pages that were merged can share a destination; pages that have no equivalent should answer 404 or 410.
  • Small and medium sites move all at once. Google recommends moving every URL together; only large sites should consider moving one section at a time.
  • Googlebot needs time. It has to visit every old and new URL at least once, and there is no fixed crawl frequency, so the pace is set by your URL count and server speed.

Phase 1: Before you build (checks 1 to 10)

Most migration damage is decided here, weeks before anything moves. Nothing in this phase touches the live site.

  1. Domain, platform, URL structure, design, copy. Google's advice is to change one thing at a time, for example the domain first and the layout later. If the project changes several at once, list them so you can tell afterwards which one moved your traffic.

  2. Google suggests a low-traffic window such as a seasonal or weekday dip. Look at your own clicks by weekday and by month in Search Console, and choose a day when someone who can fix a problem is at their desk.

  3. Export the Search Console Performance report by page and by query, and your analytics landing pages with conversions. Keep the files outside any account you might lose access to. Every "did the move work" question later is answered against these.

  4. The free version of Screaming Frog crawls up to 500 URLs; a licence (£199 a year at the time of writing) lifts the cap. Export URL, status code, indexability, title, H1, meta description, canonical, meta robots, word count and inlinks. This file is the "before" half of the crawl diff in check 14.

  5. One source is never enough. Merge the sitemap, the crawl, landing pages from analytics, recent server logs and the Links to your site report in Search Console. Include images, PDFs and downloads that earn visits or links.

  6. Sort the list by clicks and by referring domains and flag the top slice. Those rows get mapped by hand and are the first ones you test after launch.

  7. Four outcomes: kept as is, moved to a new URL, merged into another page, or removed. Google says content you are not moving should return 404 or 410, so removed pages go to the status column, not to the home page.

  8. One row per old URL, using the template and rules in the next section. This is the file you will test twice: once on staging and once on the live site.

  9. Filter the old crawl for 3xx responses. If /a already redirects to /b and your map sends /b to /c, visitors take two hops. Map /a straight to /c. Google follows up to 10 hops, but its advice is to go straight to the destination. If you can't, aim for three hops at most and stay under five.

  10. Verify every variant of the old and the new site (http and https, www and non-www) and pick a verification method that survives the move: a DNS record lives outside the web server and is the only method a Domain property accepts, while an HTML file or meta tag has to be carried over to the new server. For a domain change you need owner access to both properties from the same Google account.

The redirect map and how to test it

The map is a CSV with one row per old URL. These are the columns in the template:

Columns in redirect-map-template.csv
ColumnWhat goes in it
old_urlThe full old address as a visitor or crawler would request it, including the protocol and host.
new_urlThe final address, in the canonical form of the new site. Empty for 404 and 410 rows.
status301 or 308 for moved and merged pages; 410 or 404 for removed ones.
match_typeexact, pattern, merge or removed. Pattern rows record the rule in notes and are expanded to real URLs before testing.
clicks_12m, referring_domainsFrom Search Console and your backlink tool. They tell you which rows to hand-check and test first.
notesWhy the row looks the way it does.

Rules that keep the map testable:

  • Every old address variant is a row of its own, or is folded into the same rule: http and https, with and without www, with and without a trailing slash. Handle the host, protocol and slash in the same rule as the path, otherwise http://www.old.example/x/ takes three hops where one would do.
  • Choose the closest equivalent page. If the best match is a category rather than a product, use the category; do not default to the home page.
  • Query strings that change content (?id=42) need rows of their own. Tracking parameters usually don't.
  • Keep the file in version control next to the site, so the next rebuild cannot silently drop it.

Test every row with one command

Download the script, make it executable and point it at your CSV:

chmod +x check-redirects.sh
./check-redirects.sh redirect-map.csv

For a 301 or 308 row it checks that the first response is a permanent redirect, that the chain ends on new_url with a 200, and that it took no more than one hop. For a 410 or 404 row it checks the code and that nothing redirects. It exits with status 1 if any row fails, so it can sit in a CI job or a launch script. It does not read quoted fields, so keep commas out of the values.

On 15 October 2026 the script was run against this site with four rows: an existing redirect (/portfolio to /services, which answers 308), a path that should 404, one page that does not redirect and one that returns 404 where a 410 was planned. Output:

PASS https://migrateweb.com/portfolio
PASS https://migrateweb.com/ads
FAIL https://migrateweb.com/services  first-response=200(want 301);
FAIL https://migrateweb.com/nope  status=404(want 410);
---
passed 2, failed 2

A second run against a two-hop redirect on a public test server reported hops=2, which is the line you are looking for when a legacy rule is stacking on a new one.

Phase 2: Staging and pre-launch QA (checks 11 to 22)

The new site is built and sits on a staging address. The goal is to find every problem while nobody can see it, and to make sure the launch does not carry the staging settings into production.

  1. Google says robots.txt is not a mechanism for keeping a page out of Google, and that a disallowed page can still be indexed if other sites link to it. Use HTTP authentication or noindex. Test with curl -sI https://staging.example.com | head -1: you want 401, not 200.

  2. Google must be able to fetch a page to see its noindex. If robots.txt blocks the URL, the rule is never read. On a staging site that you protect with noindex (a meta tag or an X-Robots-Tag header), leave robots.txt open.

  3. Google tells you to prepare the final robots.txt and list every place a noindex must be removed at launch. On WordPress that includes Settings, Reading, "Discourage search engines from indexing this site", which adds a noindex robots meta tag when ticked. A missing robots.txt must answer 404, not an error page.

  4. Crawl staging with the same settings as check 4. Join the two exports on the mapped URL (old path to new path) and compare status, title, H1, meta description, canonical, word count and inlinks. A lost title or a page that lost most of its text should be a decision, not a surprise.

  5. The canonical must point at the new, final URL on the production host. Search the staging crawl for canonicals that still name the staging host or the old domain; one template mistake multiplies across thousands of pages.

  6. Skip this if the site is in one language. Otherwise every annotation, including the return links, has to name the new URLs, as Google's site-move guide specifies.

  7. Navigation, body links, breadcrumbs and the sitemap should use the new addresses so no internal click goes through a redirect. In the staging crawl, filter inlinks by status: the count of internal links to a 3xx or to the old host should be zero.

  8. Titles, meta descriptions, Open Graph tags and JSON-LD are the first things a theme or platform change drops. Use the crawl's custom extraction, or view source on one page of each template.

  9. Images, PDFs and other downloads that earn traffic or links must answer 200 at their new address and appear in the redirect map. Google lists images and downloads among the things to move.

  10. One sitemap of the new, canonical, 200 URLs, using the new host in every <loc>. Do not include redirected, noindexed or canonicalised-away URLs.

  11. Load the map into the redirect rules on the new server, point the old hostname at that server in your hosts file (you need a certificate for the old name there), and run the script from the next section. Every FAIL line is a defect you found for free.

  12. Google suggests a conservative low value, a few hours, at least a week before the move, so the new records reach resolvers quickly. See what is set now with dig +noall +answer example.com A @your-nameserver: the number after the name is the TTL in seconds.

Phase 3: Cutover day (checks 23 to 31)

Work through these in order and write down the time of each step. Keep the old server running; it is your rollback.

  1. Files and database, tested for restore on a scratch server if the site is large. Write down, in one sentence, what would make you roll back (for example "the new site answers 5xx on checkout") before anyone is under pressure.

  2. With a low TTL, resolvers pick up the new records sooner. Google notes that traffic in your logs moves gradually from the old servers to the new ones, so watch both. If you are changing name servers or DNS host, copy every record the new zone does not already hold before you flip: MX, the SPF and DKIM TXT records, verification TXT records and any CNAMEs. A missed MX record takes email down, and nobody notices until the first message bounces.

  3. Use 301 or 308 from the server or CDN. Google says a server-side redirect has the highest chance of being read correctly, and treats an instant meta refresh as permanent but a JavaScript redirect as the last resort. Send all four host variants (http and https, www and non-www) to the one final address in a single hop. Do the home page first and load it in a private window to rule out a loop.

  4. Password, noindex tag or header, robots.txt disallow, the CMS "discourage search engines" box. Verify on five live URLs with curl -sI (no X-Robots-Tag), by viewing source (no robots meta) and by opening /robots.txt.

  5. The full file, not a sample. Fix every FAIL before you step away from the desk, and re-run until the last line reads failed 0.

  6. Status 200, self-referencing canonical, title, H1, structured data and a valid certificate. Open the browser console on each: a mixed-content message means a script, stylesheet or font still loads over http://, and browsers block those requests, so the page can look fine on your machine and break for visitors. Run Search Console's URL Inspection live test on the home page and one deep page to confirm Googlebot can fetch them and that no firewall rule is blocking it.

  7. Keep the old sitemap submitted for now. Google advises submitting both: indexing of old URLs should fall while the new ones rise, and redirect warnings on the old sitemap can be ignored.

  8. Do it after the redirects are live, for every old variant of the domain, including ones you never used. It does not apply to http-to-https, www changes or path restructuring.

  9. Social profiles, the final URLs in paid ad campaigns, email signatures, business listings and partner pages. Google suggests starting with external links that bring the most visits.

Phase 4: After launch (checks 32 to 40)

Google says a medium-sized site can take a few weeks or more for the new URLs to replace the old ones. A dip in week one is normal; the checks below separate a dip from a defect. Checks 32 to 38 run over the first month; checks 39 and 40 are the long tail, a year and until the old host goes quiet.

  1. Filter the old and the new server logs by the Googlebot user agent. You should see old URLs answered with 301 or 308 and the targets answered with 200. A burst of 5xx or 403 responses to Googlebot is the one thing worth escalating the same day.

  2. Look for new reasons, not new totals: "URL blocked by robots.txt", "URL marked ‘noindex’", "Not found (404)", "Redirect error". "Discovered - currently not indexed" means Google has the URL but has not crawled it yet; on a freshly moved site that is expected for a while.

  3. Same settings as checks 4 and 14. Targets: every internal link goes to a 200 URL, redirect chains are one hop at most, and every canonical points at a 200 page.

  4. Take the rows you flagged in check 6, sum the old and new addresses if the domain changed, and compare with the same weekdays before the move. Decide in advance what size of drop, held for how long, would make you investigate.

  5. Search Console and the logs show which old URLs still receive requests. If one has visits or links and returns 404, add a row to the map and redirect it to its closest equivalent.

  6. Submit a real form, run a test purchase, trigger each key event and see it arrive in analytics. Compare the weekly conversion count with the benchmark from check 3.

  7. A redirect passes the signal, and Google says 301 and other permanent redirects don't cause a loss in PageRank, but a link that points straight at the new URL saves a hop for every visitor. Start with the referring domains you flagged in check 6.

  8. Google says to keep redirects for as long as possible, generally at least one year, and the Change of Address tool's effects last 180 days. Renew the old domain and keep the redirect rules in version control so a later site rebuild does not drop them.

  9. Google's guidance for host moves is to wait until traffic to the old servers reaches zero. Then write a one-page summary: what moved, what was removed, the before and after numbers, and the open issues. That page is what you hand to the next person.

Which kind of move is yours

Not every project needs every step. Google's documentation treats these moves differently:

What each type of move needs, per Google's documentation
MoveURL redirectsChange of Address tool
Same URLs, new host or CDNNone neededNo
http to httpsYesNo, Google works it out
www to non-www (or back)Redirects and/or canonical tagsNo
URL structure changes on the same domainYes, plus updated sitemapsNo
New domain or subdomainYes, page to pageYes, after redirects are live

A move with no URL changes skips the redirect map entirely; its checklist is checks 11 to 13, 22 to 24, 26, 28, 32, 33 and 40.

Questions people ask

How long do rankings take to settle after a migration?
Google's site-move guide says it can take a few weeks or more for a medium-sized site before the new URLs replace the old ones, and longer for larger sites. Speed depends on the number of URLs and how fast your server responds. Temporary fluctuation is normal.
301 or 302 for a site move?
Use a permanent redirect, 301 or 308. Google says it uses a permanent redirect as a signal that the target should be the canonical URL and shows the new URL in results, while a temporary redirect keeps showing the source page.
How long should the redirects stay?
Google's site-move guide says as long as possible, generally at least a year, and to consider keeping them indefinitely for users. If you used Change of Address, keep them at least the 180 days the tool runs, longer if Google Search still sends visitors through them.
Do I need Change of Address if I only change hosts?
No. The tool is for moving between domains or subdomains. Changing host or CDN without changing URLs, http to https, www to non-www and path restructuring on the same domain are all handled with redirects, canonicals and sitemaps.

Have it run for you

MigrateWeb does this work for a fixed price: the URL inventory, the redirect map, staging QA, the cutover and a check after launch. Tell us the platform you are leaving, where it is going and roughly how many pages it has, and we reply with a quote within one business day.

Get a fixed-price quoteSee the website migration service

Sources