SEO Site Migration: How to Change Platforms Without Losing Traffic

A new website should be a step forward, but many businesses watch their search traffic fall after launch and spend months trying to recover. The cause is rarely the new design. It is usually what happened to URLs, content and technical signals during the move. A planned SEO site migration protects the rankings you have earned while you change platforms, domains or structure. This guide covers the full process, from inventory and redirect mapping to launch-day checks and post-launch monitoring.

What counts as an SEO site migration

Any change that significantly affects how search engines find and understand your site is a migration. Common types:

• Platform change — for example, WordPress to Laravel, or a hosted store to a custom build.
• Domain change — rebranding, moving from a country domain to a .com, or merging sites.
• URL structure change — new categories, removing dates from blog URLs, adding language folders.
• Protocol or subdomain change — HTTP to HTTPS, www to non-www, or moving a blog from a subdomain to a subfolder.
• Major redesign — new templates, navigation and content at the same URLs.

Each carries risk in proportion to how much changes. Combining several at once multiplies that risk.

Why migrations lose traffic

Search engines associate rankings with specific URLs and the content on them. When those change, signals must be transferred. Traffic drops usually come from:

1. Missing redirects — old URLs return 404, so their rankings and backlinks are lost.
2. Wrong redirects — everything redirected to the home page or to loosely related pages.
3. Lost content — pages removed or heavily shortened in the redesign.
4. Lost metadata — titles, descriptions, headings and structured data not carried over.
5. Technical blocks — noindex tags, robots.txt disallow rules or authentication left over from staging.
6. Internal linking changes — important pages buried deeper in the new navigation.
7. Performance regressions — a slower new site with poorer Core Web Vitals.

All of these are preventable with preparation.

Phase 1: Inventory everything

Before any URL changes, build a complete list of what exists today. Combine these sources:

• A full crawl of the current site.
• XML sitemaps.
• Google Search Console performance data (pages with clicks and impressions).
• Analytics landing page data over at least the past year.
• Backlink data showing which URLs other sites link to.
• Server logs, if available, for URLs bots still request.

Record for each URL: traffic, conversions, backlinks, title, meta description, H1 and whether it should be kept, merged or retired. This baseline also lets you measure the migration's impact later.

Phase 2: Map every old URL to a new one

The redirect map is the heart of the migration. For each old URL, decide where it goes:

Use one-to-one redirects wherever possible and avoid redirect chains (old URL to interim URL to final URL). If you have previous redirects from older migrations, update them to point directly to the final destination.

For large sites, pattern-based rules help, for example redirecting /products/{id}-{name} to /shop/{name}. Always test patterns against your full URL list; edge cases are where traffic disappears.

Key takeaway: Every URL that has traffic or backlinks needs a deliberate destination. A complete, tested redirect map does more to protect rankings than any other migration task.

Phase 3: Carry content and signals across

The new site should keep, or improve, what made old pages rank:

• Body content on important pages, especially sections that answer search queries.
• Titles, meta descriptions and headings, updated thoughtfully rather than discarded.
• Structured data for products, articles, breadcrumbs and organization.
• Image alt text and file names for important images.
• Canonical tags and hreflang for multilingual sites.
• Internal links between related pages.

If you are moving from WordPress, our guide to WordPress to Laravel migration covers content export and data mapping in more detail.

Phase 4: Test on staging

Before launch, test the new site in a staging environment that is blocked from search engines (password protection is safest). Check:

1. Every URL in the redirect map resolves to the intended destination with a 301 status.
2. No redirect chains or loops.
3. Templates output correct titles, canonicals, meta robots and structured data.
4. XML sitemaps list only new, indexable URLs.
5. Page speed is equal to or better than the old site on key templates.
6. Forms, checkout and tracking events work.
7. Mobile rendering is correct.

Crawl the staging site and compare it with your baseline crawl. Missing pages or sudden drops in word count on key templates are warning signs.

Phase 5: Launch day checklist

Choose a launch time when traffic is relatively low and your team is available to respond. On the day:

• Remove staging protection, noindex tags and blocking robots.txt rules.
• Deploy redirects and test a sample of high-value URLs immediately.
• Submit the new XML sitemap in Search Console.
• If the domain changed, use the Change of Address tool in Search Console and keep the old domain verified.
• Check that analytics and conversion tracking are recording.
• Update links you control: social profiles, email signatures, directory listings and paid ad destinations.

Phase 6: Monitor and fix

The weeks after launch are when problems surface. Monitor daily at first, then weekly:

• Search Console Pages report for new 404s, redirect errors and indexing exclusions.
• Crawl stats for server errors.
• Performance by page compared against your baseline for the same pages.
• Server logs for old URLs still being requested that are not redirected.
• Conversions, not just traffic, to catch broken forms or checkout steps.

Expect some fluctuation as search engines recrawl. Investigate quickly if important pages drop sharply or remain unindexed after a few weeks.

Planning timeline

For a typical business website, a migration plan might look like this:

The key point is to start SEO planning at the beginning of the redesign, not the week before launch.

Who should be involved

Migrations go wrong most often when SEO is treated as one person's last-minute task. Bring the right people in early:

• Developers, who build redirects, templates and server configuration.
• SEO lead, who owns the inventory, redirect map and monitoring plan.
• Content owners, who decide which pages are kept, merged or retired.
• Marketing and sales, who know which pages and campaigns drive enquiries.
• Hosting or infrastructure team, who handle DNS, certificates and caching.

Agree in advance who signs off the redirect map and who is on call during launch week. Clear ownership turns a risky event into a routine release.

Special cases worth extra attention

• E-commerce stores, where product and category URLs, filters and discontinued items need careful mapping.
• Multilingual sites, where hreflang, language folders and translated slugs must all be carried over consistently.
• Sites with many PDFs or downloads, which often have their own backlinks and need redirects too.

Next steps

Platform changes are often the right decision for growth, security and maintainability. They just need to be managed carefully. DigiVort's website migration service combines development and SEO in one team, so redirects, templates and content are planned together. If you are considering a move, describe your current site in our project wizard and we will outline a migration plan that protects your traffic.