Website Migration Guide: How to Move Your Site Without Losing SEO

A website migration is one of the most technically delicate SEO operations you can undertake. One misconfigured redirect, one forgotten URL, one overlooked hardcoded path, and you can watch months or years of SEO progress evaporate in days. Traffic drops of 50–80% are common after botched migrations, and recovering from a bad migration takes far longer than executing a good one. The stakes are high because search engines have built trust in your existing URLs. Every backlink, every indexed page, every ranking signal is tied to a specific URL structure. When you change that structure without properly telling Google where the content moved, you sever those connections. This guide gives you a battle-tested, step-by-step process for migrating a website while preserving every ounce of SEO equity you have built. Whether you are switching domains, moving from WordPress to Next.js, changing hosts, or redesigning your entire site, the principles here will protect your rankings, your traffic, and your revenue.

Why Website Migrations Are High-Risk

Before we dive into the how, let us be clear on the why. A website migration is risky for three interconnected reasons. Rankings can vanish because search engines rely on consistent URL structures. When you change URLs, every backlink pointing to the old URL becomes a dead end unless a redirect is in place. Search engines must rediscover and re-evaluate your content at the new URLs, and during that transition period, rankings are volatile. Traffic drops are the direct consequence. Even well-planned migrations often see a temporary dip because search engines need time to recrawl and reindex the new URLs. Poor migrations see permanent traffic losses because redirects were wrong, broken, or missing entirely. Revenue takes a direct hit when traffic drops. For ecommerce sites, a 50% traffic drop during a slow migration period can mean tens of thousands of dollars in lost sales. The cost of downtime, lost conversions, and damaged brand reputation often exceeds the migration cost itself. This is why a careful, methodical approach is not optional — it is essential. If the idea of managing this alone feels overwhelming, my Website Migration service handles every phase of the process, from URL mapping through post-launch monitoring.

Types of Website Migrations

Not all migrations are the same. The specific type of migration you are undertaking determines what you need to prioritize and where the risks are highest.

Domain Change

Moving from one domain to another (e.g., oldcompany.com to newcompany.com). This is the highest-risk migration because every single URL changes, every backlink must be redirected, and search engines treat the new domain as an entirely new entity until they learn otherwise. Domain changes require the most extensive URL mapping and the longest monitoring period.

Platform Change

Migrating from one CMS or framework to another (e.g., WordPress to Next.js, Shopify to custom, Joomla to WordPress). URL structures may change, and the underlying technology stack is different. Performance almost always improves, but the migration risk comes from URL changes, template differences, and content mapping issues.

Host Change

Moving from one hosting provider to another while keeping the same domain and platform. The lowest-risk migration type because URLs usually stay the same, but DNS propagation, IP address changes, and server configuration differences can still cause temporary issues. Properly handled host changes rarely cause SEO problems, but mishandled ones can lead to days of downtime.

Redesign Without Platform Change

Updating your site's design while staying on the same platform. Risk is moderate because while URLs may stay the same, layout changes can affect user engagement metrics, page speed, and mobile usability — all indirect ranking factors. New JavaScript-heavy designs often hurt Core Web Vitals if not optimized.

Protocol Change (HTTP to HTTPS)

Moving from HTTP to HTTPS was a major SEO event for many years. These days, search engines handle this migration well if you implement 301 redirects properly and update your hardcoded references. The key risks are mixed content warnings (loading HTTP assets on HTTPS pages) and forgetting to update canonical URLs.

Pre-Migration Planning

The single biggest determinant of migration success is the quality of your planning. Execution takes days. Recovery from mistakes can take months. Spend as much time as you need on these four planning steps before you change a single line of production code.

Full Site Audit

Before you move anything, know exactly what you have. Crawl your entire site using a tool like Screaming Frog, Sitebulb, or Ahrefs. Export every URL on your site — all pages, posts, images, PDFs, JavaScript files, CSS files. Document the current status of each URL (200 OK, 301 redirect, 404, etc.). Identify your highest-traffic and highest-ranking pages first, because those matter most to protect. Also check for broken internal links, missing alt text, duplicate content, and thin pages. A migration is the perfect time to fix these issues — but fix them on the old site before migrating, or document them to address on the new site.

URL Mapping

Create a complete URL mapping spreadsheet with three columns: old URL, new URL, and redirect type. Every single URL from your audit must have a corresponding entry. For most pages, the mapping is direct (e.g., /about to /about). For restructured sites, you need to determine the best new location for each piece of content. Where pages are merged or split, redirect old URLs to the most relevant new URL. For deleted content, redirect to the nearest relevant category or parent page — never to the homepage unless there is absolutely no better option. This spreadsheet becomes the source of truth for your redirect implementation. When I handle a professional website migration, the URL mapping document is the single most scrutinized deliverable before launch.

Benchmarking Current Rankings and Traffic

You cannot know if your migration succeeded or failed without a baseline. Record your current rankings for your top 50 target keywords. Export your Google Search Console data for the last 3–6 months: impressions, clicks, average position, and click-through rate. Record your Google Analytics traffic numbers by channel (organic, direct, referral, social, paid). Note your Core Web Vitals scores (LCP, FID/INP, CLS). Capture your current backlink profile from Ahrefs or Majestic — total referring domains, total backlinks, top linking pages. Take screenshots of Search Console performance reports. Store all of this in a migration dashboard or document where you can reference it during and after the migration.

Rollback Plan

Every migration plan must include a rollback scenario. What triggers a rollback? Define specific criteria: if organic traffic drops more than 40% within 48 hours, if the site is returning 500 errors for more than 2 hours, if critical pages fail to resolve, if revenue drops below a defined threshold. Document exactly how to reverse the migration: restore DNS to the old hosting, swap back to the old database, re-enable the old server configuration. Test your rollback procedure before launch day — a rollback plan that has never been tested is not a plan, it is wishful thinking. Keep the old infrastructure running for at least 30 days after migration so that a rollback is possible without restoring from backups.

Step-by-Step Migration Process

With your planning complete, here is the execution sequence. Follow these steps in order. Skipping steps or changing the order introduces unnecessary risk.

Set Up Staging Environment

Build the new site on a staging server that mirrors your production environment. Use a staging URL like staging.yourdomain.com or a subfolder with IP restrictions. Block search engines from indexing the staging site using a X-Robots-Tag: noindex header or a <meta name="robots" content="noindex"> tag on every page. Verify the staging site is not indexed by searching site:staging.yourdomain.com in Google before you proceed. Import a copy of your production content, test every page template, verify that all forms work, check that analytics tracking codes are firing, and confirm that page speed meets your targets. The staging environment exists to catch problems before they affect your live site. If you need help building the new platform, I offer custom web development to create high-performance Next.js or React-based sites ready for migration.

Implement 301 Redirects

This is the single most important technical step in the entire migration. Every URL on your old site must redirect to the corresponding URL on your new site using a 301 (permanent) redirect. Implementation depends on your stack. Apache: Use .htaccess with RewriteRule directives. Nginx: Use rewrite or return 301 in server blocks. Next.js: Use next.config.js with the redirects() function, which is the cleanest approach. WordPress: Use a plugin like Redirection or Yoast Premium, or add rules to .htaccess. Cloudflare: Use Bulk Redirects or Page Rules. The key principles are: redirect old URLs to the closest matching new URL, never redirect everything to the homepage, use regular expressions for pattern-based redirects where appropriate (e.g., /blog/* to /blog/*), implement redirects at the server level (not JavaScript), and test every single redirect before going live. Create a test spreadsheet, crawl your staging site with the redirects in place, and verify that each old URL resolves to the correct new URL with a 301 status code. A single incorrect redirect can cascade into redirect chains that confuse search engines and waste crawl budget.

Update Internal Links

Your internal links are the connective tissue of your site. Every link on every page that points to an old URL must be updated to the new URL. Search your entire codebase or content database for hardcoded references to old URLs. In a CMS, this means updating content in the database. In a static site, this means updating every template and markdown file. Use search-and-replace carefully — a global replace without verification can break links that were intentionally pointing to external resources that happen to match the pattern. After updating, crawl your new site with a tool that checks for broken internal links. Zero broken internal links should be your standard.

Submit New Sitemap

Generate a new XML sitemap that contains only the new URLs. Upload it to your new server at the standard location (/sitemap.xml). Submit it to Google Search Console under the new property (or the same property if the domain has not changed). Also submit it to Bing Webmaster Tools. Delete any old sitemaps that reference old URLs. The sitemap helps search engines discover your new URL structure quickly, which accelerates reindexing. Include only canonical URLs (no paginated parameters, no filter pages, no staging URLs). Keep your sitemap under 50,000 URLs and 50MB uncompressed, or break it into a sitemap index.

Update robots.txt and Canonical URLs

Your robots.txt file must reference the new sitemap location and allow access to critical sections of your new site. Do not accidentally block your new site from crawling. Check for old disallow rules that may have been copied from your old site without updating. Canonical URLs are equally critical: every page on your new site must include a self-referencing canonical tag pointing to its new URL. Do not leave old canonical URLs that reference the old domain or old URL structure. Search engines treat the canonical URL as the authoritative version of a page, and conflicting canonicals confuse indexing completely. Verify canonical tags across your entire site after launch using a crawler.

Technical SEO Preservation

Beyond the core migration steps, several technical gotchas can silently undermine your SEO preservation efforts. Address these methodically.

Redirect Chains

A redirect chain occurs when URL A redirects to URL B, which redirects to URL C, which finally resolves to URL D. Search engines follow redirects but they do not like chains. Google has stated that it may stop following redirects beyond a certain number of hops (typically 3–5). Redirect chains waste crawl budget, slow down page load times (each redirect is an additional HTTP round trip), and dilute PageRank distribution. Before launch, trace every redirect path in your mapping to ensure each old URL goes directly to its final destination URL in a single redirect. Use tools like Screaming Frog or Redirect Path (Chrome extension) to identify and eliminate chains. If you find chains, update the first redirect to point directly to the final URL.

Redirect Loops

A redirect loop occurs when URL A redirects to URL B, and URL B redirects back to URL A, causing an infinite loop that eventually returns a 500 Internal Server Error. A redirect loop effectively makes a page inaccessible and guarantees an SEO failure for every URL caught in the loop. The most common cause is a conflict between server-level redirects and application-level redirects. For example, a Next.js redirect in next.config.js that conflicts with an .htaccess rule. To prevent loops, consolidate all redirects in a single place. Test your most complex redirect patterns in isolation before deploying them together. After deployment, crawl your entire site and check for 500 errors — every 500 error must be investigated immediately.

Handling Query Parameters

Query parameters in URLs (?utm_source=google&utm_campaign=spring) require special attention. If your old site used query parameters for tracking or filtering, those parameters may or may not need to carry forward. In most cases, you should strip tracking parameters from the canonical URL but preserve them in the redirect — the redirect must pass through query parameters to the new URL. Configure your server or redirect logic to preserve and pass query parameters by default. In Next.js, the redirects() function in next.config.js handles this correctly when you use has conditions. For search parameters that change page content (like ?page=2 or ?category=shoes), you need explicit redirect rules for each meaningful parameter combination. In Google Search Console, use the URL Parameters tool to tell Google how to handle your parameters (though this tool is increasingly deprecated in favor of proper canonical URLs and noindex on parameter-generated pages).

Post-Migration Monitoring

The migration is not over when the new site goes live. The most critical phase is the 30–60 days after launch, during which you must monitor aggressively and respond to issues immediately.

Google Search Console Monitoring

Check Search Console daily for the first two weeks after migration. Watch for: a spike in 404 errors (indicates missing redirects), a sudden drop in indexed pages (signals a crawling or canonicalization problem), an increase in manual actions (Google may penalize redirect abuse if done poorly), and changes in performance graphs. Verify the new domain property has been added to Search Console. Use the URL Inspection tool to test specific URLs and confirm they are indexable. Monitor the Coverage report for excluded pages and errors. If you keep your old Search Console property active, you will see impression data redirecting through the old URLs.

Traffic and Rankings Tracking

Compare current traffic against your pre-migration benchmarks daily. Use Google Analytics to monitor organic traffic specifically — if organic traffic drops more than 20% and does not rebound within 48 hours, investigate immediately. Use a rank-tracking tool (Ahrefs, SEMrush, AccuRanker) to check your top 50 keyword positions daily. Expect some volatility in the first 1–2 weeks as search engines recrawl and reindex. The pattern we look for is: initial dip, stabilization, gradual recovery, and eventual improvement. If rankings drop and stay down past 3 weeks, there is an underlying technical issue that needs diagnosis.

Crawl Error Checking

Run a full site crawl using Screaming Frog or Sitebulb every week for the first month after migration. Focus specifically on: 404 errors (pages that should exist but are missing), 500 errors (server-side problems), redirect chains (more than one hop), broken external links (especially if you changed domains), and orphan pages (unlinked content that search engines may not discover). Each error category tells you something different about your migration quality and requires a specific fix.

404 Monitoring

404 errors after migration are normal — search engines will try old URLs that are not yet in your redirect map. The key is to catch and fix them quickly. Set up a custom 404 page that includes a search box and helpful navigation (do not let users hit a dead end). Monitor your server logs or use a tool like Ahrefs to find 404s that search engines are hitting. Add redirects for any old URL returning a 404. The goal is zero 404s on the URLs that matter within the first week. After 30 days, a persistent 404 usually indicates an oversight in your URL mapping that needs permanent correction.

Common Migration Mistakes (And How to Avoid Them)

I have seen these mistakes repeatedly in migrations I have audited and fixed. Learn from others' expensive lessons.

Not Updating All Internal Links

This is the most common migration mistake. You update the navigation and the footer, but older content, blog posts, and landing pages still link to old URLs. The result: broken internal links that waste crawl budget, hurt user experience, and dilute PageRank. Fix: do a comprehensive find-and-replace across your entire content database or codebase. Use a crawler after deployment to verify zero broken internal links. A crawl that reports zero broken links on day one is the only acceptable standard.

Forgetting Hardcoded URLs

Hardcoded URLs hide in unexpected places: JavaScript redirects, API endpoint references, image source paths, CSS url() references, email templates, third-party integration configurations, and environment variable files. A hardcoded URL pointing to the old domain or old path will not be caught by a standard crawl — it only breaks at runtime when a user or search engine follows it. Fix: search your entire codebase for the old domain and old URL patterns. Do not assume grep will find everything; also check database serialized data, JSON blobs, and minified assets.

Neglecting Image Paths

Images are often the largest volume of assets on a website, yet they are the most commonly overlooked aspect of migration. Old image URLs lead to broken images, which hurt user experience and increase bounce rates. Search engines also index images, and broken image links waste crawl budget. Fix: map all old image paths to new image paths in your URL mapping document. Use a CDN for images if possible — a good CDN can serve images regardless of path changes. Verify image paths after launch by running a visual regression check or crawling for broken image src attributes.

Incorrect 301 Redirect Implementation

Using 302 (temporary) instead of 301 (permanent) redirects, implementing redirects via JavaScript or meta refresh instead of server-level HTTP redirects, and misconfigured regex patterns that capture too many or too few URLs are all common redirect mistakes. Each error type has a different impact. Fix: test every redirect pattern in isolation before deployment. Use a browser extension like Redirect Path to verify the response code. Crawl your entire redirect mapping to confirm all old URLs return 301, not 302, not 200 with a JavaScript redirect.

Not Updating External References

You control your site, but you cannot control who links to you. That said, you should update external references you do control: Google Business Profile, social media profiles, directory listings, email signatures, ads (Google Ads, Facebook Ads), your CRM, email marketing platform links, and any PR or press release URLs. Fix: create a checklist of every external platform where your old URL appears. Update them at the same time as your site migration or immediately after. For platforms you cannot update, ensure 301 redirects from the old URL to the new one stay in place permanently.

Platform-Specific Migration Guides

Different platforms have different migration considerations. Here are two common scenarios with specific guidance.

Migrating from WordPress to Next.js

This is one of the most common migrations I perform because it delivers significant performance improvements. WordPress sites running on shared hosting often have load times of 3–6 seconds. Moving to Next.js on a modern edge platform can bring those times under 200ms. The migration process: export your WordPress content via the WordPress REST API (or use WPGraphQL if you prefer GraphQL), map your WordPress URL structure to Next.js routes (pay attention to custom post types and taxonomies), implement redirects in next.config.js using the redirects() function (which generates server-level 301s, not JavaScript redirects), export .htaccess rules from your old WordPress site and convert them to Next.js redirect patterns, migrate images to a CDN and update all src attributes in your MDX or CMS content, preserve all slug structures where possible, and test every route against the old WordPress URL structure. For a detailed comparison of these platforms, read my Next.js vs WordPress comparison. If you need professional help with this specific migration, my website migration service covers WordPress-to-Next.js transitions with guaranteed SEO preservation.

Migrating from an Old Host to a New Host

Host-to-host migrations are lower risk but still require care. The process: set up the new server with identical or better specs, transfer all files and databases, update configuration files (database connection strings, API keys, environment variables), test the site on the new host using a local hosts file or staging URL (do not change DNS yet), update DNS records to point to the new host's IP address (lower the TTL to 300 seconds 24–48 hours before the switch for faster propagation), wait for DNS propagation (4–48 hours typically — use whatsmydns.net to check), keep the old server running for at least 30 days, and monitor server logs on both hosts. The biggest risk in host migration is DNS propagation delays causing some users to see the old site while others see the new one. This is normal and resolves as DNS propagates fully. Zero downtime during a properly executed host migration is achievable.

Frequently Asked Questions

Summary and Next Steps

A successful website migration comes down to methodical planning, meticulous execution, and aggressive post-launch monitoring. The three most important things to remember: map every URL and implement 301 redirects from every old URL to its corresponding new URL, test everything on staging before going live (redirects, internal links, forms, analytics, images), and monitor relentlessly for at least 30 days after launch, ready to fix issues immediately. The risk of migration is real, but the reward is worthwhile: better performance, a modern tech stack, improved user experience, and often better SEO outcomes in the long run.

Here is what to do next:

1. Create your URL mapping spreadsheet. Crawl your existing site and document every URL. This is the foundation of a successful migration.
2. Set up your staging environment. Build the new site, implement redirects, and test everything before touching production.
3. Choose your execution window. Migrate during a low-traffic period (typically late night or weekend) to minimize user impact.
4. Launch and monitor. Go live, verify redirects immediately, and check Search Console and Analytics daily for the first two weeks.
5. Need help? I offer end-to-end website migration services that handle everything from planning and URL mapping to redirect implementation and post-launch monitoring. I also build high-performance custom websites for businesses ready to leave outdated platforms behind. For ongoing maintenance after migration, read my website maintenance guide. Contact me to discuss your project or request a quote for a custom migration plan.