How to Plan a Website Migration That Keeps Your Traffic

A website migration is any project that moves a site to a new address, a new platform or a new structure: a CMS change, a domain change, a move from HTTP to HTTPS, or a rebuild that renames every URL. The pages survive the move. The addresses that Google, other websites and your own email campaigns point at often do not.

That gap is where the 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: one unmapped URL, one staging robots.txt that shipped, one analytics tag that never made it onto the new templates.

This guide is written for the person who signs off the project, not the person who runs the deployment. It covers the four kinds of migration and the risk each carries, how to scope the work, the redirect map that decides the outcome, what to test before launch, the order of operations on launch day, what to watch for 30 days afterwards, and what belongs in the contract.

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 real projects are a combination. A company decides to replace an ageing CMS, and while the budget is open, marketing asks for a new navigation, and the legal team asks to drop the country domain. Three migrations get bundled into one launch, and when traffic falls nobody can say which of the three caused it.

If you take one decision from this guide, take this one: change one variable at a time where the calendar allows it. Move the platform first with URLs untouched, confirm the numbers held, then rename the URLs in a second release. It costs one extra deployment. It buys you an answer when something goes wrong.

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 old address that returns 404 loses whatever ranking, links and campaign traffic it had. The fix is boring: one line per old URL in a mapping file, reviewed by a human.

Redirects that fan into one page. A bulk rule that sends 400 retired product pages to the homepage technically avoids 404s and destroys relevance at the same time. Google treats a redirect to an irrelevant page much like a soft 404.

Chains and loops. Old URL to intermediate URL to final URL wastes crawl budget and slows every visitor arriving from an old link. One hop is the target, and it is worth auditing the map for chains before launch rather than after.

Blocking directives that shipped. Staging environments are closed to crawlers on purpose. The Disallow: / line and the noindex tag are the two pieces of the staging build that must never reach production, and they are the reason for the most severe drops.

Internal links still pointing at the old tree. Navigation, footers, in-content links and XML sitemaps that reference old paths force every crawler through the redirect layer and dilute the internal linking structure you spent years building.

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 argument is the one most often made too late. It looks like this in practice: adding a page type takes a developer instead of an editor, every integration needs a plugin that breaks at the next update, page speed collapses under campaign traffic, and a second language turns into a second website. Those are the symptoms of a site that has outgrown its foundation, and no amount of design work fixes them.

The cost argument is easier to check. Add licences, plugin subscriptions, hosting, and the hours your team spends working around the system. Compare that with a rebuild spread over three years. When the running total of workarounds is larger, the decision has already been made for you.

There are also bad reasons, and they are expensive. A new marketing lead who prefers a different stack, an agency that only builds on one platform, or a redesign wish that could be delivered as a template update on the current system. If the only thing changing is how the site looks, you want a redesign, and the redesign preparation guide is the shorter, cheaper path.

Scoping is an inventory exercise, and it happens before design, before development and before anyone picks a platform. You are answering one question: what exists today, and what is each item worth? Skip it and the project team will decide by accident, usually by migrating whatever was easy to export.

Start with four exports. A full crawl of the live site gives you every URL, its status code, title and canonical. Search Console gives you every page that earned an impression in the last 12 months. Your analytics gives you entry pages and conversions per page. A backlink export gives you the pages other sites point at, which are the pages that must never 404.

Cross-reference them into one sheet, then mark every URL with a decision: keep, merge, rename or retire. A page that earns nothing, ranks for nothing and is linked from nowhere can be retired. A page with two backlinks and no traffic still needs a destination. This sheet becomes the redirect map, the content plan and the acceptance list at the same time.

The same pass answers the questions that surprise projects later: how many forms exist and where do submissions go, which integrations write into the site, how many languages the site serves, which pages carry legal text, and who owns the DNS records.

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 keep it honest. Every destination has to be the closest equivalent page, not a category or the homepage. Every redirect has to be permanent, a 301, so search engines pass the old signals forward. And every old URL that genuinely has no equivalent returns 410, which tells crawlers the page is gone on purpose instead of pretending it moved.

Review it yourself, in a spreadsheet, on the rows that matter: your top 50 pages by traffic, your top 50 by backlinks, and every page that appears in a running ad campaign or an email footer. That is an hour of your time against the cost of finding the mistake in your analytics three months later.

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 deserves its own line. Rebuilding a site means rebuilding the cookie banner, and under GDPR together with the ePrivacy rules, non-essential cookies may not fire before the visitor agrees. Teams that reimplement tracking on a deadline often ship a banner that either blocks everything, which makes reporting look like a traffic collapse, or blocks nothing, which is a compliance problem rather than a reporting one.

The table below is the shortest version of the handover conversation. Every row needs an owner and a test that happens on staging, not a promise that it will be checked after 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 checks catch most of what matters. Compare page counts and titles between old and new. Confirm every canonical points at the new production domain rather than staging. Check that hreflang is reciprocal, because Google requires each language version to list all the others and itself. Confirm meta robots tags are absent where pages must be indexed. And run the redirect map as a batch: feed the old URLs to a crawler and confirm each returns a single 301 to a live page.

Performance belongs in the same pass. Core Web Vitals are assessed at the 75th percentile of real page loads, so a template that is fine on your laptop can still fail in the field. Measure the new templates against the thresholds published on web.dev, and treat a regression as a launch blocker rather than an optimisation for later. Our own notes on page speed work cover what to fix first when a rebuild lands slower than the site it replaced.

Accessibility is now part of the same conversation in Europe. Directive (EU) 2019/882, the European Accessibility Act, has applied since 28 June 2025, and a rebuilt or significantly updated service is treated as new rather than legacy. If your site sells to consumers, the migration is the moment accessibility gets built in, not the moment it gets postponed.

Launch day fails on sequence more often than on code. The order below assumes the new site is approved on staging and the redirect map has been verified as a batch, so the day itself is mechanical.

1. Freeze content edits on the old site, and tell the team when the freeze starts.
2. Run a final crawl of the live site. This is the last snapshot you can compare against.
3. Lower the DNS TTL 48 hours in advance so the switch propagates in minutes instead of a day.
4. Deploy the new site, still closed to crawlers, and smoke-test the critical paths.
5. Remove the crawl blocks: robots.txt first, then any noindex tags left on templates.
6. Enable the redirects and test 20 URLs by hand, chosen from your traffic and backlink lists.
7. Publish the new XML sitemap and submit it in Search Console.
8. Confirm analytics, consent and forms are recording on production, not just on staging.
9. Watch server logs for 404s for the rest of the day, and fix what appears.

Keep the old environment reachable for a while after the switch. Not live, but recoverable. A rollback plan that exists only as a sentence in a proposal is not a rollback plan.

The first month decides whether a migration was a project or an incident. Search engines need time to recrawl and reprocess the new addresses, so a dip in the first two weeks is normal and a dip that keeps deepening in week four is not. Watch page groups rather than the site total, because an average hides the section that broke.

Set the review rhythm before launch: daily for the first week, twice in the second, then weekly. Give one person the job of reporting it. Migrations rarely fail loudly, they fail as a slow decline that everyone assumes someone else is watching.

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 own pricing starts at €1,500 for a landing page delivered in two to three days, €4,500 for a corporate site of 10 to 30 pages delivered in one to three weeks, and €9,000 for a portal of 50 pages or more delivered in one to three months. A migration of an existing site of the same size lands in the same range, with the mapping and verification work added on top, because the rebuild is the same work and the inventory is extra. Figures are current as of August 2026.

The timeline that surprises people is not the build, it is the two ends. Inventory and mapping take one to three weeks of calendar time on a mid-size site because they need input from marketing, sales and legal, not only from developers. The monitoring window after launch runs four to eight weeks, and it needs to be in the contract as paid work rather than goodwill.

Budget separately for the things that are always forgotten: rewriting the consent setup, retesting every form and integration, updating campaign URLs in ad platforms and email tools, and fixing the internal links in old blog posts that point at renamed pages.

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.

Ask for these seven, in writing. A redirect map covering every URL that earned traffic or a backlink in the last 12 months, delivered for review before launch. Confirmation that old URLs return a single 301 to a relevant page and that retired pages return 410. Preservation of titles, meta descriptions, canonicals and hreflang, or a documented reason where they change. A tracking test plan listing every event, goal and form that must work on launch day. A statement on accessibility obligations under the European Accessibility Act where the site is in scope. Field-measured performance targets for the main templates. And a named monitoring window, four to eight weeks, with response times for defects found in it.

Add one more clause that costs nothing and saves arguments: the redirect map, the crawl exports and the tracking plan are handed over as files at project close. They are your documents. The next agency will ask for them, and so will you.

This is the short version of everything above, arranged in the order the work happens. Copy it into your project tracker and give every line an owner and a date.

Before the build

• Crawl the live site and export every URL with its status, title and canonical.
• Export 12 months of Search Console pages, analytics entry pages and referring domains.
• Mark every URL keep, merge, rename or retire.
• List forms, integrations, tracking tags, feeds and legal pages with their owners.
• Decide whether the platform, the structure and the domain change in one release or several.

Before launch

• Redirect map reviewed by a human on the top 50 traffic pages and top 50 linked pages.
• Staging crawled and compared with the live inventory.
• Canonicals point at production, hreflang is reciprocal, no stray noindex.
• Forms, consent paths and analytics events tested on staging.
• Core Web Vitals measured on the new templates, regressions treated as blockers.
• Rollback plan written, DNS TTL lowered.

Launch day and after

• Robots block removed, redirects live, sitemap submitted.
• Twenty redirects tested by hand, server logs watched for 404s.
• Ad and email landing URLs re-pointed at the new addresses.
• Monitoring rhythm agreed: daily for a week, then weekly for a month.
• Redirects kept live for at least a year, and the map archived with the project files.

We can describe this one from the inside, because it is our site. Vezert runs in English, German, Spanish, French and Dutch, and each language has its own URL slug rather than a translated page sitting on an English address. Every time a slug changes, the old address gets a permanent redirect, and the file that stores them currently holds 329 of them.

Two decisions did most of the work. Each article carries a stable identifier that never changes, so hreflang is generated from that identifier rather than from a filename, and renaming a page in one language cannot break the connection to the other four. And slug changes emit their redirect automatically as part of the same script that renames the file, which removes the step people forget.

The lesson transfers to any migration: the redirect is part of the rename, not a task that follows it. When the two are separate, someone eventually renames a page on a Friday and the redirect arrives on Monday, if it arrives at all. If you are planning a move that adds languages at the same time, our guide to multilingual websites covers the URL structure decisions that are hard to reverse later, and the site structure guide covers the page tree the redirect map has to follow.