← Back to all articles

SEO Migration Guide: How to Switch Platforms Without Losing Rankings (2026)

July 2025 16 min read

Whether you're moving from WordPress to custom PHP, Shopify to WooCommerce, or any platform to another, the risks are the same: lost traffic, dropped rankings, and broken links. I’ve migrated over 30 sites – from small blogs to 500,000‑page ecommerce stores – and learned exactly what preserves (and often improves) SEO equity. Follow this guide to avoid the common pitfalls.

Why Migrations Fail – The Hard Truth

Over 60% of site migrations result in a significant traffic drop (source: SEMrush). The most common reasons:

  • Changing URL structures without implementing 301 redirects.
  • Losing metadata (title tags, meta descriptions, canonical tags).
  • Breaking internal links because of new URL patterns.
  • Launching without testing redirects in a staging environment.

This guide addresses each of these issues. Follow every step, and you’ll preserve – sometimes even improve – your rankings.

Phase 1: Pre‑Migration Audit – Capture Your SEO Baseline

Before touching anything, document your current site’s SEO performance. You’ll need this to compare after launch.

1. Crawl Your Entire Site

Use Screaming Frog SEO Spider (free up to 500 URLs) to extract:

  • All internal URLs (including images, PDFs, etc.).
  • Title tags, meta descriptions, and H1s for each page.
  • Canonical tags.
  • Response codes (200, 301, 404).
  • Internal and external links.

Export the crawl to CSV. This becomes your URL mapping master list.

2. Record Rankings for Top 50 Keywords

Use Google Search Console (Performance report) or a paid tool like SEMrush/Ahrefs. Export keyword positions, impressions, and CTRs for the last 3 months.

3. Document Organic Traffic Levels

In Google Analytics (or GA4), record the last 30 days of organic sessions, bounce rate, and conversion data. Take screenshots. You’ll compare these post‑launch.

4. Download All Backlinks

Google Search Console → Links → External links → Export. Save the list of linking domains and pages. You’ll want to ensure these old URLs redirect correctly.

5. Save XML Sitemap

If your old site has a sitemap (e.g., `/sitemap.xml`), download it. It’s a quick list of all indexed URLs.

Phase 2: URL Mapping – The Most Critical Step

If you keep the exact same URL paths, you avoid most migration risks. But often you’ll want to clean up URLs (remove dates, shorten categories). Create a 1:1 mapping from every old URL to its new equivalent.

Example Mapping Rules:

/2023/01/why-custom-php      →  /blog/why-custom-php
/category/web-design         →  /services/web-design
/product?id=123              →  /products/widget-name
/contact-us                  →  /contact (keep same if possible)

Tools to Build Your Mapping File:

  • Manual Excel/Google Sheets – for small sites (<500 URLs).
  • Python script using regex – for large sites.
  • CMS export + spreadsheet formulas – if your new platform has a pattern.

Save the mapping as a CSV with columns: old_url, new_url.

Phase 3: Implement 301 Redirects

A 301 redirect tells Google: “This page permanently moved.” Google transfers nearly 100% of the old page’s ranking power to the new URL. Never use 302 (temporary) redirects for permanent moves.

Option A – Apache .htaccess (best for < 200 redirects)

Redirect 301 /old-url /new-url
Redirect 301 /2023/01/why-custom-php /blog/why-custom-php

Option B – PHP Redirect Map (best for thousands of redirects)

Place this at the top of your index.php:

<?php
$redirects = json_decode(file_get_contents(__DIR__ . '/redirects.json'), true);
$request = $_SERVER['REQUEST_URI'];
if (isset($redirects[$request])) {
    header('HTTP/1.1 301 Moved Permanently');
    header('Location: ' . $redirects[$request]);
    exit;
}
?>

Generate redirects.json from your CSV mapping.

Option C – Nginx (use `map` for many redirects)

map $request_uri $new_uri {
    /old-url      /new-url;
    /old-url2     /new-url2;
}
server {
    if ($new_uri) {
        return 301 $new_uri;
    }
}

Critical Rule: No Redirect Chains

Never do A → B → C. Each hop loses a small amount of link equity. Always redirect directly A → C.

Phase 4: Preserve Metadata – Title Tags, Meta Descriptions, Canonicals

Your new site must output the exact same title tags and meta descriptions as the old site (or better).

  • If you’re using a CMS (WordPress, Shopify), export metadata via plugin or CSV.
  • If you’re building a custom PHP site, store metadata in a database table or a PHP array keyed by URL.

Example custom PHP implementation:

<?php
$pageMetadata = [
    '/services/web-design' => [
        'title' => 'Custom Web Design | BuiltToWinWeb',
        'description' => 'Hand‑coded PHP websites that score 100 on Lighthouse.'
    ]
];
if (isset($pageMetadata[$_SERVER['REQUEST_URI']])) {
    $meta = $pageMetadata[$_SERVER['REQUEST_URI']];
    echo '<title>' . htmlspecialchars($meta['title']) . '</title>';
    echo '<meta name="description" content="' . htmlspecialchars($meta['description']) . '">';
}
?>

Phase 5: Test Everything in a Staging Environment

Before going live, clone your site to a staging subdomain (e.g., staging.yourdomain.com). Test:

  • All redirects – use Screaming Frog to crawl the old URLs and verify they return 301 to new URLs.
  • Metadata – check a sample of pages for correct titles and descriptions.
  • Internal links – no broken links to old URLs.
  • Core Web Vitals – run Lighthouse. If scores are worse than old site, debug.

Phase 6: Launch Day – Switch DNS and Submit Sitemap

When you’re ready:

  1. Point DNS to your new server (TTL should be set to 300 seconds beforehand).
  2. Immediately submit your new XML sitemap in Google Search Console (Sitemaps → Add).
  3. Use the “URL Inspection” tool to fetch as Google and request indexing for your most important pages.
  4. Monitor real‑time logs for 404 errors (use server log viewer or a tool like LogHound).

Phase 7: Post‑Launch Monitoring – The First 30 Days

This is where most migrations fail – they launch and assume everything is fine.

Daily Checks (First Week):

  • Google Search Console → Coverage → Errors. Any 404s? Fix them immediately (add missing redirects).
  • Google Analytics → Real‑time to ensure traffic is landing on the new site.

Weekly Checks (Weeks 2‑4):

  • Compare organic traffic with pre‑migration baseline (Google Analytics). A small dip (5‑10%) is normal; anything larger indicates a problem.
  • Re‑run the top keywords report. If rankings dropped for specific pages, check if those URLs redirect correctly.
  • Monitor backlink 404s – use Ahrefs or GSC to see if external links are now broken.

If You See a Drop:

  • Check that you didn’t accidentally block robots.txt or add `noindex` tags.
  • Ensure the new site is faster (Core Web Vitals). Speed improvements often offset small redirect losses.
  • Re‑submit the sitemap and use “Inspect URL” on a few key pages.

Common Migration Pitfalls (And How to Avoid Them)

  • Pitfall: Changing from HTTP to HTTPS without redirecting all HTTP URLs. Fix: Add a global HTTP→HTTPS redirect at the server level.
  • Pitfall: Migrating to a new domain and not updating Google Search Console property. Fix: Add the new domain as a property and submit a change of address.
  • Pitfall: Losing image URLs (broken images). Fix: Keep the same path structure for `/wp-content/uploads/` or create redirects for image URLs.
  • Pitfall: Internal links pointing to old URLs (hardcoded). Fix: Use a find‑and‑replace on your database or codebase before launch.

Case Study: 50,000‑Page Ecommerce Migration – 0% Traffic Loss

A large online retailer moved from Magento to a custom PHP platform. The challenge: 50,000 product URLs had to change from `/catalog/product/view/id/123/` to `/products/widget-name/`.

Process:

  • Exported all old URLs from Magento database.
  • Generated new SEO‑friendly slugs based on product names.
  • Created a CSV mapping with 50,000 rows.
  • Used a PHP redirect map (JSON file) to handle 301s – no .htaccess bloat.
  • Preserved all metadata (titles, descriptions) by storing them in a custom table keyed by new URL.
  • Staged and tested redirects with a crawler – 99.8% coverage.

Results:

  • Zero organic traffic loss in the first 30 days.
  • After 60 days, traffic increased by 12% due to faster page load (custom PHP vs Magento).
  • No 404 errors in Search Console after Week 1.
  • Revenue from organic search increased by 18% within 3 months.

The client now owns the code, pays no Magento licensing fees, and can update URLs instantly.

Migration Checklist (Printable PDF Summary)

  • ☐ Pre‑migration: crawl, rankings, traffic, backlinks, sitemap.
  • ☐ URL mapping: 1:1 CSV of old → new.
  • ☐ Implement 301 redirects (no chains).
  • ☐ Preserve metadata (titles, descriptions, canonicals).
  • ☐ Test in staging (Screaming Frog crawl, Lighthouse).
  • ☐ Launch: DNS, submit sitemap, inspect URLs.
  • ☐ Monitor GSC daily for 30 days, fix 404s.
  • ☐ After 30 days, compare rankings and traffic.

Ready to Migrate Without the Stress?

I’ve migrated over 30 sites – from small business blogs to enterprise ecommerce. I handle the entire process: URL mapping, redirect implementation, metadata migration, staging testing, and post‑launch monitoring. You’ll keep your rankings and often see a performance boost.

Let’s talk about your migration. I’ll provide a free, no‑obligation migration plan and quote.

Let Me Handle Your Migration →

Data from real client migrations performed by BuiltToWinWeb. Individual results may vary based on site complexity and existing SEO health.