Define what is changing before planning the move
A website migration is any release that changes how important pages are hosted, rendered, organised or addressed. A redesign may retain every URL but alter navigation and content. A platform move may change templates, internal links and structured data. A domain or URL migration adds another layer because search systems must discover each new location and transfer signals from the old one.
Write down the moving parts before development begins: domain and protocol variants, hosting, content management system, URL patterns, rendering method, navigation, page content, analytics, consent controls, feeds, sitemaps and business integrations. The risk comes from interactions between these changes, so an accurate scope is more useful than labelling the project a simple redesign.
Capture an evidence-based baseline
Crawl the existing site while it is still available and preserve the results. Record every indexable URL, status code, canonical, title, description, heading, internal link, structured-data type and sitemap entry. Export landing-page performance, conversions, backlinks and Search Console data so priority pages are not defined by memory or page views alone.
The baseline becomes both the migration inventory and the acceptance test. It should identify pages that earn qualified traffic, links, citations or revenue; pages required for legal or customer journeys; intentional redirects; and known defects that should not be copied into the new site.
- Crawl and export all discoverable URLs and response codes
- Save Search Console, analytics and conversion baselines
- Identify linked, cited and commercially important pages
- Record current robots, canonical and structured-data behaviour
- Separate defects to fix from signals that must be preserved
Build a page-to-page redirect map
Map every changing URL to the most relevant new destination. Use a server-side permanent redirect such as 301 or 308 when the move is permanent. Avoid sending many unrelated pages to the homepage: a redirect should preserve the user's intent, and a genuinely removed page may be better served by a clear 404 or 410 response when there is no equivalent replacement.
Point each old URL directly to its final destination. Redirect chains add latency and make testing harder. Include protocol, www and non-www, trailing-slash, case and parameter variants where they have been used or linked. Google recommends retaining migration redirects for at least a year, and keeping useful legacy redirects longer can continue to help visitors following old links.
Preserve the information architecture and evidence
A technically correct redirect cannot compensate for removing the information that made a page valuable. Compare the new page with the old one for primary purpose, important sections, original evidence, media, internal links and calls to action. Improve weak content deliberately, but investigate large-scale losses of relevant text rather than assuming a cleaner design is automatically a stronger search result.
Rebuild navigation and contextual links so priority pages remain discoverable through normal anchor elements. Carry across accurate organisation, person, service, product and article relationships, then validate that structured data still matches visible content. Canonicals should point to the preferred new URLs, not the staging site or legacy domain.
Test the production-like build before launch
Test a production-like environment with access controls that do not leak into the release. Crawl it using the redirect map and baseline as the specification. Check templates as well as sample pages: status codes, canonicals, robots directives, titles, descriptions, headings, internal links, pagination, hreflang where applicable, schema, images, forms, analytics and Core Web Vitals risks.
Create a launch gate for accidental blockers. Staging noindex tags, a disallow-all robots file, password middleware, incorrect host canonicals and missing Search Console verification are common because they are sensible in staging and destructive in production. The release checklist should name the person responsible for removing or replacing each control.
- No staging host, noindex rule or crawl block remains
- Priority old URLs redirect once to the mapped destination
- New canonical URLs return 200 and are internally linked
- Sitemap, robots.txt and structured data use production URLs
- Analytics, consent, forms and conversion events work
- Mobile layouts and important page templates are usable
Launch the complete set of search signals
Deploy redirects, pages, canonical tags, internal links and XML sitemaps as one coordinated release. Verify every domain variant involved in the move and keep Search Console ownership intact. For a domain move, use Google's Change of Address tool after the redirects are live and verified; for other URL changes, the redirects, internal links and sitemap communicate the new locations.
Submit the new sitemap, inspect representative URLs and update important external profiles, campaigns and high-value backlinks. Notify IndexNow participants of changed URLs where appropriate. These steps support discovery, but they do not replace page-level redirects or guarantee immediate reprocessing.
Monitor by page group, not only site-wide totals
Expect some temporary movement while crawlers revisit URLs and search systems reassess the site. Watch server logs, crawl errors, indexation, canonical selection, sitemap processing, rankings, landing-page traffic and conversions. Segment the evidence by page type and business priority so a stable total does not conceal a failed service or location section.
Investigate patterns against the baseline. Old URLs still receiving crawler traffic may need longer-lived redirects or better external-link updates. New URLs excluded as duplicates may have incorrect canonicals or insufficiently distinct content. A migration is complete when important journeys, signals and measurement work reliably—not simply when the release is live.