SEO Site Migration Checklist: Protect Your Rankings

Why Site Migrations Are the Highest-Risk SEO Event

A website migration is any significant change to your site's URLs, structure, platform, domain, or design that could affect how search engines crawl, index, and rank your pages. When done well, a migration preserves your rankings and positions you for growth. When done poorly, it can destroy years of organic traffic overnight.

The data is sobering. An analysis of 892 site migrations found that the average recovery time for organic traffic is 523 days. That is nearly 18 months. Worse, 17 per cent of sites in that study never recovered their pre-migration traffic levels, even after more than 1,000 days. These are businesses that permanently lost a significant revenue channel because the migration was not handled properly.

In my 15 years as an SEO consultant, I have managed more than 20 site migration projects across Australian businesses. The pattern is consistent: migrations that involve SEO from the planning stage maintain 90 to 100 per cent of their traffic. Migrations where SEO is an afterthought, or is brought in after launch to "fix the damage," rarely recover fully.

This guide covers the complete migration process: planning, execution, and recovery. Whether you are moving to a new CMS, redesigning your site, changing domains, or restructuring your URLs, these steps will protect the organic traffic your business depends on.

Types of Website Migrations

Not all migrations carry the same level of risk. Understanding which type you are performing determines how much preparation you need.

Platform or CMS Migration

Moving from one content management system to another, such as WordPress to Shopify, Wix to WordPress, or a custom-built platform to a modern CMS. This is the most common migration type I encounter with Australian businesses.

Risk level: High. Different platforms often generate different URL structures, handle metadata differently, and may not support the same technical SEO features. Every URL change requires a redirect.

Domain Migration

Changing your website's domain name, such as moving from oldbrand.com.au to newbrand.com.au, or consolidating multiple domains into one.

Risk level: Very high. Domain migrations affect every URL on the site and require transferring domain authority signals. Google needs to learn that the new domain is the same entity as the old one. This process takes months.

Site Redesign

Changing the visual design, layout, and user experience while staying on the same platform and domain. Many businesses assume this is low-risk because the domain stays the same, but redesigns frequently change URL structures, remove pages, and alter content.

Risk level: Medium to high. If URLs stay identical and content is preserved, the risk is lower. But in practice, redesigns almost always involve structural changes that affect SEO.

URL Structure Change

Restructuring how your URLs are organised without changing the domain or platform. Examples include moving from flat URLs (/product-name) to categorised URLs (/category/product-name), or removing date-based blog URLs.

Risk level: Medium. Fewer variables than a full platform migration, but every changed URL still requires a redirect and monitoring.

Protocol Change (HTTP to HTTPS)

Moving from HTTP to HTTPS. In 2026, most sites have already made this transition, but some legacy sites still need it.

Risk level: Low to medium. Straightforward if done correctly with proper redirects and canonical tag updates.

Pre-Migration Planning

The majority of migration SEO work happens before launch day. I typically spend 60 to 70 per cent of total project time on pre-migration preparation. Rushing this phase is the single most common cause of migration failure.

Step 1: Benchmark Your Current Performance

Before changing anything, document your current organic performance in detail. You need this data to measure whether the migration was successful and to identify any problems after launch.

Record the following:

• Organic traffic by page. Export your top 200 organic landing pages from Google Analytics with monthly traffic figures for the past 12 months
• Keyword rankings. Export current rankings for your top 100 to 200 target keywords
• Indexed pages. Note the total number of indexed pages from Google Search Console's Index Coverage report
• Backlink profile. Export your complete backlink profile from Ahrefs or SEMrush, including which URLs receive the most links
• Search Console performance. Export clicks, impressions, CTR, and average position data for the past 16 months (the maximum Search Console retains)
• Core Web Vitals scores. Record current CWV pass rates from Search Console's Core Web Vitals report

I save this data in a shared spreadsheet that both my team and the client can reference throughout the migration project. If something goes wrong after launch, this benchmark is your diagnostic baseline.

Step 2: Complete URL Inventory

Crawl your entire current site using Screaming Frog or a similar technical SEO crawler. This gives you a complete list of every URL on your site, including pages you may have forgotten about.

Your crawl should capture:

• All HTML pages (including thin or orphaned pages)
• All URLs returning 200 status codes
• Current redirect chains already in place
• All canonical tag declarations
• All meta robots directives
• All structured data on each page

Cross-reference the crawl data with your sitemap, Google Search Console index data, and Analytics data. The goal is to identify every URL that either receives traffic, has backlinks pointing to it, or is indexed by Google. Every one of these URLs needs a plan: either migrate it, redirect it, or intentionally remove it.

Step 3: Content Audit and Consolidation

A migration is an excellent opportunity to clean up your content. Rather than migrating every page including thin, outdated, or duplicate content, audit your content and make strategic decisions.

For each page, decide:

• Migrate as-is: The page performs well, has backlinks, and the content is current
• Migrate and improve: The page has value but content needs updating
• Consolidate: Multiple pages covering the same topic should be merged into one stronger page, with old URLs redirecting to the consolidated page
• Remove: The page has no traffic, no backlinks, and no strategic value. Remove it and either redirect to the nearest relevant page or let it return a 410 (Gone) status

I typically find that 15 to 30 per cent of pages on an Australian business website can be consolidated or removed during a migration, resulting in a leaner, stronger site.

Building Your Redirect Map

The redirect map is the most critical deliverable in any migration. It is a document that specifies exactly where every old URL should point after the migration. Getting this wrong is the primary cause of traffic loss.

How to Build It

1. Start with your complete URL inventory from the crawl
2. Map each old URL to its new equivalent. This must be done page by page. Never redirect all old URLs to the homepage. Never redirect all old URLs to the nearest category. Each old URL should point to the specific new page that contains the same or most similar content
3. Prioritise high-value URLs. Sort your URLs by organic traffic and backlinks. Your top 100 URLs should receive the most careful attention because they carry the most SEO value
4. Handle URLs with no equivalent. If a page is being removed with no direct replacement, redirect it to the next most relevant page. If nothing is relevant, a 410 Gone status is more honest than a forced redirect to an unrelated page
5. Document everything. Your redirect map should be a spreadsheet with columns for: old URL, new URL, status code (301), reason, and priority level

Redirect Best Practices

• Use 301 (permanent) redirects for all migration redirects. A 301 tells Google and users that the page has permanently moved. Do not use 302 (temporary) redirects for migration
• Avoid redirect chains. If URL A already redirects to URL B, and you are now migrating URL B to URL C, update the redirect so URL A goes directly to URL C. Chains slow down crawling and dilute link equity
• Keep redirects live indefinitely. The old advice was to maintain redirects for one year. In practice, I recommend keeping them live permanently. Backlinks from external sites will continue pointing to old URLs for years, and removing redirects means those links send users to 404 pages
• Test before launch. Every redirect in your map should be tested on the staging or development environment before going live. I have caught errors in redirect maps on every migration project I have worked on

Regex Redirects

For large sites with thousands of URLs following predictable patterns, regex (regular expression) redirects can save time. For example, if every blog post URL is changing from /blog/2024/post-title to /blog/post-title, a single regex rule can handle all of them.

However, regex redirects are dangerous if written incorrectly. A badly formed regex can redirect pages you did not intend to redirect, including your homepage. I always test regex rules against the full URL inventory before deploying them.

Technical Migration Checklist

Beyond redirects, several technical elements need attention during migration. Missing any of these can cause ranking drops that take months to diagnose.

Before Launch

• Robots.txt: Verify that the new site's robots.txt does not block important pages or resources. A surprisingly common mistake is deploying a staging robots.txt that blocks all crawling
• Canonical tags: Every page on the new site must have correct self-referencing canonical tags pointing to the new URLs. Do not leave canonical tags pointing to old URLs
• XML sitemap: Create a new sitemap containing only the new URLs. Remove old URLs. Submit the new sitemap through Google Search Console immediately after launch
• Structured data: Verify that all schema markup migrated correctly. CMS migrations frequently break structured data because templates change
• Internal links: Update all internal links to point to new URLs directly, not through redirects. Internal links that go through redirects waste crawl budget and create unnecessary latency
• Meta tags: Verify that title tags and meta descriptions migrated correctly. CMS migrations can reset these to defaults or auto-generated values
• Hreflang tags: If your site targets both Australia and New Zealand with hreflang annotations, verify these transferred correctly
• HTTPS: Ensure all new URLs serve over HTTPS with valid SSL certificates. Mixed content warnings can appear when migrating older sites

Staging Environment Testing

Before going live, test the new site in a staging environment with these checks:

1. Crawl the staging site with Screaming Frog to verify no broken links, missing pages, or technical errors
2. Test all redirects against your redirect map
3. Verify structured data using Google's Rich Results Test
4. Test page speed using Lighthouse to confirm Core Web Vitals pass
5. Check mobile rendering to ensure responsive design works correctly
6. Verify that analytics tracking code is installed and firing correctly
7. Confirm that form submissions, eCommerce checkout, and other conversion paths work

I have a staging QA process that takes 2 to 3 days for a standard business site and up to 2 weeks for large eCommerce sites. This investment pays for itself many times over by catching issues before they affect live traffic.

Launch Day Process

Launch day should be controlled and methodical. This is not the time for surprises.

Launch Sequence

1. Deploy the new site during low-traffic hours. For most Australian businesses, this means early morning between 2am and 6am AEST
2. Enable all redirects simultaneously. There should be no period where old URLs return 404 errors
3. Test the top 50 redirects manually by visiting old URLs and verifying they resolve to the correct new pages
4. Submit the new XML sitemap in Google Search Console
5. Request indexing for your most important pages using the URL Inspection tool in Search Console
6. Monitor server logs for 404 errors, 500 errors, and redirect loops in real time
7. Verify analytics tracking is recording visits correctly

What to Watch For

In the first 24 hours after launch, watch for:

• Spike in 404 errors in Search Console or server logs. This means redirects are missing
• Redirect loops where URL A redirects to URL B which redirects back to URL A. Browsers show "too many redirects" errors
• Broken functionality such as forms not submitting, shopping carts not working, or JavaScript errors. These affect user experience and conversions
• Analytics data gaps where traffic appears to drop because tracking is not installed correctly on the new site

Post-Migration Monitoring and Recovery

The migration is not complete on launch day. The real work of monitoring and recovery happens over the following weeks and months.

Week 1: Daily Monitoring

Check these metrics daily during the first week:

• Crawl stats in Search Console. Google should be discovering and crawling the new URLs. If crawl rate drops dramatically, something is blocking access
• Index coverage. Watch for increases in "Excluded" or "Error" URLs in the Index Coverage report. New pages should start appearing as "Valid"
• 404 errors. Monitor the Pages report in Search Console for URLs returning 404. Every 404 on a previously indexed URL represents lost traffic
• Organic traffic. Compare daily organic traffic to the same day in the previous week. Some fluctuation is normal, but drops exceeding 20 per cent require immediate investigation

Weeks 2 to 4: Stabilisation

During this period, Google is processing your redirects and re-evaluating the new site:

• Rankings may fluctuate. It is normal for rankings to shift during the first month as Google processes the migration. Do not panic if individual keywords drop temporarily
• Monitor your redirect map. Check that high-value redirects are being followed correctly. Use server log analysis to verify Googlebot is crawling old URLs and following redirects to new ones
• Watch for cannibalisation. If both old and new URLs appear in search results for the same query, your redirects may not be processing correctly
• Continue submitting important pages. Use the URL Inspection tool to request indexing for pages that have not been picked up yet

Months 2 to 6: Recovery Assessment

Compare your current metrics against your pre-migration benchmarks:

• Organic traffic should return to within 90 to 100 per cent of pre-migration levels within 4 to 8 weeks for a well-executed migration
• Keyword rankings should stabilise within 4 to 12 weeks
• Indexed page count should match the expected number of new pages (accounting for pages intentionally removed)
• Backlink profile should show links being attributed to new URLs

If traffic has not recovered after 8 weeks, investigate systematically. Check my guide on diagnosing declining organic traffic for a structured troubleshooting approach. Common post-migration causes include missed redirects, content quality changes, and technical issues on the new platform.

Common Migration Mistakes

After managing more than 20 migrations, these are the mistakes I see most frequently, including several I have been called in to fix after another provider handled the migration.

Redirecting Everything to the Homepage

This is the most destructive mistake. Instead of creating page-to-page redirects, all old URLs redirect to the homepage. Google treats this as a soft 404 because the destination content does not match the original. You lose the ranking signals from every page that was incorrectly redirected.

I was brought in to recover a migration for an Australian eCommerce client where the previous agency redirected 4,500 product URLs to the homepage. Traffic dropped 73 per cent within two weeks. Recovery took eight months and required rebuilding the entire redirect map from backlink and analytics data.

No Redirects at All

Some redesigns go live without any redirect plan. The old URLs return 404 errors, and all accumulated link equity and rankings evaporate. This happens more often than you would expect, particularly when a business hires a web designer who does not understand SEO.

Changing Content During Migration

Migrating to a new platform and simultaneously rewriting all your content doubles the variables and makes it impossible to diagnose problems. If rankings drop, you cannot tell whether the issue is technical (redirects, crawling) or content-related (quality, relevance).

I strongly recommend migrating content as-is, then making content improvements after the migration has stabilised. Keep one variable at a time.

Blocking the New Site From Crawling

Staging environments typically have a robots.txt that blocks all search engine crawling. If this staging robots.txt is deployed to the live site, Google cannot crawl any pages. I have seen this happen three times in my career, and in each case, the business did not notice for days because the site looked fine to human visitors.

Ignoring the Old Site

After launch, some businesses immediately shut down the old server or domain. If redirects are implemented at the DNS or CDN level, this may not cause issues. But if redirects depend on the old server, taking it offline breaks every redirect. Keep the old infrastructure running for at least 12 months.

Not Involving SEO Early Enough

The ideal time to involve SEO in a migration project is at the planning stage, before any design or development work begins. If SEO is brought in the week before launch, there is not enough time to build redirect maps, audit content, or test properly.

In my practice, I ask to be involved from the moment a migration is being considered. The URL structure, information architecture, and content strategy for the new site should all be informed by SEO data. This is a core part of every technical SEO engagement I take on.

Frequently Asked Questions

How long does it take to recover from a site migration?

A well-executed migration typically sees traffic return to pre-migration levels within 4 to 8 weeks. Google needs time to process redirects, re-crawl the new site, and update its index. During this period, ranking fluctuations are normal. Poorly executed migrations can take 6 to 18 months to recover, and industry data shows that 17 per cent of sites never fully recover. The recovery timeline depends primarily on how comprehensive your redirect map is, whether content was preserved, and how quickly you identify and fix post-launch issues.

Do site migrations always cause traffic drops?

Not necessarily. A properly planned migration with comprehensive redirect mapping, content parity, and technical accuracy can maintain 95 to 100 per cent of organic traffic. I have managed migrations that showed no measurable traffic drop. However, some temporary fluctuation during the first 2 to 4 weeks is common even in successful migrations as Google processes the changes. The key is preparation: thorough URL mapping, complete redirect testing, and rapid post-launch monitoring.

Should I change my URL structure during a migration?

Only if there is a genuine strategic reason to do so. Every URL change requires a redirect and carries risk. If your current URL structure works well for users and search engines, keep it. If your URLs are genuinely problematic (extremely long, lacking keywords, or creating duplicate content), a migration is a convenient time to fix them. But do not change URLs purely for cosmetic reasons. The SEO risk rarely justifies the benefit of a "cleaner" URL format.

How many redirects can a site handle?

There is no practical limit to the number of 301 redirects a site can have. I have implemented redirect maps with more than 10,000 entries without performance issues. The important considerations are implementation method (server-level redirects via .htaccess or nginx config are faster than plugin-based redirects) and avoiding redirect chains (each URL should redirect in a single hop to its final destination). If your site has thousands of redirects, server-level implementation is essential for performance.

Can I remove redirects after migration?

I recommend keeping migration redirects live permanently. External backlinks pointing to your old URLs will continue to exist for years, and removing redirects means those links lead to 404 pages, wasting link equity. Server-side redirects have negligible performance impact even in large quantities. The only scenario where I recommend removing redirects is when the old URLs have zero backlinks and zero traffic after 12 or more months, and you have confirmed this through both analytics and backlink data.

Should I hire an SEO consultant for a site migration?

If your website generates meaningful revenue or leads from organic search, involving an SEO professional in your migration is one of the highest-ROI investments you can make. The cost of a migration engagement (typically $3,000 to $8,000 for an Australian SME site) is a fraction of the revenue loss from a botched migration. At minimum, have an SEO practitioner review your redirect map and technical checklist before launch. For complex migrations involving thousands of pages, domain changes, or platform switches, having SEO involved from the planning stage is essential.