A website migration SEO checklist should tell you what to test, what a pass looks like and who decides whether the move can go live. A list of “check redirects” and “submit sitemap” is too vague when a catalogue, domain or content structure is changing.
Discuss your projectSee selected work
This guide includes a practical launch register, a worked URL-mapping example and a way to separate launch blockers from issues that can be monitored afterwards. It is a planning aid, not a promise that rankings will stay unchanged.
The short version
When a site moves, every page that matters needs a plan. List each old address. Say where it should go. Then test that it really goes there after launch. That is most of the job.
Some problems must stop the launch. Others can be fixed in the first week. Decide which is which before the day, and agree who makes the call. This guide gives you a simple table to do that, plus a worked example.
Start with the type of move
A hosting move with unchanged URLs, a redesign and a platform migration have different risks. Write down what changes: hostname, protocol, paths, page templates, content, navigation, rendering or checkout. Avoid changing everything together where a staged release is possible; it makes diagnosis easier.
For ecommerce, protect the pages that connect search intent to the buying journey: collections, product families, individual products and useful guides. Also preserve the images, downloads and specifications that customers and search engines already rely on.
The migration register: one row per important old URL
Combine a crawl of the old site with the sitemap, Search Console landing pages, analytics landing pages and known linked URLs. A crawl alone misses orphan pages. Save the exports with a date before the move so you have a baseline.
| Field | What to record |
|---|---|
| Old URL | The complete live address, including the hostname. |
| Destination | The intended new canonical URL, or an explicit removal decision. |
| Intent and priority | What the visitor needs; whether this is a critical revenue, enquiry or linked page. |
| Expected response | Unchanged 200; permanent redirect to a relevant destination; or intentional 404/410 where there is no replacement. |
| Observed result | First response, redirect hops, final status and final URL. |
| Indexing signals | Final page robots directive, canonical target and sitemap inclusion. |
| Evidence and owner | Test date, screenshot or crawl row, responsible person and release decision. |
A worked mapping example
Imagine a furniture shop moving an oak table from /shop/tables/oak-120 to /products/oak-dining-table. The old page should lead directly to the new product if it serves the same customer need. The product’s internal links and sitemap should use the new address, and its canonical should agree.
If that table has been discontinued, a similar product is not automatically a good replacement. Check dimensions, purpose and availability. A close match or a useful category page can make sense. Sending every old product to the homepage hides the gap and annoys customers. Write down why each redirect goes where it does. “A redirect exists” is not a pass on its own.
old_url,new_url,decision,priority,owner,tested_on,result,evidence https://example.com/shop/tables/oak-120,https://example.com/products/oak-dining-table,permanent_redirect,critical,developer,,pending, https://example.com/guides/table-sizing,https://example.com/guides/table-sizing,keep,high,content_owner,,pending, https://example.com/shop/retired-part,,intentional_removal,normal,catalogue_owner,,pending,
Copy those columns into your own spreadsheet. The example is fictional; it is a template, not evidence from a client migration.
Before launch: test the destination
- Content parity. Compare titles, headings, descriptions, specifications and useful media for priority pages. A URL mapping cannot replace missing information.
- Rendered content. Check that key text and links show up on the finished page, including templates that rely on JavaScript.
- Canonical agreement. Check the final page points to the intended production URL, rather than staging, an old hostname or an unrelated product.
- Indexability. Keep the staging site locked while you build. Plan how you will remove any temporary noindex tags and crawl blocks when the new site goes live.
- Internal navigation. Crawl menus, breadcrumbs, pagination and related products. Links should reach final destinations without needless redirect chains.
- Operational checks. Test contact forms or checkout, stock, price, tax and order notifications separately from SEO.
The launch-day acceptance register
Assign an owner and capture evidence for each row. My suggested release criteria below are a practical starting point; agree the final criteria with your team before launch.
| Test | Suggested pass condition | Decision |
|---|---|---|
| Critical URL routes | Every agreed critical old URL reaches its relevant final destination; no loops or broken targets. | Block launch if failed |
| Production indexing | Priority pages are accessible, indexable and use production canonicals. | Block launch if failed |
| Buying or enquiry journey | A complete test submission or test order reaches the right operational destination. | Block launch if failed |
| Internal links and sitemap | Priority links and submitted sitemap URLs use the final canonical addresses. | Fix or document before release |
| Analytics continuity | Known test visits and key events can be verified without counting them as real sales. | Investigate before comparing results |
| Non-critical retired URLs | Removal decisions are deliberate, documented and absent from the new sitemap. | Monitor after release |
After launch: compare like with like
Repeat the redirect and indexability crawl immediately on production. Inspect priority destinations in Search Console, submit the new sitemap and monitor errors. A new site can look correct in a browser while its canonical or robots signals are wrong.
Track clicks and impressions by page group, search term and device, next to enquiries or sales. Mark the launch date, any promotions and any tracking changes. A simple before-and-after total can’t show the effect of the move if the season, ad spend or tracking changed at the same time.
For a domain move, use the Search Console Change of Address process when applicable. Keep the old domain and redirects available; do not retire them as soon as the new site works. Follow Google’s current migration guidance for retention and monitoring.
Questions to settle before a date is agreed
- Who owns each mapping exception and can approve it?
- Who can pause a release if production differs from staging?
- What can be rolled back, and what would happen to orders received after launch?
- Who will review search performance during the following weeks?
For implementation support, see technical SEO audits, WordPress development or Shopify development. The ecommerce launch checklist covers the operational tests that sit beside this register.
Prefer to hand the whole process over? My SEO migration service covers the URL inventory, redirect map, staging report and post-launch reviews.
Further reading
Google’s site-move guidance and redirect documentation explain the search-engine behaviour. Shopify’s URL redirect documentation covers platform-specific constraints. The lists and launch rules above are my own planning templates, not official platform rules.
If the move is part of a wider website redesign, plan both together so design changes do not break search.
For platform-specific steps, see how to import Shopify redirects at scale and the Shopify to WooCommerce migration guide.