A website migration is one of the highest-risk activities in SEO. Change a URL structure, swap a CMS or move to a new domain and you’re essentially asking Google to re-evaluate your entire site. Get it wrong and you’ll watch months – sometimes years – of organic growth evaporate. Studies consistently show that poorly planned migrations can cause 30–50% traffic drops, with recovery timelines stretching anywhere from a few weeks to six months or longer for large sites.
The good news: most of that damage is preventable. The sites that lose traffic almost always share the same handful of mistakes – incomplete redirect maps, blocked crawling on launch day, stripped metadata, broken internal links. This checklist walks through every phase of a migration so you can move without the freefall.
What counts as a website migration?
Not every change qualifies. A migration is any structural change that affects how search engines discover, crawl or index your pages. The main types include:
Domain change – moving from one domain to another (rebranding, acquiring a new TLD, consolidating multiple domains into one).
Protocol change – switching from HTTP to HTTPS.
CMS or platform change – replatforming from one content management system to another (e.g. WordPress to Shopify, custom-built to headless CMS).
URL structure change – restructuring your site architecture, changing folder paths, removing subdomains or altering URL slugs.
Site redesign with URL changes – a visual overhaul that also moves or renames pages.
Subdomain to subdirectory (or vice versa) – shifting blog.example.com to example.com/blog, for instance.
Content consolidation – merging two or more sites into a single domain.
The bigger the change, the bigger the risk. A domain change carries far more SEO weight than a simple HTTPS switch. Google’s own documentation recommends tackling one change at a time wherever possible – don’t rebrand, replatform and restructure URLs in a single launch if you can avoid it.
Why does SEO matter so much during a migration?
Every indexed URL on your site carries equity: backlinks pointing to it, ranking signals associated with it, and internal link weight flowing through it. When a URL changes and no redirect exists, that equity vanishes. Multiply that across hundreds or thousands of pages and you’ve got a serious problem.
Beyond traditional search, there’s a newer consideration. AI-powered search engines and LLMs now cite specific URLs as sources. If those URLs break during a migration, your content loses its AI citation trail too. Brand mentions and URL stability both feed into whether language models reference your site in generated answers, so a botched migration doesn’t just hurt Google rankings – it can reduce your visibility in AI search as well.
The financial impact is real. Even a well-executed migration typically sees a 2–4 week period of ranking volatility. A poorly executed one can mean months of depressed revenue, emergency link building to recover lost equity, and significant time spent firefighting issues that should have been caught before launch. For e-commerce sites, the stakes are even higher – a migration timed during peak trading season without proper planning can wipe out a quarter’s revenue targets.
Phase 1: Pre-Migration Planning
This is where most of the work happens. A migration is won or lost in the planning stage.
1. Define the scope and migration type
Pin down exactly what’s changing. Is this a domain move, a CMS swap, a URL restructure, or a combination? Document every change explicitly. The more variables you introduce simultaneously, the harder it becomes to diagnose problems later.
Create a single-page scope document that lists every change being made, who owns each workstream and the expected timeline. This becomes your reference point when things go sideways – and they often do.
2. Assemble the right stakeholders
Migrations touch development, design, content, SEO, paid media and sometimes legal. Set up a shared project timeline with clear ownership for each workstream. The most common cause of migration failures isn’t technical – it’s communication gaps between teams.
Weekly migration standups, a shared Slack or Teams channel, and a single project tracker are the minimum. The SEO lead needs direct access to the development team – not filtered through three layers of project management.
3. Benchmark current performance
Before you change anything, snapshot everything:
Organic traffic by landing page (Google Analytics, 12 months minimum)
Keyword rankings for your target terms
Crawl stats from Google Search Console (indexed pages, crawl rate, coverage issues)
Top-performing pages by revenue, leads or conversions
Core Web Vitals scores – these are covered in their own article, but note your current scores so you can spot regressions post-launch
Backlink profile – export your top linked-to pages and their referring domains
This data becomes your baseline. Without it, you can’t measure whether the migration succeeded or identify exactly where things went wrong.
4. Run a full site crawl and build your URL inventory
Crawl your current site with a tool like Screaming Frog or Sitebulb. Export every URL, its status code, title tag, meta description, H1, canonical tag and internal links. This is your source of truth for the redirect map.
Don’t just crawl HTML pages. Pull in:
Image URLs – if image paths are changing, you need redirects for those too. Broken image URLs mean lost visibility in Google Images and broken image sitemaps.
PDF and document URLs – these often carry backlinks and rank independently.
JavaScript and CSS resources – relevant if you’re changing CDN or file structure.
5. Build your 301 redirect map
This is the single most important deliverable in any migration. Map every old URL to its most relevant new equivalent. Rules of thumb:
One-to-one mapping wherever possible. Don’t redirect everything to the homepage – Google treats that as a soft 404.
Avoid redirect chains. If Page A already redirects to Page B, and now Page B is moving to Page C, update the original redirect so Page A goes directly to Page C.
Avoid redirect loops. Test your map for circular references before implementation.
Include non-200 URLs that have backlinks. Check your backlink data – if old 404 pages still have inbound links, redirect those too.
For large sites (10,000+ pages), prioritise by traffic and backlink value. Every page matters, but pages with zero traffic and zero links are lower priority than your top 500 earners.
6. Audit and prune your content
A migration is the perfect time to thin out your content library. Rather than migrating every page, assess what’s actually worth keeping:
Keep and migrate as-is – pages with strong traffic, rankings, backlinks or conversion value.
Update and migrate – pages with potential but outdated content, thin copy or poor structure.
Consolidate – merge pages covering the same topic into a single, stronger page. Redirect the retired URLs to the consolidated version.
Retire – pages with no traffic, no backlinks and no strategic purpose. Redirect these to the most relevant parent page or let them return a 410 (gone) status.
Pruning before migration means you’re not wasting redirect budget on dead weight, and the new site launches with a cleaner, more focused content footprint.
Use your analytics and crawl data to make these decisions. Sort pages by organic sessions over the past 12 months, cross-reference with backlink counts, and you’ll quickly see which pages are pulling their weight and which are just taking up server space. For most sites, 20–30% of pages drive the vast majority of organic value. The rest is candidate material for consolidation or retirement.
7. Preserve on-page SEO elements
Create a mapping document (or add columns to your URL inventory) that records for each page:
Title tag
Meta description
H1 tag
Open Graph and Twitter Card metadata
Image alt text
Internal links within the body copy
The goal is zero loss of on-page signals. Template changes during redesigns are notorious for wiping metadata or changing heading hierarchies. Catch this in staging, not production.
8. Plan canonical tag handling
Canonical tags need to reflect the new URL structure from day one. Ensure every page on the new site self-canonicalises to its own new URL. Leftover canonicals pointing to old URLs – or worse, to the staging domain – will cause indexing chaos. Canonical tags have their own article on the site, so we won’t go deep here, but double-check them during staging QA.
9. Prepare your XML sitemap
Have an updated XML sitemap ready that includes only the new URLs. Remove any old URLs and staging URLs before submission. XML sitemaps are covered in detail elsewhere, but the key point for migrations is timing: submit the new sitemap to Google Search Console immediately after launch.
10. Review robots.txt
Your new robots.txt must allow crawling of all pages you want indexed. A common disaster: the staging site’s robots.txt (which blocks all crawlers) gets pushed to production. Check this before and immediately after launch. Robots.txt has its own dedicated article if you need the full breakdown.
11. Set up the staging environment
Build and test the new site on a staging server. The staging environment should:
Block search engine crawlers (via robots.txt, HTTP authentication or IP restriction – not just a noindex tag)
Mirror the final URL structure exactly
Include all redirects so they can be tested before go-live
Have all tracking codes and analytics in place for testing
12. Handle hreflang tags (international sites)
If you serve multiple languages or regions, update all hreflang annotations to reflect new URLs. Every hreflang tag must point to a valid, accessible page. Mismatched hreflang signals post-migration can cause entire language versions to drop from search results.
This is one of the most commonly botched elements of international migrations. If you implement hreflang via XML sitemaps, both the sitemap references and any on-page hreflang tags need updating. If you use HTTP headers for hreflang (common for PDFs), those need attention too.
13. Plan your schema markup migration
Structured data needs to move with your pages. If your schema references specific URLs (breadcrumbs, FAQ pages, article URLs), update those references. Schema markup is covered in its own article, but don’t let it fall through the cracks during migration planning.
14. Coordinate PPC and paid campaigns
This is a step most SEO checklists miss entirely. If you’re running Google Ads, Microsoft Ads or social ad campaigns:
Map all landing page URLs used in active campaigns to their new equivalents.
Update ad URLs and extensions before launch, or pause campaigns and reactivate with new URLs immediately after.
Plan for conversion tracking – tags, pixels and goals all need transferring to the new site. Run test conversions on staging.
Consider pausing campaigns on launch day and reactivating with branded campaigns first as a controlled test. Most paid teams aim to be back live within 48 hours.
Budget for a potential CPR (cost-per-result) spike in the first week as quality scores recalibrate.
Aligning SEO and PPC timelines prevents the scenario where ads drive traffic to broken pages while organic rankings are still settling.
15. Address local SEO considerations
For businesses with physical locations, a migration can disrupt local SEO signals:
Google Business Profile – update your website URL immediately post-migration. If you’re changing domain, update it across all GBP listings.
NAP consistency – if the migration coincides with any change to your business name, address or phone number, update citations across all directories simultaneously.
Local landing pages – ensure location-specific pages are properly redirected and their content, schema and metadata are preserved.
Third-party citations – Yell, Bing Places, Apple Maps, industry directories. These take time to update, so start the process before launch.
16. Lower DNS TTL values
In the week before launch, progressively lower your DNS Time-to-Live settings:
7 days before: drop to 86,400 seconds (24 hours) if currently higher.
3 days before: reduce to 3,600 seconds (1 hour).
24 hours before: reduce to 300 seconds (5 minutes).
This ensures DNS changes propagate quickly on launch day. After the migration is stable (give it a few days), raise TTL back to normal levels to reduce DNS query overhead.
Phase 2: During Migration (Launch Day)
Launch day is about execution, monitoring and rapid response. The planning phase should mean there are no surprises – but have the team on standby regardless.
17. Deploy redirects and verify them
Push your 301 redirect map to the live server. Then test immediately:
Spot-check a sample of redirects manually (high-traffic pages, key landing pages, pages with backlinks).
Run a bulk redirect checker against your full URL list to confirm status codes.
Check for redirect chains and loops in the live environment.
Verify that non-www/www and HTTP/HTTPS variants all resolve correctly.
18. Push the new robots.txt live
Confirm the production robots.txt allows crawling. If you’re unsure, use Google Search Console’s robots.txt tester to validate. One blocked Disallow line in the wrong place can prevent your entire site from being indexed.
19. Submit the new XML sitemap
In Google Search Console:
Remove or mark the old sitemap as outdated.
Submit your new sitemap with updated URLs.
If you’re changing domain, add and verify the new property in Search Console.
20. Verify canonical tags on live pages
Spot-check canonical tags across key page templates (homepage, category pages, product pages, blog posts). Confirm they self-reference using the new URL and don’t point to old URLs, staging URLs or incorrect variants.
21. Check meta tags and on-page elements
Verify a cross-section of pages for:
Title tags matching your mapping document
Meta descriptions preserved
H1 tags correct
Image alt text intact
Open Graph tags updated
Template-level errors can wipe out metadata across hundreds of pages in one go, so check at least one page per template type.
22. Confirm analytics and tracking
Verify Google Analytics (GA4) is firing on the new site.
Check that goals, events and e-commerce tracking are recording correctly.
Confirm Google Tag Manager (if used) has been deployed.
Test conversion tracking for any active paid campaigns.
If using call tracking, verify numbers are rendering properly.
23. Validate structured data
Run a sample of pages through Google’s Rich Results Test or Schema Markup Validator. Confirm schema is rendering correctly and that no URLs within the markup point to old or staging domains.
24. Update Google Search Console
If you’ve changed domain:
Use the Change of Address tool in Search Console on the old property.
Verify ownership of both old and new properties.
Monitor both properties for the next 6–12 months.
If you’ve stayed on the same domain but changed URL structure, resubmit your sitemap and use the URL Inspection tool to request indexing of your highest-priority pages.
25. Handle image SEO
Images are often the forgotten casualty of a migration:
If image URLs have changed, ensure 301 redirects are in place for old image paths.
Verify image alt text hasn’t been stripped during the CMS switch.
Update your image sitemap (or include images in your main sitemap).
Check that image file formats and compression haven’t degraded – a CMS change can sometimes alter image processing pipelines.
If you use a CDN for images, confirm CDN URLs are resolving correctly and that any CDN-level caching has been purged.
For sites with significant Google Images traffic, image migration errors can represent a meaningful chunk of lost visibility. Don’t treat images as an afterthought.
Phase 3: Post-Migration Monitoring
The migration isn’t done when the site goes live. The first 2–4 weeks are where you catch and fix the issues that slipped through.
26. Run a full post-migration crawl
Within 24–48 hours of launch, crawl the entire new site. Compare against your pre-migration crawl to check for:
Missing pages – anything that exists in the old crawl but not the new one.
Broken internal links – links pointing to old URLs that aren’t redirecting properly.
Orphaned pages – new pages with no internal links pointing to them.
Status code issues – unexpected 404s, 500 errors, redirect chains.
Duplicate content – check for old and new versions both being accessible (e.g. staging URLs leaking into the index). Duplicate content has its own article for the full picture.
27. Monitor Google Search Console daily
For the first two weeks, check Search Console every day:
Coverage report – watch for spikes in “Excluded” or “Error” pages.
Crawl stats – confirm Google is discovering and crawling the new URLs at a healthy rate. A drop in crawl rate could indicate a problem.
Index status – track how many new URLs are being indexed and how many old URLs are being dropped.
Crawl errors are covered in their own dedicated article, but during the post-migration window you should be treating any new errors as high priority.
28. Track organic traffic against your baseline
Compare organic sessions, landing page performance and conversion rates against your pre-migration benchmarks. Some volatility in the first 2–4 weeks is normal – Google needs time to re-crawl, re-index and reassess.
What’s not normal:
A sustained drop beyond 4 weeks – investigate redirect coverage, indexing issues or lost metadata.
Specific page groups tanking – often points to a template-level issue (stripped titles, wrong canonicals, noindex tags).
Branded traffic down – could indicate DNS issues, Search Console misconfiguration or domain authority not transferring.
29. Monitor keyword rankings
Track your priority keywords daily for the first month. Look for:
Rankings that dropped and aren’t recovering – cross-reference with redirect coverage.
Keywords now ranking for the wrong page – usually a redirect mapping error or canonicalisation issue.
New 404s appearing in rank tracking tools – pages that were missed in your redirect map.
30. Check backlink integrity
Use Ahrefs, Semrush or a similar tool to verify your top backlinks are resolving to live pages (not 404s). If external links are hitting old URLs, confirm those URLs redirect correctly. You can’t control when third-party sites update their links, so redirects need to stay in place indefinitely for your most valuable backlinks.
31. Audit internal links
Internal links are often updated in templates but missed in body content. Crawl the site looking for links that 302 or 301 through old URLs. While redirects pass equity, direct links to the final URL are cleaner and faster for crawlers. Update internal links in body copy over the first few weeks. This is tedious work on large sites, but it reduces unnecessary server-side redirect processing and gives crawlers a cleaner path through your site architecture.
32. Validate site speed and performance
A new CMS, hosting environment or design can change load times significantly. Site speed has its own article, but for migration purposes: compare your current scores against the pre-migration baseline and flag any regressions immediately. Pay attention to server response times (TTFB) – new hosting infrastructure sometimes needs tuning.
33. Test on multiple devices and browsers
Rendering issues that don’t show up in desktop Chrome can break experiences on mobile, Safari or older browsers. If your new site relies more heavily on JavaScript for rendering, check that search engines can see your content. JavaScript SEO is a topic in its own right, but a quick check with Google’s URL Inspection tool (which shows the rendered page) will flag any major issues.
34. Monitor local listings and citations
If you’ve updated Google Business Profile and directory listings, verify the changes have taken effect:
Check your GBP listing shows the correct website URL.
Spot-check key directories (Yell, Thomson Local, Bing Places) for updated URLs.
Monitor local pack rankings for any drops.
35. Re-submit to AI and LLM platforms
This is a step that barely existed two years ago but matters now. If your site is referenced by AI search tools (Bing Chat, Google AI Overviews, Perplexity, ChatGPT):
Ensure your new pages are crawlable by AI user agents (check robots.txt for AI-specific crawlers like GPTBot, Google-Extended).
If you’ve changed URL structure significantly, your old AI citations will break. The faster new pages get indexed and cited, the less visibility you lose.
Structured data, clear entity markup and authoritative content all help LLMs pick up your new URLs as citation sources.
Brand search volume is one of the strongest predictors of AI citation frequency. If your migration coincides with a rebrand, invest in brand awareness campaigns to rebuild that signal.
What kind of traffic drop should you expect?
Even with a well-executed migration, expect some turbulence:
Small sites (under 500 pages): Rankings typically stabilise within 2–4 weeks. You might see a 5–15% dip in organic traffic during the transition.
Medium sites (500–10,000 pages): Allow 4–8 weeks for full recovery. Dips of 10–20% are common even when everything is done correctly.
Large sites (10,000+ pages): Recovery can take 3–6 months. The sheer volume of URLs means Google takes longer to re-crawl and re-index everything. Phased migrations – moving sections of the site one at a time – can reduce peak disruption.
If you’re still down after 8 weeks with no signs of recovery, something structural is wrong. Go back to basics: check redirect coverage, crawl the site for errors, verify indexing in Search Console and audit your metadata.
A useful diagnostic approach: segment your traffic by page type. If blog posts recovered but product pages didn’t, that points to a template-level problem on product pages specifically. If all pages in a subfolder tanked, check whether that subfolder was inadvertently blocked in robots.txt or carrying incorrect canonical tags. Pattern recognition beats page-by-page troubleshooting every time.
Should you run a phased migration?
For larger sites or e-commerce SEO setups with thousands of product pages, a phased approach can limit risk. Migrate one section (e.g. the blog, or one product category) first, monitor for a week, then move the next section.
The trade-off is complexity. You’ll have a period where parts of the site are on the old platform and parts are on the new one, which can create odd user journeys and complicate internal linking. Cross-platform redirects between old and new sections also need careful handling to avoid loops.
For most small-to-medium sites, a single-launch migration is simpler and equally safe if the planning has been thorough. Reserve the phased approach for sites where the sheer page volume makes a single-day migration logistically impractical or where the business can’t afford even a brief period of full-site disruption.
How does a migration affect link equity?
301 redirects pass the vast majority of link equity from the old URL to the new one. Google’s John Mueller has confirmed that 301s, 302s and JavaScript redirects all pass PageRank, though 301s remain the standard recommendation because they signal a permanent move.
What does lose equity:
Redirect chains – each hop in a chain can dilute signals slightly, and long chains increase crawl latency.
Redirects to irrelevant pages – redirecting a blog post about London restaurants to your homepage won’t preserve topical relevance.
Dropped pages with no redirect – a 404 with inbound links is pure equity waste.
This is why the redirect map is the most critical document in the entire process. Treat it with the same care you’d give a financial audit – every row matters, and a single oversight can cost months of recovery work.
What about technical SEO audits after migration?
A full technical SEO audit 30 days post-migration is strongly recommended. By that point, Google has had time to process most of the changes, and you’ll have enough data in Search Console and Analytics to spot patterns rather than noise.
Focus the audit on:
Redirect coverage – are there old URLs still returning 404s that should be redirecting?
Index bloat – has the migration created duplicate or near-duplicate pages?
Crawl budget – is Google spending time on redirect chains or low-value pages instead of your priority content?
Rendering – are all pages rendering correctly for Googlebot?
Structured data errors – has the migration introduced new validation errors?
The migration is done – now what?
Keep your redirects in place. There’s a persistent myth that you can remove 301 redirects after a few months. Don’t. External sites will continue linking to your old URLs for years. Removing redirects means losing that link equity permanently.
Continue monitoring Search Console and organic traffic for at least six months. Some ranking shifts only become apparent as Google fully recalculates signals across your new URL structure.
And document everything. Record what changed, what went well, what went wrong, and what you’d do differently. Include specific numbers: how much traffic dropped, when it recovered, which redirect errors caused the most damage, how long the full process took from planning to stabilisation. The next migration might be years away, but when it arrives, having a detailed record of this one will save enormous amounts of time.
A site migration doesn’t have to mean a traffic disaster. With proper planning, thorough redirect mapping and disciplined post-launch monitoring, you can move to a new platform, domain or URL structure without losing the organic visibility you’ve spent years building.
