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

🔁 SEO · Updated June 2026 · 16 min read · by Jacob Campbell

I’m Jacob Campbell, and 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 30+ sites — from small blogs to 500,000-page ecommerce stores — and learned exactly what preserves (and often improves) SEO value. Follow this guide to avoid the common mistakes.

Key facts

• 7 — Phases
• 301 — Permanent redirects
• 1:1 — URL mapping
• 0% — Traffic lost (case study)

Why migrations fail — the uncomfortable truth

Most failed migrations share the same handful of causes:

• 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 on a staging environment.

This guide addresses each one. Follow every step and you’ll preserve — sometimes even improve — your rankings.

Phase 1: Pre-migration audit — capture your SEO baseline

Before you touch anything, document your current SEO performance. You’ll need it to compare after launch.

• Crawl your whole site with Screaming Frog (free up to 500 URLs) — pull all internal URLs, title tags, meta descriptions, H1s, canonical tags, response codes and links. Export to CSV: this becomes your master URL-mapping list.
• Record your top 50 keyword positions from Search Console or SEMrush/Ahrefs — positions, impressions and CTR for the last 3 months.
• Document organic traffic levels in GA4 — last 30 days of organic sessions, bounce rate and conversions. Screenshot it.
• Download all backlinks — Search Console → Links → External links → Export. Make sure those old URLs redirect correctly.
• Save the XML sitemap — a quick list of every indexed URL.

Phase 2: URL mapping — the most critical step

If you keep exactly the same URL paths, you avoid most migration risk. But you’ll often want to clean URLs up (strip dates, shorten categories). Build a 1:1 map of every old URL to its new equivalent.

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

Build the map in a spreadsheet for small sites, or a Python/regex script for large ones. Save it as CSV with columns old_url, new_url.

Phase 3: Implement 301 redirects

A 301 tells Google “this page moved permanently,” passing ~100% of the old page’s ranking power to the new URL. Never use 302 (temporary) redirects for permanent moves.

Apache .htaccess (best for <200 redirects):

Redirect 301 /2023/01/why-custom-php /blog/why-custom-php

PHP redirect map (best for thousands):

<?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;
}

Nginx (use map for many redirects):

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

Critical rule — no redirect chains. Never do A → B → C; each hop loses link value. Always redirect A → C directly.

Phase 4: Preserve metadata — titles, descriptions, canonicals

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

• On a CMS (WordPress, Shopify), export metadata via plugin or CSV.
• On a custom PHP site, store metadata in a database table or a PHP array keyed by URL:

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

Phase 5: Test everything on staging

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

• All redirects — crawl the old URLs with Screaming Frog and confirm each returns a 301 to the new URL.
• Metadata — spot-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 the old site, debug before launch.

Phase 6: Launch day — switch DNS and submit the sitemap

• Point DNS to your new server (set TTL to 300 seconds in advance).
• Immediately submit your new XML sitemap in Search Console (Sitemaps → Add).
• Use “Inspect URL” to fetch as Google and request indexing of your most important pages.
• Monitor logs in real time for 404s (a server log viewer or a tool like LogHound).

Phase 7: Post-launch monitoring — the first 30 days

This is where most migrations fail — people launch and assume everything is fine.

Daily (first week):

• Search Console → Coverage → Errors. Any 404s? Fix immediately by adding the missing redirect.
• GA4 → Realtime to confirm traffic is reaching the new site.

Weekly (weeks 2–4):

• Compare organic traffic to your pre-migration baseline. A small dip (5–10%) is normal; anything larger signals a problem.
• Re-run the top-keyword report. If positions dropped for specific pages, check 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 you didn’t accidentally block robots.txt or add noindex tags, make sure the new site is faster (speed gains often offset small redirect losses), and resubmit the sitemap.

Common migration mistakes (and how to avoid them)

• HTTP → HTTPS without redirecting all HTTP URLs. Fix: add a global server-level HTTP→HTTPS redirect.
• Moving to a new domain without updating Search Console. Fix: add the new domain as a property and submit a Change of Address.
• Losing image URLs (broken images). Fix: keep the same path structure for uploads, or redirect old image URLs.
• Internal links hard-coded to old URLs. Fix: search-and-replace in your database or code 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/product-name/.

Process:

• Exported all old URLs from the Magento database.
• Generated new SEO-friendly slugs from product names.
• Built a 50,000-row mapping CSV.
• Used a PHP redirect map (JSON file) for the 301s — no bloated .htaccess.
• Preserved all metadata 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 rose 12% from faster page loads (custom PHP vs Magento).
• No 404s in Search Console after the first week.
• Revenue from organic traffic rose 18% in 3 months.

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

Migration checklist

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

Sources &amp; further reading

• Google — Site moves with URL changes
• Google — Redirects and Google Search
• Screaming Frog SEO Spider

Related services

• Migrate WordPress to custom PHP — The WordPress-specific version of this playbook.
• Technical SEO checklist — What to verify after you launch.
• What makes a website load fast — Why the new site should be faster.

Frequently asked questions

Will I lose rankings during a platform migration?

Not if you map URLs 1:1 and add 301 redirects. Most sites see no change or a slight gain from faster load; small short-term dips usually recover.

What’s the most critical migration step?

URL mapping plus 301 redirects. Changing URLs without redirects is the number-one cause of lost rankings.

Should I test before launching?

Always. Clone to a staging subdomain and crawl every old URL to confirm it 301s to the right new URL before going live.

How long should I monitor after launch?

Daily for the first week and weekly for a month — watch Search Console coverage, fix 404s fast, and compare traffic to your baseline.

301 vs 302 — which should I use?

301 (permanent). A 302 is temporary and doesn’t reliably pass ranking signals, so never use it for a permanent move.

How much does a custom PHP site cost?

Three flat-fee packages: a business pro site at $1,750, an ecommerce site at $5,600, and SaaS / web apps at $10,000 — all one-time, no monthly fees.

Do you handle the whole migration?

Yes — URL mapping, redirect implementation, metadata migration, staging tests and 30 days of post-launch monitoring.