A business planning a website migration

The starting challenge

A redesign can accidentally remove popular guides, product URLs, images, or regional pages. Redirecting everything to the homepage hides the loss rather than preserving the visitor's intent. Treat a migration as a coordinated release across content, server configuration, analytics, search ownership, and customer-facing links.

A sensible first work cycle

1. Collect old URLs from the CMS, sitemaps, analytics, Search Console, and known inbound links. Map each important URL to the closest legitimate new destination. Explicitly identify content being retained, merged, replaced, or removed.
2. Use server-side 301 or 308 redirects for permanent moves when suitable. Point each old address directly to the final new page, avoid loops, and test both host variants, HTTP-to-HTTPS behavior, and meaningful query parameters.
3. Before launch, update internal links, canonicals, language annotations, images, and sitemaps to the new URLs. Verify access settings and search ownership. Keep a configuration backup and a practical rollback procedure for deployment defects.
4. After launch, test the mapping in bulk and monitor error responses, important landing pages, and search visibility. For domain moves use the applicable Search Console process. Maintain redirects for the documented long-term migration period, not only the launch week.

Evidence to review before scaling

• Important old URLs reaching the intended final destination.
• Redirect loops, chains, and new error responses.
• Search clicks and conversions for mapped landing-page groups.

What would make the plan change?

A discovery issue, a mismatch between search intent and the page, unreliable measurement or an implementation dependency can change the order of work. Keep a record of assumptions, verify each change and agree on a review point before extending the scope.

Read the detailed methodology ↗