Website migration SEO checklist

I have moved and rebuilt sites in this shape, including work on leej.uk. The method is deliberately conservative. If you also need a reminder about URL shape, read the canonical tags and duplicate URLs guide before you draw the map.

Decide what ‘moved’ means, and what you will not change at the same time

Write down, in one sentence, what is changing, and what is frozen.

Examples of a single, honest change:

• Same URLs, new host or CDN, same HTML.
• Same host, HTTP to HTTPS (if you are late to that).
• Same host, new framework, paths kept.
• New path scheme on the same domain (trailing slashes, or /blog/ to /articles/).
• New domain, paths kept.

Examples of a bundle that is usually too much for one morning: a new domain, and a new CMS, and a redesign that removes half the pages, and a new trailing-slash policy, and a new robots file that also blocks AI crawlers. You can do a bundle, but you should treat it as a project with a map, a staging site, and a way to roll back the DNS or the redirects, not as a late-night switch.

Decide what you will not change until the move has settled: title patterns, the main navigation, the content of the important pages, the robots policy for Googlebot. If a page is going away for business reasons, that is a deletion with a 404 or 410, not a silent merge into the homepage.

If you are also changing what you allow training crawlers to do, do that as a documented step, not as a side effect of a new CDN preset, for the reasons in how to control AI crawlers.

Inventory: pages, assets, parameters and leftover files

You cannot redirect a URL you have forgotten. The inventory is the job most people skip, and the one that prevents “why is this old PDF still in the results, pointing at a 404”.

Collect:

• Every indexable HTML URL from the current sitemap, from a crawl of the public site, and from Search Console (pages that Google knows, including some the sitemap missed).
• Important non-HTML files that people or search engines still request: PDFs, images that rank, robots.txt, sitemap.xml, /llms.txt if you have it, apple-app-site-association, .well-known files, feeds.
• Redirects you already have. You will need to re-point or re-apply them so you do not create chains through a dead host.
• Parameterised URLs that are actually used, and a decision for each family (redirect, canonical, or drop).
• Leftovers: staging hosts, preview URLs, /test, old campaign landing pages, index.php leftovers. Decide whether they move, redirect, or stay behind as 410.

A crawl comparison later only works if you kept this list. Export it as a spreadsheet or a CSV, with the current status code, the title, and whether it is in the sitemap. That file is the source of the URL map; do not invent the map from memory or from the new navigation alone.

The URL map and the redirects that honour it

The map is a row for every inventoried URL that people or crawlers should still be able to resolve: old URL, new URL, type (301, 410, or “same”).

Rules that keep the map honest:

• One hop. The old URL should land on the final new URL, not on an intermediate that then redirects again. Re-apply old redirects on the new host, or collapse them in the map. The redirect chain tracer is the check; the redirect map builder is a way to draft the rows.
• Like for like. A page goes to its successor, not to the homepage, unless you truly have no successor and you are willing to drop the old URL’s meaning. Homepage redirects for everything are a classic way to turn a move into a soft 404 problem, as in the soft 404 guide.
• Files and feeds get rows too. A sitemap URL that 404s after a move is a self-inflicted crawl error.
• The new URL is in the published shape: HTTPS, the right host, the slash policy you chose, no tracking parameters.
• Deletions are explicit. 410 if you mean “gone for good”, 404 if you are unsure, and never a 200 with “not found” text.

Implement the redirects at the edge that will actually see the request: the new host, and, if the old host will remain up for a while, the old host too. A DNS-only move with no redirect plan only works if every path is unchanged and both hosts were already the same.

Test a sample, including a typo’d slash, an http URL, a www URL, and a leftover campaign path, before go-live, from a machine that is not already on the new host.

Canonicals, sitemaps and robots.txt on the new host

On the new site, before you point DNS or announce anything:

• Every public page has a self-referencing canonical in the new shape, not a leftover from the staging host, and not an old domain.
• The XML sitemap lists only new, 200, canonical URLs. Submit it once the name is live. A sitemap coverage diff against the crawl is the right check: URLs in the sitemap that 404, and important 200s missing from the sitemap, are both bugs.
• robots.txt allows the crawlers you intend to allow, including Googlebot, allows the sitemap, and does not accidentally Disallow: / because a framework shipped a default. If you have AI-crawler rules, they should be the policy you decided, copied carefully, not a vendor preset you have not read.
• llms.txt and any full text file, if you use them, should list the new URLs, as in the llms.txt guide.
• HTML head should not mention a staging host in canonicals, Open Graph URLs, or hreflang. A search-and-replace for the old host and the staging host, then a manual sample, is worth an hour.
• noindex should not still be on the production templates because it was on staging.

If the domain is new, you will also add the property in Search Console and any equivalent tools, verify it, and only then submit sitemaps. Do not add a Disallow “temporarily” on production to hide a launch; you will forget it.

Search Console, IndexNow and AI crawlers

Once the name is live (or just before, for things you can prepare):

• Verify the new host or domain in Google Search Console. If the domain changed, use the change-of-address tool where it still applies, and keep the old property available so you can read errors.
• Submit the new sitemap. Request indexing for a handful of important URLs if the tool offers it, without pretending that will recrawl the whole site in an hour.
• If you use IndexNow or a similar ping, send the important new URLs after they serve 200 on the public host, not against a hosts-file preview. A ping for a URL that still 404s or still shows a canonical to staging is worse than a delay.
• Confirm AI crawler and search crawler rules as in the crawler guide: Googlebot can read /, /robots.txt and /sitemap.xml; training rules are the ones you intended; a new CDN has not challenged the whole site.
• Set up the equivalent, if you use it, for Bing Webmaster Tools or any other engine you actually watch. One Search Console checkbox is not a complete picture.

Keep the old host answering redirects for a long time. I will not invent a number of months that fits every contract; for a small public site I would think in terms of years for the important 301s, not a week. The moment you switch the old host off, every forgotten URL becomes a dead citation.

The day-before and morning-of checks

The day before:

• The URL map is complete, including files, feeds and existing redirects, and someone else has sampled it.
• Redirects are deployed on a preview or a staging host that uses the same code path as production, and chains have been traced.
• A crawl of the staging or preview site, compared to the old crawl, shows expected successors and no unexpected 404s. Use a crawl comparison if you can.
• Canonicals, Open Graph URLs, sitemap entries and llms.txt use the public host, not the preview host. If the preview must stay noindex, that is fine; the templates for production must not.
• robots.txt has been read as a raw file, and Googlebot is allowed.
• Analytics, forms, and any Search Console verification files or DNS records for the new host are ready.
• A rollback is written down: DNS, a previous Worker or host version, or a way to put the old site back.

The morning of:

• DNS or the cut has been made, and from a network that is not your office wildcard, the public host serves the new site on the published URLs.
• A sample of old URLs, including http, www, a file, a campaign path and the homepage, land on the right new URLs in one hop.
• The homepage, a typical article, a tool or product page, robots.txt, sitemap.xml, and the 404 page all look and behave correctly.
• The sitemap is submitted. IndexNow, if you use it, has been pinged for the core set.
• Search Console URL inspection on a few key pages shows the live URL, the expected canonical, and no noindex.
• Forms, HTTPS, and the certificate (including the www or bare host you did not pick) work.
• You have watched the first hour of server or CDN logs for a spike of 404s that the map missed.

Do not launch on a Friday evening if you are the only person who can roll back. That is not an SEO rule, but it is how migrations become week-long incidents.

The first two weeks after go-live

The work is not over when the tweet goes out.

• Watch Search Console for crawl errors, a climb in 404s, “crawled — currently not indexed”, and unexpected noindex or canonical issues. Daily at first is not too often on a small site.
• Watch logs for old URLs that were not in the inventory. Add redirects for the ones that matter; do not do a bulk homepage dump.
• Re-crawl and run a coverage diff against the sitemap.
• Check that important backlinks and your own profiles (company listings, GitHub, App Store, directories you actually use) have been updated to the new published URLs, even though the 301s exist.
• Do not make a second large structural change in this window if you can help it. You will not know which change caused a drop.
• Keep the old property and the old redirects. A clean-looking new host without the old 301s is an unfinished move.

If traffic or impressions drop sharply on the important URLs, check the mechanical list first — robots, canonical to the wrong host, a challenge page, a sitemap of 404s, a slash policy that 404s — before you rewrite the content. Most emergency “SEO recoveries” after a move are a missed redirect or a noindex.

A printable checklist

Copy this, and tick it in the repo or on paper. It is the same work as above, in one place.

Plan

• One sentence for what is changing, and what is frozen until later.
• A rollback plan, and a person who can run it.
• A decision on robots, AI crawlers, and whether IndexNow will be used.

Inventory and map

• Crawl, sitemap and Search Console export merged into one inventory, including files and feeds.
• Existing redirects included and collapsed.
• A row for every important URL: 301, 410, or same path.
• No catch-all to the homepage unless a URL truly has no successor.

New host, before DNS

• Self-referencing canonicals on the published URLs.
• Sitemap of 200, canonical URLs only.
• robots.txt allows Googlebot and the sitemap; AI rules are deliberate.
• No staging host in canonicals, sitemaps, Open Graph or llms.txt.
• No leftover noindex on production templates.
• Redirects implemented and chain-tested, including http, www, slash and old paths.

Go-live and after

• Public DNS or cut checked from outside your network.
• Sample old URLs land in one hop; 404 page is a real 404.
• Search Console verified; sitemap submitted; IndexNow pinged if you use it.
• URL inspection on key pages looks right.
• Logs and Search Console watched for two weeks; missed URLs added to the map.
• Important inbound links you control updated; old 301s left in place.

Key takeaways

• Change as little as you can at once, and write down what is frozen. A migration plus a redesign plus a robots change is three projects.
• Inventory every important URL, including files, feeds and existing redirects, then map them one-to-one. Do not point everything at the homepage.
• Redirects should be a single hop to the published URL. Canonicals, sitemaps and llms.txt should use that same URL, never a staging host.
• Check Googlebot access, sitemaps, IndexNow and AI-crawler rules on purpose; a new CDN preset can undo them.
• Run a day-before and morning-of list, then watch Search Console and logs for at least two weeks. Keep the old 301s on for a long time.

If you want a second pair of eyes on a URL map before a move, tell me about it.

Frequently asked questions

Written by Lee Johnson. Published 10 November 2026.