Most site owners assume a platform migration is “just moving files and clicking a DNS switch.” I learned the hard way that if you treat it like that, you do not just lose a bit of traffic, you nuke years of SEO equity in a single weekend.
The short version: if you want to move platforms without losing SEO, you must keep URLs stable where possible, map every changed URL to a correct 301, preserve metadata (titles, descriptions, headings, canonical tags), carry over structured data, replicate internal links, and run the old and new stacks in parallel long enough to test with crawling tools and staging domains. The DNS cutover is the last step, not the first.
What “Migrating Platforms” Really Means For SEO
Moving from WordPress to Webflow, from a custom PHP stack to a headless CMS, from Discourse to another forum engine, or from Shopify to WooCommerce is not just a design decision. It is a structural change that search engines interpret as a signal about content, authority, and stability.
If search engines cannot connect your old URLs and signals to your new URLs, they will treat large parts of your “new” site as an unknown site.
The search crawler does not care that your marketing team changed tools. It cares about:
- URL structures
- Server responses (status codes, headers, speed)
- Content similarity and quality
- Internal linking patterns
- Canonicalization and duplicates
- Structured data
- Backlink targets
When you switch platforms, all of those can shift at once. That is why migrations go bad. Too many variables change, and no one keeps track.
Step 1: Define the Type and Scope of Migration
Migration is not a single thing. The SEO risk depends on what you are changing.
| Migration Type | Example | SEO Risk Level | Key Issues |
|---|---|---|---|
| Platform / CMS only | WordPress to Webflow, same domain and URLs | Low to medium | Templates, meta tags, performance, markup |
| Platform + URL structure | /blog/post-name to /articles/post-name | High | Redirect mapping, internal links, sitemaps |
| Domain change | example.com to example.net | High | Domain redirects, canonical signals, backlink loss |
| Protocol change | HTTP to HTTPS | Low | Mixed content, redirect chains, canonical tags |
| Architecture change | Subfolders to subdomains, monolith to headless | Medium to high | Internal linking, crawl depth, hreflang, CORS |
You cannot plan sane SEO safeguards if you do not first lock down exactly what is changing.
Change one big thing at a time where possible: platform, domain, URL structure. Combining all three and expecting stability is optimistic at best.
Checklist: What Is Actually Changing?
Make a short, brutally honest inventory:
- Domain: same or different?
- Protocol: HTTP to HTTPS, or already HTTPS?
- URL paths: same slugs and directories, or new ones?
- Content model: same content types, or merging/splitting them?
- Templates: same H1/H2/H3 patterns, or redesigned?
- CDN / hosting: staying with same provider, or moving?
- JS framework: more client-side rendering or less?
Every “yes, this is changing” line item is a risk multiplier.
Step 2: Crawl and Export the Current Site Before You Touch Anything
Before you move a pixel, freeze the current site in a form you can audit.
You need a complete inventory of:
- All crawlable URLs
- Current status codes (200, 301, 404, etc.)
- Title tags and meta descriptions
- Canonical tags
- H1 headings
- Internal links and anchor text
- Structured data snippets
Use a crawling tool (Screaming Frog, Sitebulb, or similar). Export everything to CSV. This is your baseline.
Also export from:
- Google Search Console: “Pages” report, sitemaps, top queries, top pages
- Analytics: pages with organic traffic, conversions, and engagement
- Backlink tools (Ahrefs, Majestic, etc.): top-linked pages and anchors
Your “must not lose” pages are the ones with both backlinks and organic traffic. Those get priority for 1:1 URL preservation and perfect redirects.
At this point, you should have:
- A list of all URLs
- A subset of high-value URLs
- Metadata and structure for each URL
This is the reference that will drive mapping and QA later.
Step 3: Decide What to Keep, Merge, or Kill
A migration is also a chance to clean up. Just understand that every change has SEO cost.
You have three main actions for each URL:
- Keep: Content and URL both survive as-is or nearly as-is
- Merge: Content combines with another URL (canonical consolidation)
- Kill: Content is removed (with a 410 or a redirect to the closest match)
When to Keep
Preserve URLs and content when:
- The page has solid backlinks
- The page ranks for queries you want
- The content is still accurate and useful
If you must change anything, change template and layout, not the URL.
When to Merge
Sometimes you have:
- Multiple short articles competing for the same query
- Tag/category archives with thin content
- Near-duplicate product pages
Consolidating these into a stronger single page can help long term. Short term, you need:
- 301 redirects from all old variants to the new canonical
- Updated internal links to point to the new URL
- Updated sitemaps
When to Kill
Remove content that is:
- Outdated and not worth updating
- Low traffic and no backlinks
- Thin or duplicate with no clear user value
Return:
410 Gonefor content intentionally removed404 Not Foundif you really have nothing to replace it with
If you have a close successor, a 301 to the next best match is safer.
Step 4: Design the New URL Structure Carefully
Your new platform will push a preferred URL scheme. That is not always aligned with SEO or with your existing structure. You need to control it.
Principles for SEO-Friendly URL Migration
- Keep high-value URLs identical where possible
- Avoid adding query strings where you previously had clean paths
- Avoid switching from lowercase to mixed case paths
- Keep slugs short, descriptive, and stable
- Do not change file extensions unless your platform forces it
Common traps:
- WordPress to Headless: moving from /category/post-name to /blog/post-name or worse /posts/12345
- Shopify to something else: losing the /products/, /collections/ prefixes and messing up product canonicalization
- Forum migrations: changing topic IDs or path patterns and breaking long-standing links from other sites
If a URL structure “looks nicer” but breaks thousands of existing backlinks, it is not nicer in practice.
Build a URL pattern map: for each content type (blog post, product, doc, category, topic), define:
- Old pattern
- New pattern
- Variables (slug, ID, category path, etc.)
This will drive your redirect rules.
Step 5: Build a Complete Redirect Map
This is non-negotiable. The redirect map is the core protection against losing SEO during a migration.
You need a one-to-one map:
| Old URL | New URL | Status |
|---|---|---|
| https://example.com/blog/how-to-host-a-forum | https://example.com/articles/how-to-host-a-forum | 301 |
| https://example.com/forum/topic/1234 | https://community.example.com/t/1234 | 301 |
| https://example.com/old-tool | https://example.com/tools/new-tool | 301 |
Redirect Rules: What to Watch
- Use 301, not 302, for permanent migrations
- Avoid redirect chains (A -> B -> C). Target A -> C directly
- Avoid redirect loops of any kind
- Cover all HTTP/HTTPS and www/non-www variations consistently
- Keep rules maintainable (pattern rules where possible, explicit where necessary)
If you have more than a few hundred URLs, pattern-based rules are your friend, but test them against your exported URL list with a tool or script.
A partial redirect map is almost as bad as none. Search engines will always find the one stale URL you forgot if it has the best backlink profile on your site.
Remember to:
- Update internal links to the new URLs, not rely on internal redirects
- Update canonical tags and sitemaps to new URLs only
Step 6: Replicate On-Page SEO: Titles, Headings, Canonicals, Schema
Platform migrations often strip or rewrite metadata. That is where a lot of soft SEO damage happens.
Title Tags and Meta Descriptions
Carry over:
- Title tags for all important pages
- Meta descriptions where they are meaningful and not auto-generated junk
If your new platform uses templates (for example %post_title% | Brand), validate that long titles do not get truncated into nonsense.
Headings and Content Structure
Check that:
- Each page still has one logical H1
- Subheadings (H2, H3) remain in a sensible hierarchy
- New design does not hide text behind tabs or accordions for key content
A migration that replaces real content with heavy JavaScript widgets or lazy-loaded sections can silently reduce what search engines index.
Canonical Tags
Common migration errors:
- Omitting canonical tags entirely on templates that previously used them
- Self-referencing canonicals that still point to old URLs or HTTP versions
- Canonicals pointing at staging domains or different hostnames
For each key URL, verify:
- Canonical exists
- Canonical matches the primary new URL
- Canonical protocol and domain are correct
Structured Data (Schema)
If you had schema.org markup before (Article, Product, BreadcrumbList, FAQPage, etc.), re-implement it on the new platform.
Common issues:
- JSON-LD snippets removed in new templates
- Microdata attributes lost when HTML structure changes
- Structured data pointing at old URLs or author profiles that no longer exist
Test the new pages with a structured data testing tool and clear any validation errors.
Step 7: Plan Hosting, Performance, and Rendering
Platform migrations often come with new hosting, CDNs, or rendering models. Those are not just “infrastructure concerns”. They are SEO concerns.
Server Performance and Latency
Search engines reward fast, stable responses. A move from a tuned VPS to a cheap shared host can hurt.
Check:
- Time to first byte (TTFB) on key pages
- Response consistency during peak traffic
- Caching strategy (page caching, CDN caching, headers)
Use WebPageTest, Lighthouse, or similar tools, but pay more attention to server timings and real user metrics than to synthetic “scores”.
CDN and Geo-Distribution
If your user base is global, keep or add a CDN. Watch for:
- Correct cache-control headers
- Consistent use of HTTPS and HSTS
- Proper handling of cookies so the CDN can cache HTML where valid
Client-Side vs Server-Side Rendering
Moving to a JS-heavy SPA or headless front end can break indexing if you ignore rendering.
Key questions:
- Are pages fully rendered HTML at first response, or is content injected by JS after load?
- If JS is required, is there server-side rendering (SSR) or pre-rendering?
- Can you view-source and still see the core content and links?
If critical content only appears after JS runs, you are trusting search bots to execute your app perfectly. They often will not.
For critical landing pages, prefer server-rendered or statically generated HTML.
Step 8: Build and Test on a Staging Environment
Never do a blind switchover. Put the new platform on:
- A staging subdomain (staging.example.com)
- Or a password-protected host
Then:
- Block staging with HTTP auth or by IP restriction. Do not rely only on robots.txt.
- Crawl staging with the exported URL list as a seed.
- Compare:
- Titles, descriptions, H1s
- Status codes (no unexpected 404s or 5xx)
- Canonical tags and hreflang if you use it
- Structured data presence
Test redirect rules before launch by pointing a local hosts file at the new server and crawling.
If you have never used your hosts file to preview DNS changes, do not learn how during a live migration window.
Also test:
- Form submissions and redirects after forms
- Login flows, if they are on the same domain
- Search functionality
Broken UX means poor engagement metrics, which do not help post-migration recovery.
Step 9: Update XML Sitemaps and Robots.txt
Once the new platform is ready:
XML Sitemaps
- Generate new sitemaps with only new URLs
- Remove staging URLs or test paths
- Keep sitemap size within limits or split into logical sections
Avoid listing URLs that redirect. Sitemaps should reflect canonical, indexable URLs.
Robots.txt
Check:
- You are not blocking the entire site by mistake
- Important paths are not disallowed
- Staging rules (Disallow: /) are not accidentally shipped to production
Add sitemap location lines:
Sitemap: https://example.com/sitemap.xml
Step 10: Prepare Analytics and Tracking Before the Cutover
Analytics gaps during a migration make troubleshooting guesswork.
- Verify tracking tags in new templates (GA4, server-side analytics, or whatever you use)
- Preserve the same property / view where logical to keep history intact
- Verify event tracking (signups, purchases, downloads)
Set up annotations or notes for the migration date in your tools, so you can correlate traffic shifts.
Step 11: Execute the Migration with Controlled DNS and Redirects
When you are confident in staging and mapping:
- Deploy redirect rules on the old or new host at the same time as content goes live
- Switch DNS with a reduced TTL, so changes propagate faster
- Monitor logs for unexpected 404s, 5xx responses, and heavy bot traffic
If you are changing domains:
- Verify that the old domain 301s everything to the new domain correctly
- Set up a “Change of Address” in Google Search Console for the old domain
The correct order is: deploy content, deploy redirects, verify locally, then change DNS. Not the other way around.
Step 12: Post-Migration Monitoring and Fixes
Expect some turbulence. The aim is to keep it small and fixable.
Monitor Crawling and Indexing
In Google Search Console and similar tools:
- Watch the “Pages” and “Crawl stats” reports
- Check for spikes in 404 or soft 404s
- Check for pages marked as “Alternate page with proper canonical tag” that should be canonical
Export error URLs and fix with:
- New redirects where missing
- Template fixes where canonicals or meta robots tags are wrong
Monitor Rankings and Traffic
Track:
- Organic traffic by landing page
- Average position for key queries
- Click-through rates where titles or snippets changed
Short term dips are normal. Severe, sustained drops often point to:
- Broken redirects or chains
- New noindex tags
- Loss of content depth
- Rendering issues with JS-heavy pages
Re-crawl with Your Own Tools
Run another full crawl on the live site:
- Check the redirect map against reality
- Find internal links still pointing at old URLs
- Spot canonical inconsistencies and 4xx/5xx responses
Each issue you fix early prevents search engines from “learning” the wrong structure.
Special Cases: Forums, Communities, and Web Apps
Sites that are more community than brochure have some extra complexity.
Forum and Community Migrations
If you are moving, for example, from phpBB to Discourse, or Discourse to Flarum:
- Preserve topic IDs where possible, or maintain a consistent mapping
- Preserve user profile URLs, or redirect them carefully
- Preserve pagination and linking between pages of long threads
Watch for:
- Content hidden behind JS front ends without server-side rendering
- “Latest” views becoming default instead of canonical thread URLs
- Search result pages getting indexed if not blocked
The real SEO asset for a forum is the long-tail content in threads that have aged well. Breaking those URLs breaks the archive value.
Web Apps and SaaS Platforms
For apps, you often have:
- A marketing site
- An app domain or subdomain
Keep marketing and app migrations separate where reasonable. Moving both at the same time makes debugging very hard.
Common issues:
- App-specific redirects interfering with marketing URLs
- Authenticated content getting indexed because of misconfigured robots headers
- Single-page app routes exposed under the main domain and confusing crawlers
Common Myths About SEO and Migrations
Some persistent myths cause people to under-plan.
“Search engines will figure it out”
Search bots are not mind readers. They follow links, redirects, and canonicals. If you send conflicting signals, they do not “figure it out”. They test, then sometimes downrank.
“Short 302s are fine during migration”
A 302 is a temporary redirect. Use 301 for permanent moves. If you keep 302s, search engines may keep the old URL in the index for much longer.
“We can fix SEO later”
You can patch things later, but early damage can linger. Once search engines downgrade a URL or drop it from the index, you need to rebuild trust signals.
Treat the migration as an SEO project with dev work, not a dev project with a bit of SEO glitter sprinkled on top.
Practical Timeline for a Safe Migration
A rough, realistic order for a medium-sized site:
4-6 weeks before
- Crawl and export old site
- Define scope and URL patterns
- Identify high-value pages
- Draft redirect rules and mapping
2-4 weeks before
- Build out staging environment
- Replicate metadata, canonicals, schema
- Implement redirect rules on staging or in configs
- Test with crawl against exported URLs
1 week before
- Finalize sitemaps and robots.txt for production
- Lower DNS TTL
- Validate tracking and performance
Launch day
- Deploy content and redirects
- Switch DNS
- Spot check key URLs, forms, and flows
- Watch logs for errors and unexpected paths
First 4 weeks after
- Daily checks of Search Console errors for the first week
- Weekly rank and traffic review
- Incremental fixes to redirects, internal links, canonicals
If you follow that level of discipline, a platform migration becomes a controlled SEO event instead of a demolition.
