SEOmigrationseoredirects

How to Migrate Your Website Without Losing SEO

*9 min
Table of Contents

Website migration is one of the riskiest operations in digital marketing. Done poorly, a migration can wipe out years of SEO progress in a single day — lost rankings, broken links, vanished traffic that took years to build. Done correctly, it preserves your search equity and can even improve your organic performance by fixing structural issues that were holding your rankings back.

This guide covers the complete website migration process, from planning through execution to post-migration monitoring, with a focus on the SEO pitfalls that catch most businesses off guard. We will also cover migration-specific considerations for European businesses with multilingual sites and GDPR obligations.

Types of Website Migrations

Not all migrations are equal. The level of SEO risk depends on what is changing and how much is changing simultaneously:

Low Risk

  • Hosting migration: Moving to a new server or hosting provider without changing URLs or content. Minimal SEO risk if DNS propagation is handled correctly and SSL is set up before the switch.
  • HTTP to HTTPS: Required for security, a confirmed (if minor) ranking factor, and a trust signal for visitors. Well-documented process with predictable, manageable outcomes when implemented correctly.
  • Performance optimization: Improving page speed, image optimization, and Core Web Vitals without changing URLs or content structure. Usually beneficial for SEO, not harmful.

Medium Risk

  • Platform migration: Moving from WordPress to React or Next.js, for example. URL structures often change, templates differ, and content may need reformatting. High risk if URL mapping is incomplete.
  • Redesign with URL changes: New site design that includes restructuring the URL hierarchy. The redesign itself does not hurt SEO — the URL changes do, if not handled with proper redirects.
  • CMS migration: Moving from one content management system to another while keeping the same domain and URL structure. Content formatting issues, metadata loss, and broken internal links are common risks.

High Risk

  • Domain change: Moving from olddomain.com to newdomain.com. You are transferring all domain authority accumulated over years to a domain that Google does not yet trust. Even with perfect redirect implementation, some ranking power is lost in the transition.
  • Domain consolidation: Merging multiple domains into one. Common after business acquisitions, requires careful SEO planning to avoid losing the combined authority of all merged domains.
  • Domain + platform + content restructure simultaneously: Changing everything at once is the highest-risk scenario. Break it into phases if humanly possible — change the platform first while keeping URLs, then change domains if needed.

Pre-Migration Planning (4–6 Weeks Before)

Step 1: Benchmark Current Performance

Before touching anything, document your current state comprehensively. This data becomes your recovery baseline — if something goes wrong post-migration, you need these numbers to diagnose the issue and measure recovery:

  • Rankings: Track positions for your top 50–100 keywords using Ahrefs, Semrush, Mangools, or a rank tracker. Export to a spreadsheet you can compare against post-migration data.
  • Traffic: Export the last 12–18 months of organic traffic data from Google Analytics. Note seasonal patterns — a traffic drop during your low season might be normal, not migration-related.
  • Top pages: Identify your top 50 pages by organic traffic. These are your most valuable assets and must receive the most attention during URL mapping.
  • Backlinks: Export your complete backlink profile from Ahrefs or Semrush. Backlinks pointing to dead URLs after migration represent lost link equity that can take months to recover.
  • Indexed pages: Note the current total of indexed pages in Google Search Console. A significant decrease post-migration signals crawling or indexing problems.
  • Core Web Vitals: Record current field data CWV scores from Search Console as a performance baseline. A new site should not perform worse than the old one on CWV.
  • Click-through rates: Export CTR data per page from Search Console. CTR changes after migration indicate whether your new title tags and meta descriptions are working.

Step 2: Complete URL Mapping

This is the most critical step in the entire migration process. Incomplete URL mapping is the single most common cause of significant post-migration traffic loss. Create a comprehensive spreadsheet mapping every old URL to its new equivalent before a single line of redirect code is written:

  • Crawl the old site completely: Use Screaming Frog, Sitebulb, or a similar crawler to get every URL on the site — pages, blog posts, category pages, tag pages, images, PDFs, and downloadable files.
  • Map each URL one-to-one where possible: Old URL → New URL. Direct equivalents are always best. When pages are being consolidated, map to the most relevant remaining page.
  • Handle removed content carefully: If pages are being removed, redirect them to the most topically relevant remaining page — never to the homepage. Homepage redirects tell Google the content no longer exists, destroying the page's SEO value.
  • Preserve query parameters if used: If your old site used query parameters for filtering or tracking, ensure these are handled correctly in your redirect rules.
  • Include all content types: Pages, blog posts, images, PDFs, JavaScript files, CSS files, downloadable documents. Any asset that could have backlinks pointing to it must be handled.
  • Priority flag by traffic: Add a column marking each URL's pre-migration traffic. High-traffic URLs deserve extra verification — test their redirects multiple times before launch.

The fundamental rule: If a URL has organic traffic OR has backlinks pointing to it, it must be redirected to the correct destination. There are no acceptable exceptions to this rule.

Step 3: Prepare Redirect Rules

  • Use 301 (permanent) redirects for everything: 301 redirects pass approximately 90–99% of ranking power to the destination URL. Never use 302 (temporary) redirects for a migration — they do not pass link equity effectively.
  • Avoid redirect chains: A → B → C is a chain. Each hop in a chain loses a small amount of link equity and adds latency. If your mapping creates a chain because a URL was previously redirected, update it to redirect directly to the final destination: A → C.
  • Test every redirect on staging: Verify every redirect works and delivers to the correct destination before the migration goes live. For large sites, write a script to test all redirects automatically.
  • Handle trailing slash consistency: Decide on a convention — trailing slash or no trailing slash — and redirect the other form consistently across the entire site.
  • Handle case sensitivity: If your old site served /About and /about as the same page, both patterns need to redirect correctly on the new site.
  • Handle www vs non-www: Choose one canonical form and redirect the other. This should already be configured but verify it carries through the migration.

Step 4: Prepare the New Site Completely

The new site should be 100% complete before migration day. Common pre-launch gaps that cause problems:

  • Placeholder content still present on staging ("Lorem ipsum" text, placeholder images)
  • Forms not connected to real email endpoints
  • Analytics not configured on the new site
  • Structured data (JSON-LD) from the old site not replicated
  • Old robots.txt disallowing crawlers (staging sites are typically blocked)
  • Missing 404 error page customization
  • Internal links still pointing to old URLs instead of new URLs

Migration Execution Checklist

Pre-Launch (1–2 Days Before)

  1. Final crawl of the old site: One last check for any new pages or content changes since the URL mapping was created.
  2. Verify the staging site is complete: All content in place, no placeholder text, all forms functional.
  3. Test all redirects on staging: Spot-check at minimum 100 redirects, prioritizing high-traffic pages and pages with significant backlinks.
  4. Check staging robots.txt will not become production robots.txt: The most catastrophic migration mistake is going live with Disallow: / from a staging robots.txt. Verify explicitly.
  5. Prepare the new XML sitemap: Ready to submit to Search Console immediately after launch.
  6. Verify analytics tracking on the new site: Use the real-time view in Google Analytics to confirm events fire correctly.
  7. Inform all stakeholders: Let your team and relevant partners know the migration timeline, who to contact if problems arise, and what monitoring is in place.

Launch Day

  1. Deploy during low-traffic hours: Early morning on a Tuesday or Wednesday. Never on a Friday — if something goes wrong, you want your team available to fix it. Never during seasonal peaks.
  2. Activate all 301 redirects immediately upon deployment.
  3. Verify DNS propagation: Confirm the new site is accessible from multiple geographic locations and devices.
  4. Submit the new XML sitemap to Google Search Console within minutes of launch.
  5. Request indexing for your 10 most important pages via Search Console's URL Inspection tool.
  6. Verify analytics tracking is firing: Check real-time reports immediately after launch.
  7. Test all critical user journeys: Contact forms, checkout flows, navigation paths, search functionality.
  8. Check for mixed content warnings: Open browser developer tools and look for HTTP resources loading on the HTTPS site.
  9. Verify the new robots.txt is correct: No accidental Disallow: / directives from staging.
  10. Keep someone monitoring Search Console for the first 2 hours: Crawl errors and coverage issues appear quickly and benefit from immediate attention.

If Migrating Domains

  • Use Google's Change of Address tool in Search Console — it is under Settings and tells Google directly about the domain change.
  • Keep the old domain active with all redirects in place for a minimum of 12 months. Permanently is even better — backlinks from the old domain may drive traffic forever.
  • Update all external profiles: Google Business Profile, Bing Places, Facebook Business, LinkedIn company page, industry directories, partner websites, and any other platform that references your old domain.
  • Update email signatures, business cards, and printed materials — the domain change extends beyond the website.

Post-Migration Monitoring

Week 1: Daily Monitoring

  • Google Search Console: Check Coverage, Sitemaps, and Core Web Vitals reports daily. New crawl errors need immediate investigation.
  • 404 error tracking: Monitor 404 errors in your server logs or through an analytics tool. Each 404 from a previously-valid URL is a missing redirect that needs adding.
  • Organic traffic comparison: Compare daily organic traffic against the same day in the previous year (not the previous week, as day-of-week patterns differ). A 10–20% dip in the first week is within the normal range for a well-executed migration.
  • Ranking monitoring: Check your top 20 keywords for significant position drops. Small fluctuations are normal in the first two weeks.
  • Redirect validation: Revisit your redirect testing, particularly for pages that had the highest traffic and the most backlinks.

Weeks 2–4: Weekly Monitoring

  • Index coverage: Are your new pages being indexed? The indexed page count should be moving toward the pre-migration count.
  • Core Web Vitals field data: Monitor CWV in Search Console. New sites sometimes have worse CWV than the old site if optimization was overlooked during development.
  • Backlink health: Check that key backlinks are still resolving to working pages — not hitting 404s or redirect chains.
  • User behavior metrics: Compare bounce rates, average session duration, and conversion rates with pre-migration baselines. Behavioral regression can indicate content quality issues on the new site.
  • Crawl the new site: Run a fresh Screaming Frog crawl to identify any remaining redirect chains, broken internal links, or duplicate content issues.

Months 2–3: Stabilization Assessment

  • Traffic recovery target: Organic traffic should return to pre-migration levels within 2–3 months. If it has not recovered after 3 months, structured investigation is needed.
  • Ranking recovery: Most rankings recover within 4–8 weeks. Pages that have not recovered after 3 months likely have a specific issue — check their redirect chain, content quality, and backlink health.
  • Structured data validation: Verify rich snippets are appearing in search results. Use the Rich Results Test to check key pages.
  • Redirect cleanup: After 6 months, audit your redirect list. Redirects pointing to other redirects should be updated to point directly to the final destination.

Common Migration Mistakes

1. Redirecting Everything to the Homepage

The lazy redirect — mapping every old URL to the homepage — is one of the most damaging things you can do to your SEO. Google treats a redirect to the homepage from an unrelated old URL as a soft 404, effectively telling Google the content no longer exists. Page-level ranking power is diluted into a single URL that already ranks for its own keywords. Do the work of mapping each page to its most relevant equivalent, even if that equivalent does not exist yet and needs to be created.

2. Forgetting About Internal Links

After migration, internal links on the new site may still point to old URLs — creating redirect chains that slow page loads and leak link equity. Update all internal links to point directly to new URLs, not through redirects. A post-migration crawl with Screaming Frog will identify all internal redirect chains.

3. Leaving Staging robots.txt in Production

The most common and devastating migration mistake. A staging site typically has Disallow: / in its robots.txt to prevent Google from indexing incomplete work. If this file is not replaced with the production robots.txt when the site goes live, Google stops crawling the entire site. Rankings begin disappearing within days. Always verify the robots.txt explicitly on launch day — it is worth a dedicated line in your launch checklist.

4. Not Testing on Real Devices

The new site looks perfect on your MacBook with a 24-inch monitor. Have you tested on a mid-range Android phone? On an older iPhone? On a 4G connection rather than fiber? Real-device testing catches issues that browser developer tools and emulators miss. In Europe, where a significant portion of web traffic comes from mobile devices on variable connections, mobile testing is not optional.

5. Changing URLs and Content Simultaneously

When you change both the URL structure and the content during a migration, Google has difficulty determining whether the new page is a replacement for the old one or entirely new content with different ranking signals. Where possible, change one variable at a time — keep the content the same while changing the URL (redirect handles the SEO continuity), then update the content in a subsequent phase.

6. Incomplete Multilingual Redirect Mapping

For multilingual sites, every URL change multiplies by the number of languages. A 100-page site in 4 languages means 400 redirect rules to create, test, and verify. Hreflang tags must be updated to reflect the new URL structure. Missing even a few redirects in one language creates invisible traffic losses that are difficult to diagnose. Build language-specific redirect verification into your testing process.

7. Dropping Structured Data

If your old site had JSON-LD schemas — Organization, WebSite, BreadcrumbList, FAQPage, LocalBusiness, Product — ensure they are replicated correctly on the new site. Losing structured data means losing rich snippets in search results, which can reduce click-through rates by 10–30% for affected pages.

8. Inadequate Redirect Testing Before Launch

Creating redirect rules is not the same as verifying they work. Many redirect implementations have edge cases — trailing slash differences, HTTP vs HTTPS, www vs non-www — that only appear when you test with actual HTTP requests. Build automated redirect testing into your pre-launch process, not just manual spot-checking.

European-Specific Migration Considerations

GDPR and Analytics

Website migrations often involve changing analytics implementations. Ensure your new analytics setup maintains GDPR compliance — cookie consent must fire before any tracking scripts, data processing agreements must be updated if you are changing providers, and IP anonymization must be configured correctly. A migration is a natural opportunity to audit and improve your GDPR compliance posture.

Multilingual Hreflang Updates

If your migration changes any URL structures, every hreflang tag across all language versions must be updated to reflect the new URLs. An automated hreflang generator that reads from your URL mapping spreadsheet can eliminate manual errors in this update. After migration, use a hreflang checker tool to verify the implementation across a representative sample of pages in each language.

Local Business Schema

For European businesses with physical locations, ensure LocalBusiness structured data is correctly implemented on the new site with accurate NAP (Name, Address, Phone) information. Any changes to the business address or phone number during or around a migration will create NAP inconsistency that harms local search rankings.

When to Consider Professional Help

DIY migration is feasible for small sites — under 50 pages, no significant organic traffic, single language, no domain change. Consider engaging a professional when:

  • Your site has more than 200 pages requiring URL mapping
  • You are changing domains — the risk and complexity increase significantly
  • You have significant organic traffic (1,000+ sessions per month) that you cannot afford to lose
  • Your site is multilingual with hreflang implementation requiring updates across all language versions
  • You have an e-commerce site with thousands of product, category, and filter URLs
  • You are migrating from a legacy platform to a modern stack where the CMS data formats differ significantly
  • Your site has significant link equity concentrated in a few key pages that must be preserved

The cost of professional migration management is almost always less than the cost of recovering from a poorly-executed migration — both in direct revenue from lost traffic and in the 3–6 months it can take to rebuild rankings that were unnecessarily lost.

We have handled dozens of website migrations across European markets — from simple platform switches to complex multilingual domain consolidations — preserving organic traffic throughout the process. Our clients typically see traffic return to pre-migration levels within 4–8 weeks, well within the normal recovery window. Contact us to discuss your migration project and ensure your years of SEO investment are protected.

migrationseoredirectstechnical
Musa Kerem DemirciFounder & Lead Developer

Full-stack developer serving European businesses with premium web solutions. React, Next.js, and TypeScript specialist with 33+ international projects delivered.

LinkedIn

Ready to start your project?

Let's discuss how we can help your business grow with a premium web presence.

Get in touch