SEO Migration Checklist
The whole job, in 4 parts: what to capture before you migrate, how to map URLs and redirects, the cutover, and what to watch afterwards. It covers a domain change, a replatform, a redesign that keeps the domain, and an http to https move. Start with Part 1, because it is the only part you cannot redo.
Work directly with Chris, Ana, and Audrey
Meet the team →Key Takeaways
- Capture the baseline before you change anything. Rankings, top pages, backlinks, the URL inventory, the existing redirect map and the analytics record are the only part of a migration you cannot redo.
- Search Console holds 16 months and no more, so export it by page and by query before the old site goes away.
- Most migration traffic loss comes from redirect mistakes and lost internal links. Not algorithm changes, not the new platform, and not anything exotic.
- A 301 to a genuinely equivalent page passes signals. A bulk redirect to the homepage is treated as a soft 404 and passes nothing.
- Expect a short dip. Down more than about 30%, or still down at week 4, is a defect to diagnose rather than a settling period to wait out.
In short: To migrate a website without losing rankings, freeze a record of how the current site performs, inventory every URL Google knows about, map each one to a single new URL with a 301, test the map against the live rules before you launch, point internal links at final destinations rather than through redirects, then compare against the frozen baseline weekly at page level until it recovers.
Which kind of migration are you doing?
The word migration covers 4 fairly different projects. All 4 use this checklist, because the mechanics are the same: URLs change, or the content on them changes, and Google has to be told which new address replaces which old one. What differs is where the risk concentrates.
A domain change
oldbrand.com.au becomes newbrand.com.au
Highest risk
Every URL changes at once, and the new domain has none of the history the old one built. The only type where the Change of Address tool applies, and the only one where recovery is routinely measured in months rather than weeks.
A replatform
WordPress to Shopify, Wix to a custom build, or the reverse
Highest volume of work
The domain stays, but the new system imposes its own URL conventions, so the mapping sheet is the largest of any type. Content parity is the other trap: templates get simplified, and the copy that was doing the ranking goes with them.
A redesign on the same domain
Same URLs, new look, new templates
Lowest risk, most underestimated
URLs can often stay identical, which removes most of the redirect risk. What goes wrong instead is content and internal linking: pages get shortened, and a new navigation quietly stops linking to a third of the site. Redesigns lose traffic without a single broken redirect.
A protocol or structure change
http to https, www to non-www, adding or removing trailing slashes
Small job, easy to get subtly wrong
The smallest of the 4, and the one most often left half-finished. Every combination of protocol, host and trailing slash has to resolve in a single hop to one canonical form. Change of Address does not apply, and done properly this one settles fast.
Most real projects are 2 or 3 of these at once: a rebrand arrives with a new domain, a new platform and a new design in one release. That is normal, and it is also why diagnosis afterwards is so hard. Where the schedule allows, separate them. Moving the domain in one release and redesigning in the next costs a few weeks and buys you the ability to know which change did what.
Before you migrate: 12 things to capture while you still can.
The most useful part of the page. Every other stage can be fixed after launch. This one cannot, because the moment the old site is switched off, the evidence of how it performed goes with it.
Stage 1: Freeze the performance record
Do this first, and do it properly. Every other stage can be redone after launch. This one cannot, because the moment the old site is switched off the evidence of how it performed goes with it.
- 1
Export 16 months of Search Console data, by page and by query
Search Console retains 16 months and then discards. Export the Performance report twice, once grouped by page and once by query, at the maximum date range, and save the files yourself.
- 2
Export the analytics baseline by landing page and by channel
In GA4, take the Landing page report and the Traffic acquisition report for the last 12 months. Landing pages show which URLs earn sessions; channels let you attribute a drop rather than argue about it.
- 3
Record current ranking positions for the terms that matter
A dated snapshot for your top 50 to 100 commercial terms, from a rank tracker or from average position by query. An undated estimate made after the fact settles no argument.
- 4
Note the seasonality of the last 2 years
Pull the same months from the previous year alongside the baseline. Plenty of migrations get blamed for a January drop that happened every January.
Stage 2: Capture the full URL inventory
3 sources, because no single one is complete. A crawl finds what is linked, Search Console knows what Google found, and the old server knows what still gets requested.
- 5
Crawl the live site and export every URL it returns
Export URL, status code, title, meta description, H1, canonical, indexability and word count. This is the spine of the mapping sheet, so crawl before anything on the old site changes.
- 6
Pull the URLs Google knows about, not just the ones you link to
Export the Page indexing report and every submitted sitemap. Google holds URLs that are no longer linked anywhere: old campaign pages, orphaned posts, paginated archives. A crawl alone misses all of them.
- 7
Export the redirect map that already exists
Most sites carry redirects from a previous move, in .htaccess, an nginx config, a plugin table or a hosting panel. Rebuild without them and every one of those URLs starts 404ing at launch.
- 8
List the non-HTML URLs that earn traffic or links
PDFs, spec sheets and downloads get linked and ranked, and a rebuild drops them first. Filter the crawl and the backlink export for anything that is not a page, and map those too.
Stage 3: Capture links and technical state
The part of the site you did not build and cannot recreate. Backlinks are earned over years and lost in an afternoon by pointing them at a 404.
- 9
Export the backlink profile grouped by target URL
Not a list of linking domains: you need which of your pages each link points at. That column tells you which URLs must be mapped 1 to 1 no matter what.
- 10
Save robots.txt, the sitemaps and the canonical pattern
Keep literal copies, and note how canonicals are formed: trailing slash or not, www or not, http or https. Rebuilds routinely flip 1 of those and generate a full set of duplicates on day 1.
- 11
Record titles, meta descriptions and structured data
Your crawl export already holds titles and descriptions. Add which schema types appear on which template. Rewriting every title in the same week you change every URL makes movement impossible to attribute.
- 12
Record Core Web Vitals and server response times
A dated reading from the Core Web Vitals report plus a PageSpeed run on your 3 main templates. A replatform that turns out slower is worth catching in week 1, not month 6.
Why the baseline is the part people regret skipping
6 weeks after a migration, someone asks whether a page used to rank. Without a dated export, nobody can answer, and the argument that follows cannot be settled. Search Console retains 16 months and then discards, so a baseline captured late is already partly gone.
It also changes what you do next. With a baseline you can sort by clicks lost per URL and work the 20 pages that actually dropped. Without one, the only response available is to rebuild things at random and hope.
URL mapping and redirects: 8 checks.
The mapping sheet is the migration. 1 row per old URL, a single destination on each row, and no blanks. Everything after this is execution.
Stage 4: Build the mapping sheet
1 row per old URL, and no blanks. This document is the migration. Everything else is execution.
- 1
Map every old URL to a single new URL, 1 to 1
Old URL, new URL, and the reason if they differ. Every URL from all 3 inventory sources gets a row. An empty destination is a decision nobody has made yet.
- 2
Decide deliberately what happens to pages you are not keeping
With no equivalent, redirect to the closest genuinely relevant page, usually the parent category. Serve a 410 only when you want the URL gone and it has no links or traffic.
- 3
Never bulk-redirect everything to the homepage
Google treats a redirect to an irrelevant page as a soft 404, so no value passes and the URL drops out anyway. This 1 shortcut causes more migration traffic loss than anything else on the list.
- 4
Keep the URL structure unless you have a reason to change it
On a redesign or replatform, changing URLs is optional. Every URL you keep is a redirect you never have to write, test or maintain. Change slugs where they are wrong, not because a new system prefers a different pattern.
Stage 5: Get the redirects technically right
Redirect mistakes are the leading cause of migration traffic loss, and almost all of them are found by testing before launch rather than after.
- 5
Use server-side 301s, not 302s, meta refreshes or JavaScript
A 301 says the move is permanent and consolidates signals to the new URL. A 302 says the opposite and keeps the old URL in the index. The other 2 are slower to be honoured and easier to break.
- 6
Flatten every chain to a single hop
Old URL to new URL, directly. Chains appear when a rebuild layers new rules over redirects from a previous migration. Aim for 1 hop and treat anything over 3 as broken.
- 7
Handle the host and protocol variants explicitly
http and https, www and non-www, upper and lower case, trailing slash and not. Every combination should resolve in 1 hop to a single canonical form. On an https move, this is the whole job.
- 8
Decide what happens to query strings and parameters
Tracking, filter, pagination and old search URLs each need a stated rule. Keep the parameters that carry meaning, and check no rule silently strips the UTM tags your reporting depends on.
The cutover: 10 checks on launch.
5 checks on staging while everything is still cheap to fix, then 5 on the day itself. The staging half is the one that pays.
Stage 6: Pre-launch, on staging
Everything here is cheap to fix now and expensive to fix after go-live. Test the redirect map against the real old-URL list before anything is switched.
- 1
Block staging properly, and plan how the block comes off
Use HTTP authentication rather than a noindex tag, because a forgotten noindex shipped to production is the most destructive migration error there is. Write down who removes it, when, and who verifies it.
- 2
Run the full old-URL list against the staging redirect rules
Feed every URL from the mapping sheet through the new rules in list mode and check the status code and final destination on each. The highest-value test in the whole migration, and the most often skipped.
- 3
Point internal links at final URLs, not through redirects
Navigation, in-body links, footers, sitemaps and canonicals should all reference the new URL directly. Lost internal links are the second big cause of migration drops.
- 4
Confirm the content actually came across
Compare word counts, headings and body text between the old crawl and the staging crawl, template by template. Rebuilds routinely lose the long sections that were doing the ranking.
- 5
Check canonicals, hreflang and structured data survived
Diff the staging crawl against the baseline on every field. Self-referencing canonicals should point at the new absolute URL, and schema on the old templates should still be present and valid on the new ones.
Stage 7: Launch
Early in the week and early in the day, on a day someone can watch it. Never on a Friday afternoon.
- 6
Keep the old environment running and reachable
Leave it accessible for at least a few weeks. If the redirects turn out to be wrong, being able to compare against a live original is the difference between a fix and a reconstruction.
- 7
Remove the staging block and verify with a live fetch
Do not trust the deploy. Read the response headers and robots meta on the live homepage and 2 templates, then run the URL Inspection tool with Test live URL.
- 8
Submit the new sitemap, and the old URLs as a temporary one
Submit the new XML sitemap, then a second temporary sitemap listing the old URLs so Google is prompted to recrawl them and find the redirects faster. Remove the second one once they are processed.
- 9
Use the Change of Address tool, but only for a domain change
It applies to a move between domains and nothing else. Both properties must be verified and the 301s must already be live before you submit it.
- 10
Verify the new property and confirm analytics is recording
Set up Search Console for the new property and every protocol and host variant, then confirm GA4 is receiving events from the live site within the hour.
After launch: 9 checks on monitoring and recovery.
A migration is not finished when the site is live. It is finished when the numbers are back, and the only way to know is to measure against the record you froze in Part 1.
Stage 8: The first 72 hours
Almost everything that goes badly wrong is visible in the first 3 days, and almost all of it is cheap to fix if you find it there.
- 1
Crawl the live site and hunt for 404s, chains and orphans
Crawl the new site, then run the old URL list against production. Any 404, any chain over 1 hop, and any page with no internal links pointing at it is a defect to fix today.
- 2
Watch what Googlebot is actually fetching
The Crawl stats report shows response codes and what is being requested. A spike in 404s or 5xx responses, or crawling that collapses to almost nothing, tells you within a day that something structural is wrong.
- 3
Read the Page indexing report daily
Watch for growth in Not found (404), Redirect error, and Duplicate without user-selected canonical. Page with redirect growing is normal: that is Google processing the old URLs correctly. The other 3 are not.
- 4
Test the things that make money, on a phone
Submit every form, tap every phone link, complete a checkout if you have one, and confirm the conversion recorded in GA4 and in Google Ads. Tags break silently in a rebuild.
Stage 9: Weeks 1 to 12
Expect a dip. The job is telling a normal settling period apart from a real problem, and the baseline you captured in stage 1 is the only thing that lets you.
- 5
Compare against the frozen baseline, not against last week
Use the Performance report with date comparison against the pre-migration period, at page level. During a migration both recent weeks are unstable, so the baseline is your only fixed point.
- 6
Know the thresholds before you panic or relax
A short dip is normal. Still materially down at week 4, or down more than about 30% at any point, is a defect: go back to the redirect map and the internal links first.
- 7
Diagnose at page level, never at site level
Sort by clicks lost against the baseline and take the worst 20 URLs individually. Losses are almost never evenly spread. They concentrate on pages mapped wrong, thinned out, or stripped of internal links.
- 8
Chase the backlinks worth chasing
Redirects pass value, but a direct link is better and a redirect can be removed later. Ask the 20 or 30 strongest linking sites to update the URL, and ignore the long tail.
- 9
Keep the redirects, effectively forever
12 months is the usual minimum, but old links keep sending people for years and a redirect file costs nothing to keep. Removing redirects should be a decision with evidence behind it.
What a rebuild looks like while it is still recovering
Trusted Mechanical, a diesel workshop in Lonsdale, went live with a full SEO rebuild on 25 June 2026. Impressions have climbed sharply since, and the site now surfaces for Adelaide diesel terms it was not appearing for before. It is also still early: average position sits around 31, which is visible in Search Console and not yet visible to most people searching.
That is the honest shape of a rebuild in its first months, and it is worth stating plainly because migration content tends to skip the middle. Impressions move first, positions consolidate afterwards, clicks follow the positions. Knowing which of those 3 should be moving at week 4 is what stops a normal recovery being mistaken for a failure.
Optional bonus
4 pieces of migration advice to ignore.
Each one is common, each one sounds reasonable, and each one is usually offered by whoever has the least interest in it being examined.
✕Point all the old URLs at the homepage and let Google sort it out
Google treats a redirect to a page that is not a genuine equivalent as a soft 404, so no value passes and the old URL drops out anyway. It also strands every visitor who followed an old link.
✕Migrate and rewrite the content in the same release
You can, but you give up the ability to diagnose the result. If URLs, templates and copy all change on one day, a drop has 3 candidate causes and no way to separate them. Where the schedule allows, do them in 2 releases.
✕Traffic always drops after a migration, give it 6 months
A dip while Google reprocesses URLs is normal. Still materially down at week 4, or down more than about 30% at any point, is a defect and waiting will not fix it. That advice usually comes from whoever ran the migration.
✕The new site is faster, so rankings will improve
Speed is real but modest, and nowhere near large enough to offset a redirect map with holes in it or a page that lost half its content. Improve speed because it converts better, not as insurance against the rest of the checklist.
The pattern is the same each time: a shortcut that saves an afternoon during the build, paid for over the following 6 months by someone who was not in the room when it was taken.
SEO migration questions.
What should I capture before a website migration?
How much traffic will I lose when I migrate a website?
Do I need to change my URLs when I redesign a website?
How long should I keep the 301 redirects after a migration?
Does an http to https migration need the same checklist?
Can I use the Change of Address tool for a redesign?
What are the most common causes of traffic loss after a migration?
How long does it take to recover after a site migration?
Related Resources
For when the migration raises a question this page does not answer.
My Website Dropped Off Google
Diagnosing a ranking loss when you are not sure a migration caused it.
Website Design and Rebuilds
Rebuilds run with the redirects, content parity and internal links treated as part of the job.
Why Isn't My Website Ranking?
The reasons a site does not rank, and how to tell which one applies to yours.
What SEO Costs
Retainer pricing, what sits inside it, and what a rebuild changes.
Got a migration coming up you'd rather not run alone?
The checklist is free and stays free, whether you work through it yourself or hand it to whoever is building the new site. If you would rather someone ran the SEO side of the move with you, that is what Chris does: website SEO from $1,500+GST/month, month to month, with no lock-in contract.
130+ five-star reviews across Australia · 8 years Adelaide-based · Google Partner