A beautiful redesign can still damage demand if it removes the pages people discover, breaks external links, changes every URL, blocks crawling, loses analytics, or replaces useful content with vague marketing copy.

Google's site-move documentation emphasizes preparation, URL mapping, permanent redirects, internal-link updates, canonicals, sitemaps, testing, and monitoring. Use that as the technical baseline even when the migration remains on the same domain.

Before design: capture the current system

  • Export every indexable URL from the sitemap, CMS, analytics, Search Console, backlink tools, and server logs available to the team.
  • Record titles, descriptions, canonicals, status codes, headings, internal links, structured data, media, and word count for important pages.
  • Mark pages that earn impressions, clicks, conversions, backlinks, calls, bookings, or assisted revenue.
  • List forms, phone tracking, checkout, booking, CRM, pixels, consent, email, maps, reviews, and other integrations.
  • Capture a 28-day and 90-day baseline for organic landing pages, branded and non-brand queries, conversions, and errors.

Do not let a visual wireframe silently decide which content survives. The migration inventory should inform information architecture before copy and layouts are finalized.

Make one explicit decision for every old URL

Keep the URL when its intent and destination remain the same. Redirect it permanently when a better replacement exists. Consolidate overlapping pages only after deciding which page will carry the combined value. Return a real not-found response when a retired page has no relevant replacement.

Create a two-column map from each old URL to its final new URL. Avoid redirect chains, loops, broad rules that catch unrelated paths, and homepage redirects for deleted content. Preserve query parameters only when they have a continuing purpose.

Update every internal link to the final destination instead of relying on the redirect. Update canonicals, hreflang where used, structured data URLs, image references, navigation, breadcrumbs, XML sitemaps, email templates, ads, profiles, and downloadable documents.

Protect useful content and search intent

For each important page, identify the search intent, buyer question, proof, and conversion action it currently serves. The redesign can improve clarity, but it should not delete the specific information that made the page useful.

Map old headings, FAQs, comparison details, locations, policies, proof, and media into the new page. If several pages consolidate, the destination must genuinely answer the combined topics rather than merely receiving their redirects.

Keep navigation and contextual internal links descriptive. A page should be discoverable from a relevant hub, service, industry, location, or article path. Orphan pages in the sitemap are not a substitute for information architecture.

Staging checklist before launch

  • Crawl the staging site and compare expected URLs, status codes, titles, headings, canonicals, directives, links, images, and schema.
  • Verify staging protection will not accidentally ship as a production noindex or blocked robots rule.
  • Test forms, phone links, email, booking, checkout, CRM delivery, confirmation states, and error handling.
  • Test keyboard access, labels, focus, contrast, zoom, small screens, and reduced-motion behavior.
  • Check representative page templates for Core Web Vitals risks and large media.
  • Validate the redirect map against the actual production rules.
  • Confirm analytics ownership, consent behavior, events, cross-domain settings, and conversion definitions.
  • Prepare the final sitemap and a rollback or hotfix owner.

Launch-day sequence

  1. Reduce content changes and take a final export of the old site's important URLs and settings.
  2. Deploy the new site and redirects together.
  3. Check the homepage, top landing pages, robots.txt, sitemap, key canonicals, forms, analytics, and a sample from every redirect pattern.
  4. Crawl the public site for accidental blocks, broken links, redirect chains, missing assets, duplicate titles, and server errors.
  5. Submit or refresh the sitemap in Search Console and inspect several representative URLs.
  6. Annotate analytics with the launch time, scope, and known issues.

If the domain changes, use Google's Change of Address guidance after domain ownership, redirects, canonicals, and verification are ready. Google advises not to combine that move with unrelated major changes when possible.

Monitor behavior, not only rankings

Check daily during the first week, then weekly as the site stabilizes. Watch index coverage, crawled URLs, server errors, redirect errors, canonical selection, sitemap discovery, organic landing pages, queries, form delivery, calls, bookings, checkout, and qualified lead quality.

Some visibility fluctuation is normal during a move. Diagnose patterns rather than reacting to one keyword. If one directory collapses, inspect its redirects, canonicals, content, internal links, and crawlability. If traffic remains but leads fall, inspect conversion paths and measurement.

Keep redirects in place. Google's move guide recommends maintaining them as long as possible, generally at least a year. Keep the URL map, baseline, deployment notes, and fixes as the permanent migration record.

Decide whether redesign is actually the right project

If the current site has sound architecture but weak visual trust or conversion copy, a focused improvement may be safer than rebuilding everything. If the CMS, templates, navigation, performance, or workflows block necessary changes, a rebuild can be justified.

Use the free website audit to identify obvious issues, compare redesign versus a custom system build, or review fixed-scope website builds before choosing the migration surface.