A new website may look fine in staging, then produce large numbers of 404s, missing old articles, lower search traffic, and broken advertising links after the production switch. These incidents often result not from poor design or code quality, but from the absence of a migration plan.
Migration work should begin with an inventory of old-site URLs and continue through content mapping, redirects, launch cutover, and ongoing monitoring. The more pages and history a site has, the less the team can rely on memory.
01 Map Every Old URL to a New URL
Export every accessible URL from the old site and assign a destination based on traffic, backlinks, indexing, and business value. Every old URL should have a clear outcome: retain, update, merge, delete, or redirect.
When several old pages merge into one new page, confirm that the new page genuinely covers the original intent. Do not redirect every expired address to the homepage.

02 Preserve Content Value, Not Necessarily Its Exact Form
High-value articles and case studies can receive updated structures, facts, and visuals, but their core topics, important information, and searchable text should not disappear during the redesign. Low-value, duplicate, or outdated content can be consolidated or retired.
Also verify images, PDFs, and download addresses, especially resources referenced by external websites.
03 Point Redirects Directly to the Final Destination
Permanent URL changes typically use server-side permanent redirects and should avoid paths such as A to B to C. Redirect chains increase latency, maintenance difficulty, and crawl costs.
Before launch, batch-test status codes, destinations, parameters, and letter case for redirect rules in the staging environment.

04 Synchronize Canonicals, Sitemaps, and Internal Links
The canonical on each new page should point to its own preferred URL, and the sitemap should contain only final indexable pages. Navigation, body copy, breadcrumbs, and language selectors should link directly to new addresses rather than rely on redirects.
For multilingual pages, synchronize hreflang and reciprocal links across all versions.
05 Prepare Rollback and Monitoring for the Cutover
Before the production switch, back up the database, files, DNS, and configuration. Define the launch owner, time window, and rollback conditions. Immediately after cutover, check the homepage, core templates, forms, login, analytics, and important URLs.
Do not shut down the old server too early. First confirm that DNS, crawlers, and users are consistently reaching the new environment.

06 Monitor the Migration for at Least Several Weeks
Monitor 404s, redirects, server errors, indexing, crawling, core keywords, organic traffic, and conversions. Short-term ranking fluctuations are not uncommon, but an expanding decline or disappearing core pages requires prompt investigation.
Keep the migration map and launch log so omissions discovered later can be traced quickly.
Migration Execution Plan
| Stage | Key Deliverable | Acceptance Focus |
|---|---|---|
| Inventory | List of old URLs, content, backlinks, and traffic | No orphan pages or downloads omitted |
| Mapping | Old URL → new URL map | Destination matches the original intent |
| Implementation | Redirects, canonicals, internal links, and sitemap | Points directly to the final URL |
| Launch | Backup, cutover, and rollback plan | Core business functions and analytics work |
| Monitoring | Error, indexing, ranking, and conversion reports | Issues have owners and resolution deadlines |
Frequently Asked Questions
Do all old URLs have to be retained?
No, but every address with visits, backlinks, or business value should have an appropriate destination. Pages with no value can return 404 or 410.
How long are ranking fluctuations normal after a redesign?
There is no universal period. Evaluate the extent of the fluctuations and whether crawling and indexing are normal. Persistent loss of core pages or rising errors requires immediate investigation.
Can every old page redirect to the homepage?
This is not recommended. The destination should relate to the old content; otherwise, both user experience and search signals will be poor.
When should the new sitemap be submitted?
Submit it after the new site launches and canonical URLs are confirmed. Continue necessary monitoring, and do not submit early while staging addresses can be indexed.
When can the old server be shut down?
Wait until DNS is stable, old logs show almost no genuine visits, every asset has been migrated, and the site has been observed for a period.
| Service | View |
|---|---|
| Related service | View service details |
| Related reading | View service details |
| Design work | View service details |
| Project inquiry | Contact JVDS Design Studio |