Site migration for product teams: the complete checklist for protecting (and growing) your organic traffic

I once watched a 14,000-page content app lose 20% of its brand traffic after a CMS migration. The redirect mapping was incomplete, the staging audit got rushed, and nobody owned the cross-functional coordination between SEO, engineering, and content. I was the senior PM responsible for the remediation, and it took months of forensic redirect auditing and phased fixes to arrest the decline. That experience taught me something I now treat as a first principle: site migrations are product projects, not engineering projects. They demand the same rigor you would give any high-stakes launch.

A website migration is any change to your site that fundamentally alters how search engines see it. Moving to a new domain. Switching from HTTP to HTTPS. Swapping out your CMS. Redesigning your URL structure. Each of these forces Google to re-evaluate your entire site, and re-evaluation means risk. Rankings can drop. Pages can fall out of the index. Organic traffic, the channel you spent years building, can vanish in a week.

But here is the other side of that coin. A well-executed migration is one of the few opportunities where you can actually improve your SEO in a single project. You clean up years of technical debt, consolidate thin content, upgrade your site architecture, and come out the other end with stronger rankings than you started with.

This guide is written specifically for product managers and product teams who are owning (or about to own) a migration project. It is not a generic SEO article. It is a playbook that covers the full lifecycle: how to audit and plan before a single line of code changes, how to coordinate the technical execution with your engineering team, what to monitor on launch day, and (the part most guides skip) how to use the migration as a springboard for post-launch growth. Along the way, I will share real case studies, including failures I have been personally involved in, and provide checklists you can adapt for your own project.

If your team is about to move domains, switch platforms, or restructure URLs, read this before your first sprint planning session.

What website migration actually means and why your product team should own it

The term “website migration” covers a wide range of technical changes, and the SEO risk varies significantly by type. As a PM, your first job is understanding what kind of migration you are dealing with, because the planning, the redirect strategy, and the monitoring approach all depend on it.

Domain name change is the highest-risk migration type. You are asking Google to transfer all the authority and trust it has built for your old domain to a completely new one. Google’s documentation on site moves walks through the mechanics, but the short version is: you need 301 redirects from every old URL to its new equivalent, you need to use the Change of Address tool in Google Search Console, and you need to keep the old domain active and redirecting for at least 180 days. Even with perfect execution, expect some temporary ranking fluctuations.

HTTP to HTTPS migration is lower risk but still requires care. Google treats HTTP and HTTPS as separate URLs, so a move to HTTPS is technically a URL change for every page on your site. The good news is Google has been encouraging HTTPS adoption since 2014, and the process is well-documented. The bad news is that sloppy implementation (mixed content warnings, broken redirects, forgetting to update the sitemap) still causes ranking drops.

CMS migration (moving from WordPress to Shopify, or Drupal to a headless CMS, for example) is where things get complicated for product teams. The URL structure almost always changes, the internal linking architecture shifts, and platform-specific SEO features (like how canonical tags are generated or how XML sitemaps are built) work differently. This is the migration type that burned us on the Hotels.com Go Guides app, and it is the type where PM ownership matters most. Engineering will focus on making the new platform work functionally, and the SEO implications are easy to overlook unless someone is explicitly owning that checklist.

Site redesign with URL changes is the most common trigger for accidental SEO damage. The design team restructures the navigation, the information architecture changes, old pages get removed or merged, and new URL patterns get introduced. Without a redirect map that accounts for every old URL, Google loses track of where your content went.

Does site migration affect SEO? Yes. Every type changes the signals that search engines use to crawl, index, and rank your pages. The degree of impact depends almost entirely on how well you plan. Google’s own guidance makes clear that migrations with proper redirects typically recover within weeks, but migrations with gaps can take months to stabilize, if they recover at all.

The reason product teams should own this (not just engineering, not just SEO) is that migrations sit at the intersection of technical execution, content strategy, and business risk. You need someone who can coordinate across all three, set priorities, manage the timeline, and make trade-off decisions when things get complicated. That is a PM’s job.

Pre-migration planning that prevents disasters

Every migration failure I have seen (and I have seen a few) traces back to a planning gap. Not a technical gap. A planning gap. Someone skipped the audit. Nobody mapped the redirects until a week before launch. The content team and the engineering team had different assumptions about which URLs were changing. Planning is not the glamorous phase, but it is the one that determines whether your migration protects your traffic or destroys it.

SEO and technical audits that go deeper than the surface

Before you change anything, you need a complete snapshot of your current site’s SEO health. This is your baseline, the before picture you will compare everything against after launch.

Start with a full crawl of your existing site using Screaming Frog or a similar crawler. You are looking for the current state of affairs: every URL, its status code, its title tag, its canonical tag, its internal links, and whether it is in the XML sitemap. Export this data. You will need it for redirect mapping later.

Check your indexation status in Google Search Console. How many pages does Google have indexed? How many are excluded, and why? This matters because pages that are not indexed pre-migration do not need redirects, and pages that are indexed need careful handling. I learned this the hard way: when we audited indexation across 50+ brand properties at Expedia, we discovered that only 40% of pages were actually indexed, even on our strongest sites. The lesson is that your actual indexed footprint is almost certainly smaller than you think, and building a redirect map based on your CMS page list rather than your indexed URL list wastes effort on URLs Google already ignores.

Run your top landing pages through Google PageSpeed Insights and record your Core Web Vitals scores (LCP, INP, CLS). These are your performance benchmarks. If the new site is slower than the old one, that is a regression you want to catch in staging, not after launch.

Document your current keyword rankings for your top 50 to 100 pages. Use Ahrefs, Semrush, or even manual Google Search Console queries. These rankings are the KPIs your stakeholders will care about most, so capture them now.

Your pre-migration audit checklist.

• Full site crawl exported (all URLs, status codes, canonicals, internal links)
• Google Search Console indexation report downloaded
• Core Web Vitals baseline recorded for top 20 pages
• Keyword rankings captured for top 50-100 pages
• Organic traffic baseline pulled from Google Analytics (last 12 months, by page)
• Backlink profile exported from Ahrefs or Semrush
• Current XML sitemap URLs counted and verified
• Robots.txt rules documented

Content inventory and strategy

A migration is the best excuse you will ever get to clean up your content. Most sites accumulate pages over years without ever pruning the ones that stopped performing. Thin pages, duplicate content, outdated blog posts that get zero traffic: these all drag down your site’s quality signals and waste crawl budget.

Pull your page-level traffic data from Google Analytics for the last 12 months. Sort every page into one of four buckets:

1. Keep and redirect. High-traffic, high-value pages that will exist on the new site with a new URL. These get one-to-one 301 redirects.
2. Keep and improve. Pages with moderate traffic that could perform better with updated content, better metadata, or stronger internal linking on the new site.
3. Merge. Pages covering the same topic that should be consolidated into a single, stronger page. Common with blog content that has covered the same subject from slightly different angles over the years.
4. Prune. Pages with zero or near-zero traffic, no backlinks, and no strategic value. These can be removed or set to noindex. Do not redirect pruned pages to unrelated content (Google treats that as a soft 404).

Update your metadata while you are at it. If title tags and meta descriptions have been neglected, the migration is the time to bring them in line with your current keyword strategy. Document everything in a spreadsheet that maps old URL to new URL to action (redirect, merge, prune).

Predictive risk assessment

Most migration guides give you a checklist and say “follow the steps.” That is necessary but not sufficient. What separates a good migration from a great one is the ability to predict which steps are most likely to go wrong for your specific project, and have contingency plans ready.

Build an impact/likelihood matrix. List every known risk (broken redirects, server downtime during DNS propagation, content parity gaps, analytics tracking loss) and rate each one on two axes: how likely it is to happen, and how much damage it would cause. Focus your QA effort on the high-likelihood, high-impact quadrant.

Run scenario planning for three outcomes: best case (traffic fully recovers within 2 weeks), expected case (temporary dip with recovery in 4-8 weeks), and worst case (significant traffic loss requiring active remediation). Define what “significant” means in terms of your KPIs. What is the threshold that triggers your rollback plan? What is the threshold that triggers escalation to leadership? Having these numbers agreed on before launch prevents panic-driven decisions after launch.

Common pitfalls that your risk assessment should specifically address:

• Redirect coverage gaps. Are there URL patterns on the old site that your redirect rules do not cover? Parameter URLs, paginated URLs, and AMP URLs are frequently missed.
• Staging environment leaks. Is your staging site accidentally indexable? A noindex meta tag or robots.txt block on staging that accidentally gets deployed to production is one of the fastest ways to de-index your entire site.
• DNS propagation delays. How long will the TTL be on your DNS records? Have you lowered it in advance?
• Third-party dependencies. Do any third-party tools (A/B testing platforms, CDN configurations, chat widgets) rely on your old domain or URL structure?

Stakeholder alignment and the communication plan

If you are a PM reading this, stakeholder alignment is probably the part of the migration you already understand is important but wish you could skip. You cannot skip it. Migrations touch every team: engineering builds it, SEO defines the requirements, marketing needs to know what is changing and when, legal may need to review domain or privacy changes, and customer support needs to be ready for user confusion.

Create a RACI matrix (responsible, accountable, consulted, informed) for the migration project. The PM is accountable for the overall project. Engineering is responsible for the technical execution. SEO is responsible for the redirect map, sitemap, and robots.txt requirements. QA is responsible for the staging audit. Marketing is responsible for updating any external campaigns that reference old URLs.

Your communication plan should include:

• Weekly status updates during the planning phase, increasing to daily updates in the week before launch.
• A go/no-go checklist that every team signs off on before launch day. This should include engineering, SEO, QA, and marketing.
• A rollback plan that everyone understands. If something goes catastrophically wrong in the first 24 hours, what is the process for reverting? Who makes that call?
• External communication for customers or partners who link to your site. If you are changing domains, notify high-value referral partners in advance so they can update their links.

Frame the migration as a product launch, because that is what it is. It deserves the same planning rigor you would give any major roadmap initiative. If your organization uses an SEO PRD process, a migration is exactly the kind of project that needs one.

Technical execution that protects your SEO

The planning phase told you what to do. This phase is where your engineering team actually does it. Your job as PM shifts from defining requirements to verifying execution: making sure the staging environment matches the spec, the redirects work correctly, and nothing falls through the cracks between what was planned and what was built.

Building and auditing the staging environment

Your staging environment is your safety net. Every check you run here is a problem you catch before it reaches your users and Google’s crawlers.

Set up the new site on a staging URL that is not accessible to search engines. Use a combination of robots.txt disallow rules, HTTP authentication (password protection), and noindex meta tags. Belt and suspenders, because the cost of Google accidentally indexing your staging site is much higher than the cost of triple-checking that it cannot.

Once the new site is running on staging, crawl it the same way you crawled the old site. Compare the two crawls side by side:

• URL count. Does the new site have the same number of indexable pages as the old one (minus anything you deliberately pruned)?
• Status codes. Are all intended pages returning 200? Are there unexpected 404s or 500s?
• Canonical tags. Does every page have a correct self-referencing canonical? Are there pages accidentally pointing their canonical to the old domain?
• Title tags and metadata. Did the content transfer preserve all your title tags, meta descriptions, and heading structures?
• Internal links. Are internal links pointing to new URLs directly, or are they still using old URLs (which would create unnecessary redirect hops)?
• Page speed. Run Lighthouse on your top 20 pages. Compare against your pre-migration baselines. Fix any regressions before launch.

This is where your QA checklist earns its keep. A staging audit is not a casual walkthrough. It is a systematic, line-by-line verification that every SEO requirement from your migration plan has been implemented correctly.

Redirect mapping beyond the basics

Redirects are the single most important technical element of any migration. A missing redirect means a dead page, a lost ranking, and a frustrated user. A badly implemented redirect (sending everything to the homepage, or creating chains of three or four hops) is almost as bad.

Build your redirect map as a one-to-one mapping: old URL to new URL. Every indexed page on the old site should have a corresponding 301 redirect to its equivalent page on the new site. Google’s documentation on 301 redirects confirms that permanent redirects pass full ranking signals to the destination URL.

For large sites, one-to-one mapping by hand is not realistic. This is where regex (regular expression) redirects become valuable. If your old site used the pattern /products/category/product-name and your new site uses /shop/product-name, a single regex rule can handle thousands of redirects. But regex redirects are also the easiest place to introduce bugs. Test every rule against a sample of at least 50 URLs before deploying.

Watch out for redirect chains. A redirect chain happens when URL A redirects to URL B, which redirects to URL C. Google will follow chains up to about 5 hops, but each hop delays crawling and dilutes the signal slightly. After a migration, audit your redirect rules to ensure you are not stacking new redirects on top of old ones from a previous migration. The goal is one hop: old URL to final new URL.

Test your redirect map before launch day. Tools like Screaming Frog can crawl a list of old URLs and verify that each one redirects to the expected destination with a 301 status code. Do this on staging first, then again immediately after launch.

Robots.txt, XML sitemaps, and canonical tags

These three files are how you tell Google’s crawlers what to index, where to find your content, and which version of a page is the authoritative one. Getting them wrong during a migration can undo all your redirect work.

Robots.txt. Your new site’s robots.txt should allow crawling of all pages you want indexed and block admin areas, internal search results, and other non-public sections. The most common migration mistake with robots.txt is deploying the staging version to production. If your staging robots.txt contains Disallow: / (blocking the entire site), and that file goes live, Google will stop crawling your site entirely. Add a robots.txt check to your go/no-go checklist.

XML sitemaps. Generate a new XML sitemap that reflects your new URL structure. It should contain only indexable pages (no redirects, no noindexed pages, no 404s). Submit it via Google Search Console immediately after launch. Keep your old sitemap active on the old domain for at least 180 days, because it helps Google discover your redirects faster.

Canonical tags. Every indexable page on the new site should have a self-referencing canonical tag pointing to its own new URL. During a migration, a common bug is canonical tags that still point to old-domain URLs. This tells Google that the old URL is the authoritative version, which directly undermines your redirects. Crawl your staging site and check every canonical tag before you launch.

Updating internal links and fixing broken links

Here is a step that gets overlooked more than it should: updating internal links within your content to point directly to the new URLs.

If your blog post links to /old-site/product-page and that page now lives at /new-site/product-page, the redirect will handle it. The user will get to the right place. But every internal link that goes through a redirect is an unnecessary hop. It adds latency for users, and it sends a signal to Google that your internal linking is not clean. Over thousands of pages, these hops add up and reduce crawl efficiency.

After the migration, run a full crawl of the new site and look for:

• Internal links returning 301s. These are old URLs that need to be updated in the content to point to the new URL directly.
• Internal links returning 404s. These are broken links, often caused by pages that were pruned but still linked from other content.
• Orphan pages. Pages on the new site that have no internal links pointing to them. These are difficult for Google to discover and unlikely to rank well.

Fix these systematically. If your CMS supports search-and-replace across content (most do), use it to bulk-update old URLs to new ones. If not, prioritize your highest-traffic pages and work outward.

Launch day and the first 72 hours

You have planned, built, tested, and gotten sign-off from every team. Now you launch. The next 72 hours are the most important monitoring period of the entire project.

Executing the launch and notifying Google

On launch day, the technical steps are straightforward if your staging environment has been properly audited:

1. Update DNS records to point your domain to the new server or platform. If you lowered your TTL in advance (you should have), propagation will be faster.
2. Verify redirects are live by spot-checking 20-30 URLs from your redirect map. Use a tool or just check manually in an incognito browser.
3. Submit your new XML sitemap in Google Search Console. Go to Sitemaps, enter the new sitemap URL, and submit.
4. Use the Change of Address tool if you changed domains. This is found in Google Search Console under Settings > Change of Address. Google’s documentation walks through the exact process.
5. Request indexing for your most important pages using the URL Inspection tool in Search Console. You can only do this for a limited number of URLs per day, so prioritize your homepage, top landing pages, and key content.

If your migration involves a domain change, keep the old domain’s Search Console property active. You need it to monitor how Google is processing the redirects and to track any errors that appear on the old domain.

Setting up and verifying analytics

This is the step that gets forgotten most often, and the damage is invisible until someone asks “why does our traffic data look weird?”

Before launch, verify that your Google Analytics tracking code (or Google Tag Manager container) is correctly installed on every page of the new site. Use Google’s Tag Assistant to verify that tags are firing properly.

Check these specific items:

• Property and data stream configuration. If you changed domains, you may need to update your GA4 data stream to reflect the new domain.
• Cross-domain tracking. If your old and new domains will coexist during the transition period, set up cross-domain tracking to avoid inflating session counts.
• Goal and conversion tracking. Verify that your conversion goals, e-commerce tracking, and any custom events are working on the new site. A migration that breaks conversion tracking will give you misleading performance data for weeks.
• Filters and exclusions. Update any view filters, IP exclusions, or hostname filters that reference the old domain.

Run a real-time report in Google Analytics after launch and verify that live visits are being tracked. Click through a few pages yourself and confirm the pageviews appear. This takes five minutes and saves days of diagnostic work if something is broken.

The immediate post-launch audit

The first 72 hours after launch are your rapid-response window. Set up monitoring for these signals:

Google Search Console. Check the Coverage report daily. Look for spikes in “Excluded” pages, new 404 errors, or “Crawled but not indexed” entries. These are early warnings that something in your redirect map or sitemap is off. The Performance report will show you impression and click data, but expect a 48-72 hour delay before meaningful data appears.

Server logs. If you have access to your server logs, monitor them for 404 responses to URLs that should be redirecting. A spike in 404s in the first hours after launch usually means a redirect rule is broken or missing.

Site crawl. Run a fresh crawl of your new site within 24 hours of launch. Compare it against your staging crawl. Any new broken links, missing pages, or changed status codes that were not there in staging are post-launch regressions that need immediate attention.

Organic traffic. Compare daily organic sessions against the same day in the previous week. A moderate dip (10-20%) in the first few days is normal and expected. A steep drop (50%+) within the first 48 hours suggests a significant technical problem, likely a redirect issue, an indexing block, or a robots.txt misconfiguration.

Keep a shared document (a Google Sheet works well) where the team logs any issues found, their severity, and their resolution status. This becomes your migration incident log and is invaluable for post-mortems.

Post-migration optimization for growth

Most migration guides stop at “monitor and fix issues.” That is table stakes. The real opportunity in a migration is using the new site as a platform for growth. If you did the hard work of cleaning up content, improving site architecture, and upgrading your technical stack, it would be a waste to just recover to your pre-migration baseline. The goal is to surpass it.

Long-term monitoring and analysis

Set up a migration-specific dashboard in Google Analytics that tracks these metrics against your pre-migration benchmarks:

• Organic sessions by page (weekly, compared to the same period pre-migration)
• Keyword rankings for your top 50-100 terms (weekly, using Ahrefs or Semrush)
• Index coverage in Google Search Console (weekly, tracking the ratio of indexed to submitted pages)
• Crawl stats (from Search Console Settings > Crawl Stats, looking for any decline in crawl frequency or increase in errors)
• Conversion rate (are users converting at the same rate on the new site?)

Track these weekly for the first 3 months post-migration, then monthly for the following 9 months. Most migrations reach full stabilization within 3 to 6 months, but some effects (especially around domain authority consolidation) can take up to a year.

Compare against the three scenarios from your pre-migration risk assessment: best case, expected case, and worst case. If you are tracking below your expected case after 4 weeks, investigate. If you are tracking below your worst case, escalate and consider whether specific remediation actions are needed.

Core Web Vitals and user experience

A migration is your chance to reset your technical performance baseline. If you moved to a faster platform, a better CDN, or a cleaner codebase, your Core Web Vitals should improve. And if they do, that improvement directly affects both user experience and rankings, since Google uses CWV as a ranking factor.

Focus on the three metrics that matter:

• Largest Contentful Paint (LCP). Should be under 2.5 seconds. If the new site loads hero images or large content blocks slower than the old one, investigate image compression, server response times, and render-blocking resources. We went through exactly this at Expedia, where we had to cut LCP from 4.5 seconds to under 2.5 seconds across a million pages.
• Interaction to Next Paint (INP). Should be under 200 milliseconds. Measures how quickly your site responds to user interactions. Common culprits after a migration are heavy JavaScript bundles from the new platform and third-party scripts that were not on the old site.
• Cumulative Layout Shift (CLS). Should be under 0.1. Layout shifts often increase after a migration when new templates have different image aspect ratios, ad placements, or font loading behavior than the old site.

Run PageSpeed Insights on your top 20 pages within the first week post-launch and compare to your pre-migration baselines. Any regressions are bugs that should be fixed in the next sprint.

Content enhancement and new opportunities

With the technical migration behind you, shift your attention to content. The content inventory you built during planning identified pages in the “keep and improve” bucket. Now is the time to actually improve them.

Start with your top 20 pages by organic traffic. For each one, ask: is the content still accurate? Does it target the right keywords? Is it better than what currently ranks in positions 1-3 for those keywords? If the answer to any of those is no, update it. A freshly migrated page that also gets a content refresh sends a strong positive signal to Google.

Look for new content opportunities that the old platform could not support. Maybe the new CMS has better structured data support, enabling FAQ schema or How-To schema that your old site lacked. Maybe the new site architecture allows you to build topic clusters that were not possible before. Maybe you can now implement proper internal linking architecture that connects your content in ways the old platform made difficult.

Build a 90-day post-migration content plan that covers: content refreshes for your top pages, new content pieces that fill gaps in your topic clusters, and technical content improvements (schema markup, internal linking, metadata optimization). Treat this plan as a phase of the migration project, not a separate initiative.

External link outreach

Your backlinks are one of your most valuable SEO assets, and a migration puts them at risk. Every external link pointing to your old URLs now goes through a redirect. While 301 redirects pass full ranking signals, there is value in getting those links updated to point directly to your new URLs, because it reduces your dependency on redirect infrastructure and gives Google cleaner signals.

Export your backlink profile from Ahrefs or Semrush. Sort by Domain Rating (or equivalent authority metric) and identify your highest-value linking domains. For the top 50-100, reach out to the webmasters with a simple request: “We recently migrated our site. Here is the new URL for the page you linked to. Would you be able to update the link?”

The response rate for these outreach emails tends to be in the single digits, but the value per updated link is high because these tend to be your strongest backlinks. Focus your outreach on:

• Partner and vendor sites that link to you as part of a business relationship
• Industry publications where you have been featured or quoted
• Resource pages and directories that list your site
• Guest post placements where you can update the author bio links

For links you cannot get updated, the redirects will do their job. But for your top 50 referring domains, the outreach is worth the effort.

Real-world case studies

Theory is useful. Examples are better. These three case studies illustrate specific challenges and outcomes from real migration projects. The details have been anonymized where needed, but the technical problems and the solutions are real.

Enterprise domain and CMS migration

The situation. A large travel brand with over 14,000 content pages and a significant share of brand organic traffic decided to migrate both its domain and its underlying CMS simultaneously. The content app accounted for roughly 20% of the brand’s total organic traffic, so the stakes were high.

What went right. The team conducted a full pre-migration audit including a content inventory, a backlink analysis, and a baseline of keyword rankings across all major landing pages. They identified which pages drove traffic and which were dead weight. The redirect map was built using a combination of one-to-one mappings for high-value pages and regex rules for URL pattern changes.

What went wrong. The staging audit was compressed into a single sprint instead of the planned two, and several edge cases in the redirect map were not tested. Post-launch, around 15% of the redirects for long-tail content pages were either missing or pointed to the wrong destination. The result was a steady decline in organic traffic, roughly a 20% drop within the first month.

The recovery. The PM (this was my project) prioritized a forensic redirect audit, pulling server logs and Google Search Console error reports to identify every broken or incorrect redirect. The team deployed fixes in batches over 6 weeks, and simultaneously consolidated thin content pages that had been underperforming even before the migration. The traffic decline was fully arrested, and the schema markup rollout that followed on the new CMS eventually opened up rich snippet eligibility on thousands of pages, something that would not have been possible on the old platform.

The lesson. Do not compress your staging QA timeline, no matter how much pressure there is to launch. The time you “save” gets spent tenfold in post-launch firefighting.

Recovering from a faulty e-commerce migration

The situation. A mid-sized e-commerce retailer migrated from a legacy platform to a modern hosted solution. The site had approximately 8,000 product pages, 500 category pages, and a blog with 200 posts. The migration was driven by the engineering team with minimal SEO involvement in the planning phase.

What went wrong. Three errors compounded to cause a 60% drop in organic traffic within two weeks of launch.

First, the redirect map only covered category pages and the homepage. The 8,000 product page URLs all changed format, and no redirects were created for them. Google returned 404s for every product page that had been indexed on the old site.

Second, the new platform generated canonical tags that pointed to parameterized URLs (with session IDs and tracking parameters), which fragmented Google’s understanding of which pages were authoritative.

Third, the XML sitemap on the new platform included every URL variant (including parameterized versions), inflating the sitemap from 9,000 URLs to over 40,000.

The recovery. An emergency SEO audit using Google Search Console and Screaming Frog identified the three root causes within 48 hours. The team deployed a regex redirect rule to handle all product page URL patterns (old format to new format), which resolved the 404s within a week. Canonical tags were fixed to point to clean URLs, and the sitemap was regenerated to include only canonical, indexable pages. Traffic began recovering after 3 weeks and returned to pre-migration levels after approximately 10 weeks.

The lesson. Never run a migration without SEO involvement in the planning phase. Engineering teams optimize for functionality and performance. SEO requirements (redirects, canonicals, sitemaps) are not on their radar unless someone puts them there. That someone is the PM.

HTTPS migration without traffic loss

The situation. A content-heavy publisher with approximately 30,000 indexed pages migrated from HTTP to HTTPS. The site’s revenue depended almost entirely on organic traffic, so even a small ranking dip would have had an immediate financial impact.

What went right. The team treated the HTTPS migration with the same rigor as a domain change. Every step was documented and tested:

1. SSL certificate was installed and tested on staging weeks before launch.
2. A complete one-to-one redirect map was built covering all 30,000 indexed URLs from HTTP to HTTPS.
3. All internal links in the content were updated to use HTTPS URLs before launch, eliminating redirect hops from internal navigation.
4. The XML sitemap was updated to HTTPS URLs and submitted to Google Search Console on launch day.
5. Canonical tags were updated to reference HTTPS URLs.
6. Mixed content issues (images and scripts loaded over HTTP on HTTPS pages) were identified and fixed in staging.
7. The HTTP site was kept live with redirects for 6 months.

The result. Zero measurable traffic loss. Organic sessions remained flat through the migration window, and within 4 weeks, rankings had stabilized at the same positions. The team credited the outcome to two factors: a complete redirect map with no gaps, and the internal link update that eliminated redirect chains from day one.

The lesson. HTTPS migrations are often described as “easy” compared to domain changes, but that ease breeds complacency. The publishers who lose traffic during HTTPS migrations are the ones who treat it as a checkbox instead of a project.

Migration checklists and tools

The checklists throughout this guide are designed to be practical, not theoretical. They are platform-agnostic and can be adapted regardless of whether you are on WordPress, Shopify, a custom CMS, or anything else.

Your migration readiness assessment

Before you commit to a launch date, run through this readiness assessment. If you cannot check every box, you are not ready to launch, and that is fine. It is much cheaper to delay by a week than to launch with gaps.

Pre-launch readiness checklist.

• Full site crawl of old site completed and exported
• Content inventory completed with decisions documented (keep, merge, prune)
• Redirect map built and covers 100% of indexed URLs
• Redirect map tested against sample URLs (minimum 50)
• Staging environment crawled and audited against old site
• Core Web Vitals tested on staging and compared to old site baselines
• Robots.txt on new site verified (not blocking indexable content)
• XML sitemap generated for new site with only indexable URLs
• Canonical tags verified on staging (all self-referencing, pointing to new URLs)
• Internal links updated to new URLs (no old-site links remaining in content)
• Google Analytics / Tag Manager verified on staging
• Go/no-go sign-off from engineering, SEO, QA, and marketing
• Rollback plan documented and understood by all teams
• Google Search Console access confirmed for both old and new properties

Post-launch monitoring checklist (first 72 hours).

• DNS propagation confirmed
• Spot-check 30 redirects (mix of page types)
• New XML sitemap submitted to Google Search Console
• Change of Address tool used (if domain change)
• URL Inspection requested for top 10 pages
• Google Analytics real-time report confirmed (tracking active)
• Conversion tracking verified (test transaction or goal completion)
• Server logs reviewed for 404 spikes
• Fresh site crawl run and compared to staging crawl
• Daily organic traffic compared to pre-migration baseline
• Google Search Console Coverage report checked for new errors
• Migration incident log started and shared with team

Templates for redirect maps and audit sheets

Two documents will save your team the most time during a migration project.

The redirect map spreadsheet. This is the single most important deliverable of the planning phase. Structure it with these columns:

Include every indexed URL from your pre-migration crawl. For pages you are pruning, note the decision and leave the “New URL” column blank (or mark as “410 Gone” if appropriate). For merged pages, point multiple old URLs to the single new consolidated URL.

The pre/post-migration audit sheet. Structure this as a comparison template:

Fill in the pre-migration column from your audit. Update the post-migration columns at each interval. This sheet becomes your source of truth for whether the migration succeeded.

Platform-specific migration considerations for e-commerce

Every e-commerce platform has its own quirks when it comes to URL structures, redirect handling, and SEO configuration. As a PM, you need to understand these platform-specific constraints to write accurate requirements for your engineering team.

Shopify and product URL management

Shopify enforces a specific URL structure that you cannot fully customize. Products live at /products/product-handle, collections at /collections/collection-handle, and pages at /pages/page-handle. If you are migrating from a platform that used a different structure (like /shop/category/product-name), every product URL will change.

Shopify has a built-in URL redirect feature that handles basic one-to-one redirects, and you can upload redirects in bulk via CSV. For most migrations, this is sufficient. The limitation is that Shopify does not support regex redirects natively, so if you have thousands of product URLs that follow a predictable pattern, you will need to generate the full one-to-one redirect list in a spreadsheet and upload it.

Things to watch for as a PM:

• Collection URLs with nested paths. Shopify generates URLs like /collections/category/products/product-handle in addition to /products/product-handle for the same product. Make sure canonical tags point to the /products/ version (Shopify does this by default, but verify in staging).
• Faceted navigation. Shopify’s filtering adds parameters to collection URLs. These parameterized URLs should not be in your sitemap and should not be indexed. Confirm this with your engineering team.
• Apps and third-party tools. Shopify apps can modify URL behavior, add pages, and change canonical tags. Audit all installed apps during staging to ensure they are not creating SEO conflicts.

Magento database complexity and extension management

Magento migrations are among the most complex because of the platform’s deep database structure and heavy reliance on extensions. If you are migrating from Magento 1 to Magento 2 (or from Magento to another platform entirely), expect the URL structure, the category tree, and the internal linking to change significantly.

Magento’s data migration tool handles product data, customer accounts, and order history, but it does not handle SEO-specific configurations like URL rewrites, meta descriptions, or custom canonical rules. These need to be migrated separately.

Things to watch for as a PM:

• URL rewrites table. Magento stores URL rewrites in a database table that can contain hundreds of thousands of entries, including duplicates and conflicts. Before migration, clean this table and export a deduplicated redirect map.
• Category URL structure. Magento can generate URLs that include the full category path (/electronics/phones/iphone-15) or just the product key (/iphone-15). Make sure the new site uses a consistent pattern and that redirects account for whatever pattern the old site used.
• Extension dependencies. Many Magento stores rely on extensions for SEO features (layered navigation, hreflang tags, schema markup). Each extension may store configuration differently. Document all SEO-related extensions and their equivalents on the new platform.

WooCommerce plugin management and permalinks

WooCommerce runs on WordPress, which gives it strong SEO fundamentals (especially with plugins like Yoast SEO or Rank Math), but also means migrations involve WordPress-specific considerations around plugins, custom post types, and permalink structures.

If you are migrating to WooCommerce from another platform, you will need to set up your WordPress permalink structure to match (or redirect from) your old URLs. WordPress uses a configurable permalink pattern, so you have more flexibility than Shopify, but you need to choose your pattern before importing any products.

If you are migrating away from WooCommerce, the challenge is extracting data from WordPress’s database structure, where products are stored as custom post types with metadata spread across the wp_postmeta table.

Things to watch for as a PM:

• Plugin conflicts during migration. WooCommerce stores rely on a stack of plugins for payments, shipping, SEO, and marketing. During migration, disable all non-essential plugins to avoid conflicts, then re-enable and test one by one.
• Permalink structure. WooCommerce product URLs default to /product/product-name/. If the old site used a different pattern, set up your permalink structure before importing products, not after. Changing permalinks after import creates orphaned URLs.
• SEO plugin migration. If you are moving between SEO plugins (e.g., from Yoast to Rank Math), use the destination plugin’s built-in migration tool to transfer meta titles, descriptions, and canonical settings. Verify a sample of 20-30 pages after migration to confirm the data transferred correctly.
• Order and customer data. WooCommerce stores orders and customer accounts as custom post types. These are important for business continuity but do not directly affect SEO. Make sure your engineering team has a separate plan for migrating this data.

A migration done right is one of the few projects where the PM’s impact is immediately measurable. Your traffic either holds (or grows), or it does not. The difference between those outcomes is not luck and it is not the platform you choose. It is the planning you put in before a single line of code changes, the discipline of your staging QA process, and your willingness to monitor and fix issues fast when they appear.

Download the checklists from this guide, adapt them for your project, and start your pre-migration audit before your next sprint planning session. If you have run a migration (successful or otherwise), share your experience in the comments. The best migration advice comes from people who have been through it.

References

• Google Search Central — Site moves with URL changes
• Google Search Central — 301 redirects
• Google Search Central — Managing crawl budget
• Google Search Central — Canonicalization
• Google Search Central — Robots.txt specification
• Google Search Central — Sitemaps overview
• Google Search Central — Soft 404 errors
• Google Search Central — HTTPS as a ranking signal
• Google Search Central — Core Web Vitals and page experience
• Web.dev — Core Web Vitals
• Google Search Console
• Google Analytics
• Google Tag Assistant
• Google PageSpeed Insights
• Screaming Frog SEO Spider
• Ahrefs
• Semrush
• Shopify — URL redirects documentation
• Adobe Commerce — Data migration tool
• WordPress — Customizing permalinks