SEO Migration Checklist
By Chris LourencoLast updated
I help business owners move to a new website, platform or domain and carry their search history and enquiries across with them. This is the checklist I work from, in 4 parts, free to read in full. Use it yourself, hand it to your web designer, or talk to me about running the SEO side of your move.
- A clear order of work, from the baseline to the weeks after launch
- 1 checklist for domain changes, replatforms, redesigns and https moves
- Free to read and print, with a spreadsheet and PDF if you'd like them
“In addition to content creation, Chris has been invaluable in updating our website with our new simplified design, optimising web links, and resolving backend indexing issues. These improvements have streamlined the user experience and ensured a seamless journey for our audience.”
160+ 5-star Google reviews across Australia
Work directly with Chris
Meet Chris →Key Takeaways
- Capture the baseline before you change anything. Rankings, top pages, backlinks, the URL inventory, the existing redirect map and the analytics record can only be taken while the old site is running.
- Search Console holds 16 months and no more, so export it by page and by query before the old site goes away.
- Redirect mistakes and lost internal links cause most migration traffic loss, so the redirect map and the new navigation deserve the most checking.
- A 301 to a genuinely equivalent page passes its signals across, so map every old URL to its true match.
- A short dip is normal. A drop of more than about 30%, or one still showing at week 4, is a defect to diagnose straight away.
In short: To migrate a website and keep its 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 straight at their final pages, then compare against the frozen baseline weekly at page level until every page is back.
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
Needs the most planning
Every URL changes at once, and the new domain starts without the history the old one built. It's the only type where the Change of Address tool applies, and the one that takes longest to settle.
A replatform
WordPress to Shopify, Wix to a custom build, or the reverse
The most mapping work
The domain stays, but the new system brings its own URL conventions, so the mapping sheet is the largest of any type. Content parity is the other big job, because simpler templates can drop the copy that was doing the ranking.
A redesign on the same domain
Same URLs, new look, new templates
The lowest redirect risk
URLs can often stay identical, which removes most of the redirect risk. The work moves to content and internal linking, so check that each page keeps its copy and that the new navigation still reaches every section of the site.
A protocol or structure change
http to https, www to non-www, adding or removing trailing slashes
The smallest job
The smallest of the 4, and the one that rewards finishing properly. Every combination of protocol, host and trailing slash has to resolve in a single hop to one canonical form. Change of Address doesn't apply here.
Many real projects are 2 or 3 of these at once, such as a rebrand that arrives with a new domain, a new platform and a new design in one release. Where the schedule allows, separate them. Moving the domain in one release and redesigning in the next adds a few weeks to the plan and lets you see exactly 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 adjusted after launch, and this one has to happen while the old site is still running, because it records how that site performed.
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 matters most
6 weeks after a migration, someone will ask whether a page used to rank. A dated export answers that in a minute. Search Console retains 16 months and then discards, so the earlier you capture it, the more of the record you keep.
It also shapes what you do next. With a baseline you can sort by clicks lost per URL and work on the 20 pages that actually dropped, so every fix goes where it counts. If a web designer is building the new site and nobody owns the search side, this capture is the first job to hand to Adelaide SEO specialists, because it has to happen in the weeks before launch rather than after it.
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 finished when the numbers are back, and you see that by measuring 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 in its early months
Trusted Mechanical, a diesel workshop in Lonsdale, Adelaide, went live with a full SEO rebuild on 25 June 2026. Impressions stepped up from late June, and the site now surfaces for the Adelaide diesel terms the workshop wants, from diesel tuning to DPF cleaning. It's still early.
That order is typical of a rebuild. Impressions move first, positions consolidate afterwards, and clicks follow the positions. Knowing which of those 3 should be moving at week 4 helps you read a normal recovery correctly and spot a real defect early.
Optional bonus
“He found a way to transfer our previous Squarespace website over to Wordpress for better SEO optimisation and functionality.”
4 pieces of migration advice, and what to do instead.
Each one sounds reasonable and saves a little time on the day. Here's what I do in its place, and why.
✕Point all the old URLs at the homepage and let Google sort it out
What to do instead
Map each old URL to its genuine equivalent instead. Google treats a redirect to an unrelated page as a soft 404, so the old URL's value drops away, and the visitor who followed an old link lands somewhere they didn't ask for.
✕Migrate and rewrite the content in the same release
What to do instead
Where the schedule allows, do them in 2 releases. If URLs, templates and copy all change on one day, a drop has 3 candidate causes and you can't separate them. Moving first and rewriting second keeps every result readable.
✕Traffic always drops after a migration, so give it 6 months
What to do instead
A dip while Google reprocesses URLs is normal, and the baseline tells you when it's more than that. Still materially down at week 4, or down more than about 30% at any point, means a defect to find, so go straight to the redirect map and the internal links.
✕The new site is faster, so rankings will improve
What to do instead
Speed helps, modestly, and it's well worth having because faster pages convert better. Treat it as a bonus on top of a complete redirect map and full content parity, which carry far more weight.
Each of these takes a little more care during the build, and each one protects the rankings and enquiries the old site already earns.
SEO migration questions.
What is SEO migration?
How can I migrate my website without losing my SEO?
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
More help for the questions a migration raises.
My Website Dropped Off Google
Diagnosing a ranking drop and finding its cause, migration or otherwise.
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?
What helps a site rank, and how to tell which piece yours needs.
What SEO Costs
Retainer pricing, what sits inside it, and what a rebuild changes.
Got a migration coming up? I'll run it with you.
The checklist is free and stays free, whether you work through it yourself or hand it to whoever is building the new site. When you'd like me to run the move with you, there are 2 routes.
- A website rebuild with the migration handled, from $4,000+GST. I build the new site and run every check on this page as part of the job.
- Website SEO from $1,500+GST a month, month to month, when someone else is building the site. I own the search side of the move, from the baseline to the monitoring.
“Now using SEO, we have had an influx of extra leads and he found leads that were not coming through on our old website.”
160+ 5-star Google reviews across Australia · 9 years Adelaide-based