SEO

The SEO Migration Checklist: What to Do Before, During and After a Site Move

An SEO migration checklist runs in a fixed order: record a baseline, inventory every URL, decide what each page becomes, build the redirect map, keep staging out of search, match titles and markup, update links and sitemaps, protect tracking, check launch day, then monitor against the baseline. Skipping early steps makes the later ones guesswork.

Prabhu SolutionsPublished 8 October 2026Last reviewed 8 October 202617 min read

On this page

What is an SEO migration checklist, and what is it for?
What is the SEO site migration checklist, in order?
How do you record a baseline, inventory URLs and build the redirect map?
How should the staging site be kept out of search?
Which on-page elements need to match between the old and new site?
How should internal links and XML sitemaps be handled?
How do you keep analytics and Search Console continuous?
How does the platform you are moving to change the checklist?
What should be checked on launch day?
What should you monitor after an SEO migration?
What commonly goes wrong in an SEO migration, and how do you spot it?
When should you not migrate at all, or change less?
Who should run the migration, and what drives the effort?

What is an SEO migration checklist, and what is it for?

An SEO migration checklist is the ordered list of checks that protects the pages already earning you enquiries when a website changes platform, domain, URLs or templates. Its purpose is narrow: make sure search engines can find the new version of every page that mattered, and that you can tell afterwards whether anything was lost.

Search engines know your site by its addresses. A migration changes the addresses, the templates that produce them, or both, and anything not carried across properly can drop out of the results. Most of the damage is not mysterious. It comes from a redirect nobody wrote, a noindex tag copied across from staging, or content that only exists after JavaScript runs.

Not every redesign is a migration. A new look on the same platform with the same URLs and the same copy is a low-risk change. The risk rises with each thing you alter at once, which is also why this list matters most when several things move together. If you want the work planned and tested by someone else, SEO migration support exists for exactly that, as part of wider SEO work.

The point
Not every redesign is a migration.

What is the SEO site migration checklist, in order?

The checklist has thirteen steps in a fixed order: scope the move, record a baseline, inventory every URL, decide what each page becomes, build the redirect map, protect staging, match on-page elements, update links, prepare sitemaps, protect tracking, test on staging, launch carefully and monitor. Each step is explained below.

Step 1: Decide what is actually changing. List the platform, domain, URL structure, templates, copy and navigation separately. The more that changes together, the harder any later fall is to diagnose.
Step 2: Record a baseline. Capture what ranks, what is indexed, which pages earn links and which produce enquiries, before anything moves.
Step 3: Inventory every live URL. Combine a crawl, Search Console, analytics and your sitemaps, so pages a crawler cannot reach are included.
Step 4: Decide what each page becomes. Keep, merge, rewrite or retire, with a written reason.
Step 5: Build the redirect map. One row per old URL, one permanent redirect to its closest new equivalent.
Step 6: Keep staging out of search. Use access control, not only a noindex tag, and write down every staging setting that must change at launch.
Step 7: Check on-page parity. Titles, descriptions, headings, copy, canonicals, structured data and hreflang should match what ranked, unless a change was agreed.
Step 8: Rewrite internal links to final URLs. Menus, breadcrumbs and in-content links should not route through redirects.
Step 9: Prepare the XML sitemap and robots.txt. List only final, indexable URLs, and make sure the live robots.txt allows crawling.
Step 10: Protect analytics and Search Console. Carry tracking across, test conversions, and verify the new property before launch.
Step 11: Test on staging. Run the redirect map against the full URL list and crawl the new site, including its raw HTML.
Step 12: Launch with the redirects live. Switch staging settings off in a written order, with a rollback route, then run the launch-day checks.
Step 13: Monitor against the baseline. Watch indexation, errors, traffic and enquiries, fix what surfaces, and leave the redirects in place.

How do you record a baseline, inventory URLs and build the redirect map?

Record what ranks and converts, list every live URL from several sources, decide what each page becomes, then give every URL that earned traffic, links or rankings one permanent server-side redirect to its closest new equivalent. The map is the only thing connecting what search engines already know to what you are about to launch.

The baseline comes first: what ranks, what is indexed, which pages earn links and which produce enquiries. Without it a fall after launch is an argument, because “it feels lower” cannot be separated from seasonality or a change in tracking. A thorough SEO audit of the old site produces most of it, and notes what was already broken so the move is not blamed for inherited faults.

The inventory needs several sources because each sees pages the others miss. A crawl finds pages linked from other pages, Search Console shows which URLs receive impressions and clicks, analytics shows which landing pages convert, and your sitemaps show what you thought mattered. Old campaign pages, parameter versions and PDFs are the usual casualties.

Decide the fate of each URL before writing a rule: keep, merge, rewrite, or retire with a redirect to a relevant parent or a proper 410 response. Google treats a redirect to an irrelevant page, such as everything sent to the homepage, much as it treats a missing page, so a pattern rule that looks complete in a spreadsheet can teach search engines nothing.

Use 301 or 308 redirects set at server level, not meta refreshes or JavaScript redirects. Avoid chains and loops, and include the variations people forget: trailing slashes, capital letters, query strings and the http and www versions of the old site. Test the whole list on staging, not a sample of twenty.

Treat redirects as permanent. Google's guidance for site moves is to keep them for at least a year, and longer where the old addresses still receive links or visitors. Removing them to tidy the server is a common way to turn a recovered migration back into a broken one.

The point
Removing them to tidy the server is a common way to turn a recovered migration back into a broken one.

How should the staging site be kept out of search?

Put the staging site behind password or IP-based access control, and add a noindex rule as a second layer. Access control is the only method that reliably stops both search engines and strangers. A noindex tag alone can fail quietly, and a robots.txt block alone does not stop a URL being indexed if other sites link to it.

The two common methods also interact badly. If robots.txt blocks crawling, a search engine cannot read the noindex tag on the pages it is blocked from. And whichever method you use, it has to be switched off at launch. A noindex tag or a robots.txt block that travels from staging to the live site tells search engines the new pages do not want to be found. It looks perfect in a browser, which is why it survives, and it is the first thing a technical SEO review looks for.

Write the switch-off list before launch day, not on it: the noindex meta tag, any X-Robots-Tag header set by the server, the robots.txt file, the access control, any canonical tags that name the staging domain, and sitemaps that list staging addresses. Each is a separate setting, often in a different place, and each has been forgotten by someone competent.

The point
Each is a separate setting, often in a different place, and each has been forgotten by someone competent.

Which on-page elements need to match between the old and new site?

Titles, meta descriptions, headings, body copy, canonical tags, structured data, image alternative text and hreflang should all carry across to the new pages unless you have agreed a change on purpose. These elements are how search engines decide what each page is about, so quiet differences move rankings even when every URL redirects correctly.

Element	What to compare	A common slip
Title tags	The new title against the old one on every page that ranked, and that each new title is unique.	A template that replaces every title with the site name, or truncates the important words.
Meta descriptions	That each page still has one that describes it accurately.	A blank field in the new CMS, so search engines write their own.
Headings	One clear h1 per page, matching the topic of the page, with the subheadings that answered real questions still in place.	A designer turning the h1 into an image, or demoting every heading to styled text.
Body copy	Whether the text that ranked still exists, in full, on the new page.	A cleaner design shortens pages, and the section that answered a particular question disappears.
Canonical tags	That each canonical names its own final, live URL.	A canonical still pointing at the staging site or the old domain.
Structured data	That markup validates and matches what the page shows.	Markup left behind in a theme that no longer exists, or copied from a template with the wrong address.
Image alternative text and file names	That meaningful images keep descriptive alternative text.	Images re-uploaded to the new CMS with the alternative text stripped.
hreflang	That every language or country version points at the others and back again, using final URLs.	Annotations pointing at addresses that now redirect, or only in one direction.

How should internal links and XML sitemaps be handled?

Point every internal link and every sitemap entry at the final URL, never at an address that redirects. Menus, breadcrumbs, in-content links, canonical tags and the XML sitemap all describe your structure to a search engine, and if they still name the old addresses they tell it the old structure is current and add a hop to every click.

In practice this means a find-and-replace across content, and a check of the templates that generate links automatically, such as breadcrumbs, related-product blocks and footer menus. It is also the right time to tidy structure: a service page that was only reachable from the footer deserves a proper place in the navigation. Resist changing too much at once, though, for the reasons in the first step.

A sitemap should list only final, indexable addresses that return a normal page. A single file is limited to 50,000 URLs and 50MB uncompressed, so larger sites use an index of several files. Reference the sitemap in robots.txt and submit it in Search Console. Some teams also submit a temporary sitemap of old URLs so that crawlers meet the redirects sooner; it is optional, and the main sitemap must stay clean.

If the site serves more than one country or language, the same logic applies to hreflang. Markup that is not reciprocal, or that names redirected addresses, can show the wrong version in the wrong market, and the detail belongs to international SEO.

The point
If the site serves more than one country or language, the same logic applies to hreflang.

How do you keep analytics and Search Console continuous?

Carry the same Google Analytics 4 property and tag setup across to the new site, test every conversion event on staging, and have the new Search Console property verified before launch. Without continuous tracking you cannot compare before and after, and nobody can say whether traffic fell or only the measurement did.

Conversions are where this usually fails. A rebuilt form can lose its tracking event, a thank-you page can change address, a tracked phone number can vanish from a redesigned header. Submit a test enquiry through every form, click every tracked call and email link, and confirm each arrives in GA4 as the same event name as before. Add an annotation for the launch date so the change is visible in reports.

Check how Search Console verification was done. If the old property was verified by an HTML tag in a theme file, it can disappear with the theme. A domain property verified through DNS survives a platform change. For a change of domain, verify both properties and use Search Console's Change of Address tool, which is meant for moves to a new domain rather than a switch between http and https or a rearrangement within one site. Keep the old property: you will want its data for the comparison.

The point
If the old property was verified by an HTML tag in a theme file, it can disappear with the theme.

How does the platform you are moving to change the checklist?

The platform decides how URLs are formed, which settings can leak from staging, and where redirects are managed, so each destination adds its own checks. The table covers four common cases. The steps stay the same; what changes is where the usual faults sit and which of them are built into the platform.

Moving to	What changes at URL level	What to check
WordPress	Permalink settings decide the address format, and plugins often generate the sitemap, canonical tags and redirects.	The setting that discourages search engines, left on after staging. Which plugin owns redirects and sitemaps, so two do not conflict. See WordPress development for how builds are approached, and WordPress or custom build if the platform choice is open.
Shopify	Product and collection addresses sit under fixed prefixes such as /products/ and /collections/, so a move from a different structure changes most store URLs.	A full product, collection and page redirect list imported through the admin, and canonical handling for products reachable through several collections. A Shopify agency will own this on the build side; the platform decision is covered in Shopify, WooCommerce or custom.
WooCommerce	Product and category addresses use configurable base prefixes, and filters and variations can generate large numbers of parameter URLs.	That the product and category bases are set deliberately before the catalogue is imported, and that filter URLs are handled rather than left to multiply. Ecommerce development covers store moves generally, and ecommerce SEO covers what the catalogue needs afterwards.
A custom-built site	Anything is possible, and nothing is automatic: redirects, sitemaps, canonicals and rendering are all things a developer must build.	What the server sends before JavaScript runs, where the redirect rules live, and who maintains them. Website development should include these in the specification, not as an afterthought.

What should be checked on launch day?

On launch day check that every redirect resolves in one step, that nothing from staging is still switched on, that canonicals and the sitemap name live URLs, and that tracking records a real enquiry. The table gives each check, how to run it, and the red flag that means stop and investigate before anything else.

Check	How to run it	Red flag
Redirect map on the live domain	Run the whole list of old URLs through a crawler in list mode and read the status codes.	Any 404, any chain of more than one hop, or any redirect to a page that is not the intended equivalent.
robots.txt	Open the live file in a browser and read it.	A blanket Disallow for the whole site, or the staging file still in place.
Noindex rules	View source on each template and inspect response headers; use the URL Inspection tool on key pages.	A noindex meta tag or an X-Robots-Tag header on pages that should rank.
Canonical tags	Read the canonical on each template and on a sample of key pages.	A canonical naming the staging domain, the old domain or a redirecting address.
Host and protocol versions	Request the http, https, www and non-www versions of the homepage and a deep page.	More than one version returning a normal page rather than redirecting to the chosen one.
XML sitemap	Open it, spot-check URLs, then submit it in Search Console.	Redirecting, erroring or staging addresses listed inside it.
Tracking	Submit a real test enquiry, click a tracked phone link, and watch GA4 receive both.	No events, a changed event name, or a thank-you page that no longer fires.
Error handling	Request a nonsense address and read the response.	A page that looks like an error but returns a 200 status, or a blank page.

What should you monitor after an SEO migration?

Monitor indexation, crawl errors, traffic and enquiries against the baseline, page group by page group, and keep the redirects in place while you do. Expect movement, because search engines re-crawl and re-rank the new pages. The job is to tell that normal movement from a fault, and to fix faults while they are still small.

Search Console's Page indexing report. Look for new 404s, redirect errors, soft 404s and pages discovered but not indexed. Triage by whether the URL earned traffic or links before the move.
Redirects and live status codes. Re-run the full redirect map after launch and again after any release, since deployments and plugin updates can quietly overwrite rules.
Traffic and enquiries compared with the baseline. Old URLs lose traffic as new ones gain it, so compare grouped sections of the site and the enquiries, not a single day's graph.
Crawl behaviour. Search Console's crawl stats, and server logs where they exist, show whether search engines are crawling the new site and still spending time on old addresses.
Links from other sites. Look for linked addresses the map missed, add the redirects, and ask the most valuable linking sites to update their links.
Core Web Vitals. Field data lags behind a launch, so judge it over time, and compare it with the old site on the pages that earn traffic. What Core Web Vitals measure explains how to read the figures.
Tracking. Check enquiries are still being recorded every time you review, because a later release can break an event that worked at launch.
Ongoing change control. The risk does not end at launch, which is why many sites pair this with website maintenance so someone is watching after the project team leaves.

What commonly goes wrong in an SEO migration, and how do you spot it?

The commonest failures are unmapped URLs, copied noindex or robots rules, wrong canonicals, content drawn only by JavaScript, lost tracking and shortened copy. Each has a recognisable symptom in Search Console or analytics. The table pairs symptoms with the likely cause and the first thing to check, so a fault is found in minutes rather than argued over.

Symptom	Likely cause	First thing to check
Pages vanish from results shortly after launch	A noindex tag or robots.txt block carried over from staging.	View source and robots.txt on the live site.
Search Console reports many “not found” URLs that used to rank	Old addresses with no redirect in the map.	Compare the reported URLs with the inventory.
One section falls while the rest holds	A template-level fault in that section: canonical, rendering, titles or headings.	Compare the raw HTML of that template with the old one.
Redirects exist but traffic to those pages falls	Redirects sent to irrelevant pages, or content thinned on the new page.	Compare the old and new content, and the destination chosen in the map.
Enquiries drop to nothing overnight	Conversion tracking not carried across, or a form that no longer sends.	Submit a test enquiry and watch for it in GA4 and the inbox.
Duplicate versions of the site appear	Host or protocol redirects missing, or canonicals inconsistent.	Request each version of the homepage and read the response.
The wrong country version ranks in a market	hreflang that is not reciprocal or names redirected addresses.	Check annotations in both directions on a sample page.
Content seems missing to some crawlers	The new front end draws content with JavaScript after the page loads.	Fetch the page without running JavaScript and read the response.

When should you not migrate at all, or change less?

Do not migrate when the current site earns enquiries from search and the reason for the move is cosmetic. Changing the platform, the URLs and the copy together for a fresher look is the combination that most often costs traffic. If the old site works, keep its URLs, and fix what is actually broken first.

A slow or awkward site can often be repaired in place, and whether the platform is really the constraint is a question to answer before rebuilding. The trade-offs are set out in WordPress or a custom build and, for shops, in the shop platform comparison. Be suspicious of any supplier who recommends a rebuild without checking.

Phasing helps when a move is justified. Move the platform first and hold the URLs and copy still, then change the structure once the new platform is stable. That can mean a second round of redirects, but when something moves you know what moved it. If hardly any of your enquiry volume rides on search, a single move is reasonable.

Timing matters too. Peak trading weeks, or a launch date driven by a deadline unrelated to readiness, are poor times to move. A launch that slips is annoying; a broken one at peak season is expensive. And if nobody can own the redirect map and the testing, the right decision is to wait until somebody can.

The point
Peak trading weeks, or a launch date driven by a deadline unrelated to readiness, are poor times to move.

Who should run the migration, and what drives the effort?

Whoever owns the URL map and the staging tests should run it, whether that is your developer, a freelancer or an agency. The deciding question is not who writes the code but who is accountable for the redirects, the pre-launch checks and the monitoring. If the answer is nobody, the work is unowned and the risk is yours.

The effort is driven by the number of URLs to map, how much of the structure changes, how complex the platform is, whether a domain or country changes, and who builds the new site. A forty-page brochure site that keeps its addresses is a small job. A shop with a very large catalogue on a new platform is not. What a rebuild costs overall is a separate question, covered in what a website costs in the UK.

We do not publish prices, and we scope this kind of work after looking at the site. Where we build the site, the migration plan sits inside the build; where another supplier does, our part is the specification and the testing of their staging site. If you are planning a move and want an honest view of whether it needs a specialist, send us the details. Prabhu Solutions is registered at 14 Chester Rise, Oldbury, B68 0SS, West Midlands, and the work runs remotely. Our delivery record to date is international rather than UK-based, and you can see what we have built and judge it directly.

The point
Where we build the site, the migration plan sits inside the build; where another supplier does, our part is the specification and the testing of their staging site.

Questions people ask about this

What is the difference between an SEO migration plan and a checklist?

A plan is the decisions specific to your site: what changes, what each page becomes, who owns each task and how rollback works. A checklist is the generic order of checks that every plan should contain. Use the checklist to test whether your plan has gaps, then write the plan against your own URLs.

Will I lose rankings when I migrate my website?

Temporary movement is normal, because search engines must re-crawl and re-evaluate the new pages. Lasting loss usually comes from avoidable causes: unmapped URLs, wrong redirects, copied noindex rules, thinner content and lost tracking. No supplier can promise zero movement, and anyone who does is promising something they do not control.

How long should I keep 301 redirects in place?

Treat them as permanent. Google's guidance for site moves is to keep them for at least a year, and for as long as the old addresses still receive links or visitors. Removing them to simplify the server is a common reason a recovered migration breaks again later.

Do I need a separate SEO migration for a redesign?

Only if the redesign changes URLs, platform, domain or substantial copy. A new look on the same platform with identical addresses and content needs a short check, not a full programme. The more elements change at once, the stronger the case for the full checklist. An audit of the current site shows what is at stake.

Should I use a noindex tag or a password on staging?

Use a password or IP restriction, and add noindex as a second layer. A robots.txt block alone does not stop a URL being indexed if other sites link to it, and it can stop a crawler reading the noindex tag. Whichever you use, list it among the settings to switch off at launch.

Do I need to tell Google about a site move?

For a change of domain, yes: use Search Console's Change of Address tool once both properties are verified and the redirects are live. For a platform change, a URL change within the same domain, or a switch to https, there is no such tool. Redirects, sitemaps and a verified Search Console property do the work instead.

What should I do if traffic drops after launch?

Do not panic and do not undo everything. Check the likely causes in order: noindex or robots rules, then redirect status codes, then canonicals, then rendering, then tracking. Compare against your baseline by section. If a fault is found, fix it. If not, normal re-ranking can take time. Technical SEO review is the next step.

Is moving to HTTPS or changing www a migration too?

Yes, a small one. The paths stay the same but the address of every page changes, so every old version must redirect to the chosen one in a single step, and canonicals, sitemaps and internal links must name it. It is the lowest-risk kind of move, and still one where leftovers cause duplicate versions.