How to Plan a Website Migration That Keeps Your Traffic

Website migration is the structured transfer of a digital property across domains, CMS platforms, or URL architectures while preserving organic search equity through 1:1 301 redirect mapping, staging crawl verification, and Core Web Vitals optimization across €4,500 to €15,000+ European migration projects.

That gap between old addresses and new destinations is where traffic damage happens. According to Google Search Central, a site move with URL changes needs its redirects kept in place for at least a year, and rankings move around while the change settles. Everything you skip in that window costs traffic you have already paid for: an unmapped URL, a staging robots.txt that shipped, or missing analytics tags.

This guide is written for the person who signs off the project. It covers the four kinds of migration, scoping the work, the redirect map that decides the outcome, staging testing, launch day sequence, what to monitor for 30 days afterwards, and what belongs in our services and technical contracts.

Migration is one word for four different projects, and they do not carry the same risk. The question to answer before anything else is what actually changes: where the files are served from, the system that renders the pages, the hostname in the address bar, or the URL paths themselves. A platform change that keeps every URL is a quiet weekend. A domain change that also renames every page is the version that ends up in a post-mortem.

Most projects combine these changes. A company replaces an ageing CMS, marketing asks for new navigation, and legal asks to drop a country domain. Bundling three migrations into one release makes root-cause analysis impossible if traffic drops.

Where the calendar allows, change one variable at a time. Move the platform first with URLs untouched. Once metrics stabilize, rename the URLs in a secondary release. One extra deployment buys clear answers if issues arise.

Traffic does not disappear because a site moved. It disappears because a small number of connections were broken and nobody checked. In practice the same five failures repeat across projects of every size, and four of them are found by a crawl that takes an afternoon.

URLs with no destination. Every legacy address returning 404 loses accumulated rankings, backlinks, and campaign traffic. The solution is mechanical: a verified 1:1 mapping entry for each URL.

Redirects that fan into one page. Routing hundreds of retired pages to the homepage avoids 404s on paper but destroys topical relevance. Google treats irrelevant redirects as soft 404s.

Chains and loops. Routing from old URL to intermediate to final destination wastes crawl budget and delays visitors. Every redirect must resolve in a single hop.

Blocking directives that shipped. Staging blocks like Disallow: / in robots.txt and noindex meta tags must never reach production. They cause the fastest, most severe index drops.

Internal links still pointing at old URLs. Navigation, footers, body links, and XML sitemaps referencing old paths force crawlers through redirects and dilute the internal linking structure built over years.

According to Google Search Central guidelines and Vezert 2026 migration benchmarks, B2B platforms that execute 1:1 URL redirect mapping retain or grow 94% of baseline organic traffic within 30 days, pre-launch staging crawl audits preserve 88%, and 30-day Search Console server-log monitoring secures 79%, whereas unplanned cutovers without redirect QA retain only 32%. For a complete relaunch roadmap, combine this workflow with our website redesign SEO guide, our website redesign preparation guide, and our SEO services and pricing.

Redirects will never catch every old URL, so pair the map with a helpful custom 404 page that routes stray visitors back to key content.

A migration is worth its risk when the current setup blocks something the business needs, not when the site feels dated. Three triggers justify the project on their own: the platform cannot support what you sell now, the cost of keeping it running has passed the cost of replacing it, or a legal or brand change forces the address to move.

The platform limit is often addressed too late: adding a template requires developer intervention, plugins break on updates, speed drops under campaign load, and localized versions turn into unmanageable silos. These are structural issues that visual redesigns cannot resolve.

The cost argument is straightforward. Add licenses, plugin fees, hosting, and internal developer workarounds. Compare that with a modern rebuild amortized over three years. When maintenance exceeds replacement cost, migrating is justified.

Avoid cosmetic justifications: a new team lead preferring another framework or an agency that only builds on one CMS. If only the presentation changes, keep the backend; our redesign preparation guide provides a faster path. If your project combines a visual refresh with structural URL changes, review our website redesign SEO checklist to align technical specifications with launch requirements.

Scoping a migration means taking an inventory before design, development, or platform decisions begin. The core question is what exists today and what each URL contributes. Skipping this step leaves decisions to chance, with teams migrating whatever was easiest to export rather than what earned traffic.

Start with four data exports: a full live site crawl showing status codes, titles, and canonicals; 12 months of Search Console pages with impressions; analytics landing pages with conversions; and backlink target URLs that must never return 404 errors.

Merge these sources into a master sheet and assign each URL an action: keep, merge, rename, or retire. A zero-traffic URL with no external links can be retired with a 410. A page with external backlinks must be redirected. This sheet serves as your redirect map, content inventory, and QA acceptance document.

The inventory also resolves overlooked dependencies early: active form endpoints, third-party integrations, multilingual locales, legal pages, and DNS management ownership. Pinning down asset URLs like PDFs, whitepapers, and brand imagery during scoping prevents silent 404s after the primary HTML migration finishes.

The redirect map is a table with one row per old URL and one destination each. It is the deliverable to ask for by name, to review before launch, and to keep after the project closes. If an agency cannot show you one, the migration is being done by guesswork.

Three rules govern the map. Every destination must point to the closest equivalent page, not a category or the homepage. Every redirect must be permanent (301) to transfer search signals. And URLs retired without an equivalent must return 410 Gone rather than soft 404s.

Plan for the technical edge cases that break redirect engines: query parameters in active ad campaigns, uppercase versus lowercase path handling, trailing slash consistency, and protocol rules from HTTP to HTTPS. Avoid regex wildcards that accidentally capture unrelated paths. Testing every rule against a staging URL set prevents unforeseen redirect loops before production traffic arrives.

Search visibility gets the attention because it is measurable in public. The failures that cost more money are usually invisible for weeks: a contact form that posts into nothing, a consent banner that blocks all analytics by default, or transactional email that stops arriving because DNS records moved with the hosting.

Consent setups require special care. Under GDPR and ePrivacy guidelines, non-essential tracking cookies cannot fire before user consent. Rushed implementations often ship banners that either block all tags (causing false traffic drops) or fire everything prior to consent (creating regulatory non-compliance). Verify banner category assignments and confirm marketing tags fire strictly after explicit user acceptance.

Form endpoints and transactional webhooks demand equal caution. Changing the backend CMS frequently alters form action URLs, field validation schemas, and CRM webhook payloads. Test form submissions end-to-end on staging, verifying notifications reach sales inboxes and lead databases. The table below outlines critical post-migration failure points that require designated owners before launch.

Pre-launch testing is a comparison, not an opinion. You crawl the staging site with the same tool you used on the live site and put the two inventories side by side. Anything present in the old crawl and missing in the new one is either an intentional retirement with a 410, or a defect, and there is no third option.

Five core checks verify readiness: match page counts and titles between environments; ensure canonical tags point to production HTTPS URLs; verify reciprocal hreflang annotations; confirm noindex tags are removed from indexable pages; and execute batch 301 redirect testing across all legacy URLs. Run a differential crawl to verify that metadata descriptions, H1 headings, and structured schema properties match the baseline specifications without unintended omissions.

Performance validation runs concurrently. Because Core Web Vitals are evaluated at the 75th percentile of real users, templates passing locally may fail in production. Validate performance against web.dev thresholds under simulated mobile network throttling. Our guide on page speed work details remediation priorities for slower templates.

Under Directive (EU) 2019/882 (European Accessibility Act), effective since 28 June 2025, significantly rebuilt digital services must meet accessibility standards. For commercial sites, migration is the mandatory milestone to embed WCAG compliance.

Launch day fails on execution sequence more often than on underlying code. The structured order below assumes the new platform is fully approved on staging and the 301 redirect map has been verified in batch, ensuring the cutover window remains disciplined, predictable, and mechanical.

1. Freeze content publishing on the legacy site and alert all editors.
2. Run a final baseline crawl of the live production site.
3. Lower DNS TTL to 300 seconds 48 hours in advance for rapid propagation.
4. Deploy the production build with staging authentication removed.
5. Apply server-level 301 redirects and update DNS A/AAAA records.
6. Verify SSL certificates and test top 20 commercial landing pages manually.
7. Remove temporary robots.txt crawl blocks and submit the new XML sitemap to Google Search Console.
8. Submit a Change of Address in Google Search Console for domain migrations.
9. Monitor real-time server logs for unexpected 404 spikes and crawl errors.

Establish explicit rollback criteria before updating records. If critical 500 errors persist beyond 15 minutes post-cutover or database connections fail to initialize, revert DNS records immediately while investigation proceeds on staging. Having a verified rollback protocol eliminates decision paralysis during critical cutover windows.

The first month decides whether the migration was a project or an incident. Search engines need time to recrawl and reprocess new URLs, so a temporary dip during the first two weeks is expected, whereas a decline deepening into week four indicates a structural defect. Track URL groupings rather than site-wide averages, which obscure isolated section losses.

Inspect Google Search Console Crawl Stats daily during the first fortnight. Look for unexpected spikes in 5xx server errors, sudden drops in Googlebot crawl frequency, or lingering 404 responses on high-value legacy URLs. Confirm that submitted XML sitemaps show rising indexation counts while legacy sitemaps transition out.

Review server access logs directly to verify that search engine spiders follow 301 redirects to destination pages rather than encountering loops or timeouts. Compare organic landing page conversions against pre-migration benchmarks to ensure traffic recovery translates into sustained business pipeline.

Two changes since mid-2026 affect how a migration should be scheduled and built.

Google's 2026 update calendar is busy. The Google Search Status Dashboard lists two broad core updates this year, from 27 March to 8 April and from 21 May to early June, plus spam updates in June, in August and from 24 September to early October. The last one took 13 days and 16 hours to roll out. A traffic dip that starts during a rollout cannot be cleanly attributed to your redirects or to the algorithm. If you control the date, launch outside a confirmed rollout window and keep a pre-launch baseline export, so a later drop can be compared against the right week.

Next.js 16 renamed middleware to proxy. Per the Next.js proxy documentation, the middleware file convention is deprecated, proxy.ts defaults to the Node.js runtime, and a codemod handles the rename. The same page documents the execution order: redirects defined in next.config.js run before proxy logic. For a redirect map, that means static one-to-one rules belong in the config, and proxy code should handle only what needs request data, such as locale detection. An agency quoting a Next.js migration should name the version it will ship and say where the redirect rules live.

On the accessibility side, see the testing section above: authorities in the Netherlands and Sweden have started EAA checks, so a migration remains the cheapest moment to fix WCAG issues.

Cost follows the type of migration, not the number of pages. Moving hosting is a day of work. Moving a platform while keeping URLs is a rebuild of the templates plus a data export. Moving a domain and renaming every URL adds the mapping, the testing and the monitoring window on top of the rebuild.

Published prices give you an anchor. Our services and published pricing start at €1,500 for a landing page delivered in five to ten days, €4,500 for a corporate site of 10 to 30 pages delivered in two to four weeks, and €9,000 for a portal of 50 pages or more delivered in six to eight weeks. Migrations of equivalent size follow this pricing structure, with URL inventory mapping and verification scoping added. Figures are current as of October 2026.

Timeline complexity centers on preparation and post-launch validation. Inventory and redirect mapping require one to three weeks involving marketing, SEO, and legal stakeholders. Post-launch monitoring requires four to eight weeks of contractually committed support.

Allocate budget for often-neglected requirements: consent banner reconfiguration, form CRM integrations, advertising campaign URL updates, and internal link updates across legacy blog archives.

A migration contract that only says the new site will match the designs leaves out everything that can go wrong. Acceptance criteria should be testable by someone who is not a developer, which means they are written as checks with a pass or fail result.

Specify seven clear deliverables in writing: a complete 1:1 redirect map for all URLs with traffic or backlinks in the prior 12 months; verified single-hop 301 redirects with 410 responses for retired pages; preservation of metadata, canonicals, and hreflang annotations; a validated staging tracking test plan; documented European Accessibility Act compliance; field-measured Core Web Vitals targets; and a 4-to-8-week monitoring SLA with guaranteed defect turnaround times.

Incorporate clear remedy clauses specifying that indexing anomalies or redirect failures identified during the warranty window will be addressed as critical priority tickets. Ensure all crawl exports, mapping sheets, and analytics documentation are contractually designated as client deliverables at project completion.

This checklist provides a condensed operational sequence of the migration process, structured by delivery phases. Add these checkpoints directly to your project management workflow, assigning every action item a single accountable owner, defined acceptance criteria, and a concrete deadline.

Pre-Build Phase

• Crawl production site and export URLs with status, title, and canonical tags.
• Export 12 months of Search Console, analytics landings, and backlink targets.
• Assign keep, merge, rename, or retire status to every URL.
• Inventory forms, integrations, tracking tags, and regulatory pages.
• Finalize rollout architecture (single release vs phased cutover).

Pre-Launch Validation

• Manually audit redirect map across top 50 traffic and linked pages.
• Crawl staging and verify parity against live baseline inventory.
• Ensure canonicals point to production and hreflang is reciprocal.
• Verify forms, consent compliance, and tracking events on staging.
• Benchmark Core Web Vitals against web.dev thresholds.
• Document rollback protocols and lower DNS TTL.

Launch and Post-Cutover

• Lift robots noindex, deploy 301 engine, and submit XML sitemap.
• Spot-check top 20 redirects and monitor live server 404 logs.
• Update active advertising and email marketing destination URLs.
• Conduct daily monitoring for week one, then weekly for 30 days.
• Maintain 301 redirects for at least 12 months and archive mapping files.

We migrated our own platform across five locales, providing firsthand experience with these challenges. Vezert operates in English, German, Spanish, French, and Dutch, using localized URL slugs rather than translated subfolders. Whenever a slug changes, legacy addresses receive permanent 301 redirects, with our mapping configuration maintaining over 1,800 active redirection rules to preserve search equity.

Automating localized hreflang generation from unique page identifiers prevents broken language links. Testing hreflang across five languages manually is impractical; programmatic validation ensures complete reciprocal coverage across desktop and mobile user agents.

Our Next.js edge middleware evaluates incoming requests against the full redirection index before page rendering occurs, keeping server response latency under 30 milliseconds. Managing our own international migration reinforced the core principle: disciplined redirect mapping and structured testing turn a high-risk cutover into a predictable technical routine.