SEO Migration Checklist: How to Protect Rankings During a Website Migration

Introduction: what an SEO migration really involves

A website migration covers any change that affects how search engines crawl, index, and understand your site. That includes domain moves, protocol changes like HTTP to HTTPS, content management system replatforming, redesigns that alter url structure, site structure overhauls, and even something as seemingly minor as a WordPress theme swap. Each of these can disrupt search engine rankings and organic traffic if redirects, metadata, and tracking are not handled properly.

The stakes are real. Research shows that website migration can lead to a 44% drop in organic traffic when SEO planning is absent or poorly executed. A poorly executed migration can devastate online visibility, sometimes taking months to recover from or, in the worst cases, never fully recovering at all. SEO migration prevents losing search engine rankings and traffic by ensuring every technical and content detail is accounted for before, during, and after the switch.

This migration seo checklist is based on how Gareth and RedShaw Consulting run technical SEO migrations for lead-generation and content sites. It is a practical, step-by-step guide covering pre migration planning, staging environment work, launch day operations, and post launch monitoring. A proper SEO migration can lead to long-term positive SEO impact when done with discipline, but that outcome depends on doing the groundwork correctly.

If you are planning a complex site migration and want hands-on support, you can reach RedShaw Consulting via the contact page.

Before you start: define scope, risks and success criteria

Every successful website migration starts with clear scope. Before any design or development work begins, stakeholders need to agree on what type of migration is happening, what it is expected to achieve, and how success will be measured. Skipping this step is how projects drift and rankings get damaged.

Start by defining the migration type: is this a domain migration, a protocol change, a CMS replatform to WordPress, a url structure overhaul, or a full redesign? Each carries a different risk profile. Then document the business drivers. Are you improving mobile UX, consolidating regional sites, fixing legacy technical SEO issues, or improving site speed? Map each driver to a measurable KPI.

You should establish baseline analytics two to four weeks before migration at minimum, though three to six months of historical data from google analytics and google search console gives you a much stronger foundation. Recording current organic traffic is essential for post-launch comparison. Capture top landing pages, conversion rates, keyword rankings, and backlink profiles.

Set explicit success criteria:

• Limit organic traffic dip to no more than 10–15% in the first four weeks
• Full recovery to pre-migration levels within 8–12 weeks
• Maintain conversion rates within an acceptable margin of baseline
• No loss of keyword rankings beyond 10 positions for core terms

Finally, list key risks and assign named owners:

• Loss of search engine visibility due to missing redirects
• Staging site indexation creating duplicate content
• Tracking breaks causing phantom traffic loss
• Redirect loops or chains leaking link equity

These questions must be answered before green-lighting the migration process.

Plan the migration timing and project governance

Poor timing and weak project management are major causes of failed site migrations. Choose your window carefully.

Use at least two years of google analytics data to identify seasonal lows. For lead-generation sites, that might be mid-January or late August. Avoid peak sales periods, public holidays, and active marketing campaigns. Do not launch a new website during Black Friday week or the week before a major industry event where your team’s attention is split.

Schedule migration for a weekday afternoon or evening in your primary market’s time zone, when your technical team, SEO lead, web developers, and hosting providers are all available. Avoid Fridays. If something breaks on Saturday morning, you want people ready to fix it.

Build a project plan with clear phases:

• Discovery and content inventory
• Technical SEO audit of the existing website
• Staging build and QA
• Redirect mapping
• Launch
• Post launch monitoring

Assign named owners for SEO, development, content, design, analytics, and stakeholder communication. Set up a dedicated Slack or Teams channel and a single written runbook for launch day covering every step and rollback procedure.

Audit the old site: content, URLs and analytics baselines

A thorough audit of the old site is the foundation of any successful site migration. Without it, you are guessing which pages matter and which redirects to prioritise.

Run a full site crawl using a tool like Screaming Frog or Sitebulb to export all the urls: indexable and non-indexable pages, status codes, titles, meta descriptions, canonical tags, H1s, and hreflang tags where relevant. Create a list of your current URLs for mapping against the new site structure.

Merge crawl data with google analytics, google search console, and backlink data from tools like Ahrefs or SEMrush. This tells you which pages drive website traffic, conversions, and link equity. Identifying outdated or low-performing pages aids in content optimization before migration, letting you consolidate thin or duplicate content rather than carrying dead weight into the new build.

Create a master URL inventory spreadsheet containing:

• Old URL and new URL mapping
• HTTP status code
• Organic sessions and conversions
• Backlink count and referring domain quality
• Whether the page must be preserved 1:1, consolidated, or retired

Baseline current keyword rankings, organic traffic by landing page, and conversion rates. A full backup of the website allows for quick recovery in case of failure, so take a complete backup of files and database, and ideally download a static HTML copy of the old site before anything changes.

Design the new site structure and URL strategy

Revisiting site structure during a migration is a significant opportunity to improve topical authority and user experience, but it is also where many sites lose rankings through careless changes.

• Sketch the new site architecture: homepage to primary categories to subcategories to content pages. Ensure important commercial and informational pages sit within three clicks from the homepage, including the blog homepage and core service pages.
• Standardise URL patterns. Use lowercase, hyphens, and consistent trailing slash policy. Avoid unnecessary parameters, mixed casing, and underscores. Keep slugs readable and descriptive.
• Reuse high-performing URL slugs from the old site wherever possible. Only change URLs where there is a clear SEO or UX benefit. Proper URL mapping is crucial to avoid SEO penalties.
• Plan internal linking hubs and breadcrumb structure so link equity flows naturally to high-value sections of the new site structure.
• Coordinate taxonomy and navigation changes with the redirect map. No important topic or landing page should disappear without an equivalent replacement.
• Review new wireframes and templates from an SEO perspective: heading hierarchy, content blocks, space for metadata, schema markup support, and mobile-first usability. Ensure templates work well on mobile devices.

Set up a secure staging environment

A staging environment is where you build, test, and break things without affecting your live site or search engine visibility. Every migration should be tested here before going live.

The staging website must be protected from indexation. Use HTTP authentication or IP whitelisting. At minimum, apply “noindex, nofollow” meta tags and block the staging site via robots.txt. Accidental indexation of a staging site creates duplicate content problems and confuses search engine crawlers with wrong canonical signals.

Staging should mirror your live hosting as closely as possible: same PHP version, database engine, caching configuration, and CDN setup. This ensures that site speed and technical behaviour on staging are representative of what the live site will deliver.

Migrate a recent copy of content and data from the old site into staging so internal links, forms, and lead-gen flows can be tested properly. All tracking tags, including google analytics 4 and Google Tag Manager, should use test properties or debug modes to prevent search engines from receiving mixed signals and to avoid polluting live data with staging activity.

Gareth and the RedShaw Consulting team often insist on a separate password-protected SEO QA staging environment, distinct from the design staging site, so technical SEO review does not get tangled up with ongoing design revisions.

Technical SEO checks on the staging site

The bulk of technical SEO issues should be caught and fixed in the staging environment before launch day. Conducting a thorough audit on the staging site helps identify bugs before going live and avoids costly post-launch firefighting.

Run a full site crawl of the staging site using authenticated access. Verify these elements against your pre-migration crawl:

• HTTP status codes on all pages
• Canonical tags pointing to the correct canonical version of each URL
• Title tags and meta descriptions matching your migration plan
• H1 headings present and correct on every template
• Structured data (Article, FAQ, Product, LocalBusiness) intact and error-free
• Hreflang tags for multilingual sites
• Pagination handling

Ensure there is only one canonical version of each URL. Resolve www versus non-www, trailing slash versus non-trailing, and HTTP versus HTTPS variants with proper redirects.

Confirm mobile-friendliness and core web vitals using PageSpeed Insights. Target LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. Page loading performance on the new build matters as much as redirects.

Validate robots.txt and meta robots rules. Staging should remain fully blocked, but prepare a clean production-ready robots.txt file. Validating structured data ensures schema markup is correct on the new site; use Google’s Rich Results Test to catch errors before deployment.

Log all discovered issues in a shared tracker with priorities and owners. Be clear about which fixes are must-do before launch and which can wait.

Build your redirect map and link equity strategy

A detailed redirect map is the heart of any seo migration checklist because it preserves link equity and user journeys. Get this wrong, and even a well-designed new site will lose search traffic.

Start from your master URL inventory. Create a detailed map of old URLs to new URLs, prioritising 1:1 matches for pages with the highest traffic, conversions, and backlinks. Every old URL needs a destination. Create a detailed redirect map for old and new URLs covering the entire site, not just the pages you remember.

Key principles:

• Implement 301 redirects to preserve link equity during migration. 301 redirects help preserve link equity and tell search engines the move is permanent. Avoid 302s unless the change is genuinely temporary.
• Avoid redirect chains where old URL A redirects to B, which redirects to C. Flatten them so old urls redirect directly to the final destination.
• Avoid redirecting old URLs to a single new location like the homepage. Redirect retired content to the closest topical equivalent page to maintain relevance signals. Sending everything to the homepage wastes link equity and confuses users.
• Prepare separate redirect rules for protocol changes, www/non-www consolidation, and trailing slash consistency.

SEO migration ensures search engines recognize new URLs correctly when redirects are mapped accurately.

Test a sample of redirects in staging using a crawler and manual checks. Focus on high-value old pages first. Then export a final tested redirect file for the production server, whether that is an .htaccess file, Nginx configuration, or a WordPress redirection plugin.

A good redirect map spreadsheet should contain: old URL, new URL, redirect type (301), validation status, traffic/backlink priority score, and notes on any content consolidation decisions.

Prepare analytics, tracking and tags for continuity

Many apparent migration failures are actually data failures. Website traffic looks like it vanished, but the real problem is that tracking codes broke on launch day.

Deploy google analytics 4 on the staging site via Google Tag Manager, using a dedicated test container or test GA4 property. Document every existing event, conversion, goal, and ecommerce tracking setup on the old site so they can be replicated precisely on the new build.

Verify cross-domain tracking if forms, checkouts, or resources are handled on subdomains or third-party platforms. For lead-generation sites, this is especially important when CRM integrations pull data from external domains.

Tracking codes must be verified to ensure analytics function correctly post-launch. Catalogue all third-party scripts: Meta Pixel, LinkedIn Insight Tag, Hotjar, chatbot scripts, and marketing automation tracking. Ensure each is installed and firing correctly on key templates of the new site.

Plan an annotation in GA4 and other search engines’ analytics tools on the exact launch date and time. This makes pre and post migration performance comparison clean and unambiguous.

Gareth and RedShaw Consulting often run a mini measurement QA 48 hours before launch, testing tag firing across key page templates on staging to catch gaps that would otherwise create blind spots in your data.

Content and on-page SEO migration

Technical foundations are necessary but not sufficient. On-page SEO and content quality must also survive the website migration process.

Export all titles, meta descriptions, H1s, and key body content from the old site. Use these as the baseline when populating new templates. Do not let developers or designers strip content for aesthetic reasons without understanding the SEO implications.

• Update copy where needed to reflect current positioning, but keep core keyword targeting and search intent aligned with historical performance. Do not rewrite high-performing pages without clear justification.
• Update internal links to reflect the new URL structure post-migration. Review internal links pointing within blog posts, service pages, and resource content. Links should point directly to new urls rather than relying on redirect chains.
• Maintain or improve unique content on critical pages such as service, product, and location pages. Cutting content to simplify templates can weaken relevance signals.
• Migrate media assets (images, PDFs, videos) with sensible filenames and alt text. Ensure legacy media URLs have appropriate redirects. For high-value PDFs, consider converting to HTML for better indexation.

Pre-launch checklist: final staging QA

This is your go/no-go gate. Nothing moves to production until these checks pass.

Run a final site crawl against staging and compare it to the pre-migration crawl. Ensure no major sections are missing and that canonical URLs look correct across every template. If page counts do not match expectations, investigate before proceeding.

• Test key lead-generation paths end-to-end: contact forms, quote request forms, download gates, newsletter sign-ups. Confirm submissions reach the correct CRM or inbox.
• Verify core templates (homepage, category, service page, blog post, search results page, 404 page) across Chrome, Safari, and Firefox on desktop, tablet, and mobile devices.
• Re-check robots.txt and meta robots on staging. The staging site should still be blocked. The production robots.txt file should be reviewed, finalised, and ready with only deliberate disallows.
• Confirm all planned redirects exist in configuration files and have been tested on the staging site.
• Document a rollback plan. If severe issues surface after launch, you need to know exactly how to revert DNS, serve the old site, or disable the new build within minutes.

This checklist should be signed off by SEO, development, and stakeholders before anyone touches DNS.

Launch day: switching from old site to new site

Launch day is a controlled operation, not a casual deployment. Treat it like a site create event that requires coordination across every team involved.

Update your DNS settings to point to the new IP address. Coordinate with hosting providers, ensuring TTL was lowered 24–48 hours earlier for faster propagation. Have hosting support on standby.

Immediately after go-live:

• Deploy the production robots.txt without blocking the whole site. Ensuring robots.txt allows crawlers helps maintain search visibility after migration. Remove any “noindex” directives from production templates.
• Enable the full 301 redirect set on the live server. Test a sample of high-value old urls to confirm they return 301 status codes and resolve to a 200 on the destination.
• Run a quick targeted site crawl of priority URLs on the live site within the first hour. Look for server errors, 404s, and redirect loops.
• Verify that google analytics, Tag Manager, and key conversion events are firing correctly on the live site within minutes of launch.

SEO performance can drop immediately after a site migration, so rapid validation reduces the window of exposure.

Immediate post launch checks (first 48–72 hours)

The first few days after migration are critical for spotting severe SEO and UX problems before they compound.

Run a full site crawl of the new live site. Using tools to crawl the new site identifies broken links and missed redirects that slipped through staging QA. Monitor for broken links and 404 errors after migration, as broken links can disrupt user experience and harm SEO.

• Check server logs or analytics for spikes in 404 errors. Monitoring Indexing reports for 404 spikes is crucial for post-migration health. Prioritise fixes for URLs with the highest historical traffic and backlink counts.
• Validate that the xml sitemap has been updated to contain only new canonical URLs and is referenced correctly in robots.txt. Submit updated XML sitemaps to search engines after migration.
• Submit new sitemaps in google search console and bing webmaster tools. For domain migrations, use Google’s Change of Address tool to tells search engines about the move.
• Monitor google search console for crawl errors, soft 404s, and coverage issues. Start resolving high-impact problems immediately.

Post migration analytics and SEO monitoring (weeks 1–12)

Expect short-term volatility. Even a well-managed successful migration typically sees a 5–10% organic traffic dip lasting one to two weeks. For complex domain migrations or large-scale replatforming, full recovery can take three to six months.

Monitor traffic and rankings using Google Analytics on a daily basis during the first two weeks, then weekly. Monitoring search performance should occur for several weeks after migration to catch issues that surface as search engine crawlers reprocess the migrated site.

• Compare performance of priority pages and keyword rankings against pre-migration benchmarks at 1, 2, 4, 8, and 12 weeks. Note where rankings drop beyond expected ranges.
• Set up custom dashboards focused on migrated sections, mobile performance, core web vitals metrics, and loading speed on the new site.
• Monitor post migration performance in google search console search results reports: queries, pages, CTR, and average position trends.
• Run scheduled site crawls weekly for the first month, then monthly to catch new issues introduced by ongoing content edits or code changes.
• Monitoring traffic and rankings for weeks after migration helps detect issues early, before they become entrenched.

For lead-generation sites, track not just direct conversions but assisted conversion paths. If sales cycles are longer, extend your monitoring window accordingly. The site’s performance should be measured against the success criteria you defined before the migration process began.

Backlinks, citations and off-site signals

Redirects preserve link equity in most cases, but they are not always enough. External links from high-authority referring domains deserve direct attention.

• Export top backlinks from tools like Ahrefs and google search console, focusing on links to old pages that changed URL or were consolidated.
• Prioritise outreach for the most valuable referring domains. Ask them to update external links from old URLs to new canonical URLs where you have a relationship with the site owner.
• Update all owned assets: Google Business Profile, Bing Places, social profiles, email signatures, and key directory listings with the new domain or updated URLs.
• Watch referral traffic reports post migration to identify important third-party sites still sending users to old urls without proper redirects or with poor redirect targets.

Preserve link equity proactively rather than relying entirely on redirect chains that may degrade over time as other search engines process changes at different rates.

Common SEO migration mistakes to avoid

Many migration failures stem from a handful of predictable errors. Here are the ones that cause the most damage:

• Staging environment indexed by search engines. Forgetting to prevent search engines from crawling the staging website creates duplicate content and sends wrong canonical signals. Always use authentication or IP restrictions.
• Redirects not deployed or tested. Launching the new site without the full redirect set causes widespread 404s and immediate loss of search traffic. A website migration checklist without redirect verification is incomplete.
• Changing too many variables at once. Altering site structure, content, design, and brand messaging simultaneously makes diagnosis of ranking drops nearly impossible. Search Engine Journal documents this as one of the most common migration errors.
• Broken analytics tracking. Not verifying tracking codes on the new site creates apparent traffic loss that is actually just missing data, not a real drop.
• Ignoring page speed and core web vitals. New templates or JavaScript frameworks can introduce performance regressions that harm search engine rankings even when redirects are perfect. Test site speed thoroughly before launch.
• Launching on a Friday or holiday. When the team is unavailable to respond to issues, problems compound over the weekend.

When to bring in specialist help

Some website migrations, particularly on custom platforms or complex WordPress setups, carry enough risk that experienced technical SEO support pays for itself in avoided losses.

• Consider external help if the site has hundreds or thousands of URLs, multiple languages, or complex lead-gen funnels tied into CRM and marketing automation platforms.
• An seo audit before migration is especially valuable if historic algorithm issues, large numbers of legacy redirects, or a messy site structure make planning difficult.
• Gareth and RedShaw Consulting regularly handle seo migration projects, technical audits, and redirect planning for B2B and professional services sites, working alongside in-house teams or existing agencies to reduce risk.
• A smooth migration depends on preparation. A successful website migration is rarely the result of luck. If you feel unsure about your plan, it costs nothing to have a conversation before locking in a launch date. Reach out via the RedShaw contact page.

The difference between a successful site migration and a damaging one is almost always the quality of planning. Search engine optimization during a migration is not a bolt-on activity. It needs to run through every phase of the project, from the first scoping conversation through to the final post launch monitoring review weeks later. Done well, a migration protects what you have built and creates a stronger foundation for the site’s seo going forward.