Treat a website redesign as an evidence migration, not a visual launch

“Redesign” is too broad to be a technical plan. A reskin that keeps URLs, rendered copy, navigation, and tracking intact has a different risk profile from a domain move, a framework replacement, or a rewrite that consolidates service pages. Start by listing what actually changes: domain, protocol, hostname, path, query handling, renderer, information architecture, structured data, analytics property, consent behavior, forms, phone tracking, and CRM handoff. Avoid stacking a domain, URL, CMS, design, analytics-property, and consent-platform change into one launch when they can be sequenced and observed independently.

A baseline is not a screenshot of total sessions. It is a dated, reproducible record at the grain where migration failures occur. Export Search Console performance by page and query for a representative pre-launch window, preserving filters, row limits, anonymized-query gaps, and the fact that visible or exported rows are not a complete census. Record indexed and submitted URLs, crawl the full known URL union, and preserve responses, metadata, directives, schema, internal links, rendered body text, XML sitemaps, and robots. The point is enough bounded evidence to distinguish seasonality from a missing page or broken template.

Measurement needs its own baseline. Document landing-page sessions, form starts and completions, tracked calls, bookings, and accepted leads by the dimensions the business actually uses. Preserve the identifiers and fields that cross systems: client or session identifiers where policy permits, lead ID, event timestamp, landing page, referrer, campaign parameters, consent state, phone pool, form name, location, service, and CRM status. Record known gaps such as offline calls with no digital session or legacy forms that omit a lead ID. Unknown attribution should remain unknown rather than being redistributed into a preferred channel.

Build the URL map from evidence, not from the new navigation alone. Union the crawl, sitemaps, indexed pages, landing pages, backlinks if available, and URLs that produced impressions, conversions, or accepted leads. For each old URL, assign an intentional outcome: unchanged, redirected to a close replacement, consolidated into a broader resource, or removed with an appropriate not-found or gone response. A blanket redirect to the home page hides planning gaps and creates a poor destination for both users and crawlers.

Google supports direct permanent server-side 301 or 308 redirects as a strong signal that a destination should become canonical, but redirects are only one signal. The destination should also return a successful response, declare a self-consistent canonical when appropriate, remain crawlable, appear in internal links and the new sitemap, and fulfill the old page’s purpose. Redirect chains, loops, mixed protocol targets, and irrelevant destinations weaken the contract even when the final page eventually loads.

A checklist says that someone looked. An acceptance contract defines the population, denominator, assertion, threshold, evidence location, environment, build identifier, owner, due time, and disposition for every condition. It prevents the common launch-day negotiation in which missing metadata is called minor, broken analytics is deferred, and no one knows whether a redirect sample represents the full map. Each condition should be machine-testable where practical and manually reviewed where meaning matters.

Use representative template tests during development, then run full URL-map checks and all critical conversion contracts against the release candidate. Include non-HTML assets that carry search or customer value—images, PDFs, feeds, scripts, styles, and downloads—in the migration inventory. A crawler cannot judge replacement meaning, and a manual reviewer cannot reliably find loops across thousands of rows. Preserve machine and manual evidence with build identifiers.

A redesigned form often changes more than its appearance. Write a versioned event-and-lead data contract for each conversion path: business definition, user action, event name, parameter name and type, allowed values, privacy class, consent dependency, analytics destination, server or vendor handoff, CRM field, pseudonymous reconciliation key, final business status, owner, retention, and validation evidence. Test successful and unsuccessful submissions, duplicate clicks, validation errors, consent states, mobile layouts, call-tracking swaps, cross-domain journeys, and SPA route changes.

Do not use analytics conversions as a substitute for lead records. Analytics can show that an event was observed; the CRM can show whether an inquiry was accepted, qualified, won, duplicated, spam, or unreachable. Reconcile the systems at a documented cadence using lead IDs or another governed key where possible. Expect legitimate differences caused by consent, blocked scripts, cross-device behavior, phone calls, and processing rules. The goal is an explainable bridge, not artificially identical totals.

Immediately after deployment, verify DNS and certificates if changed, critical responses, robots access, old and new sitemaps, canonical targets, redirects, rendered templates, non-HTML assets, structured data, browser and network errors, analytics collection, and real test leads. For a domain move, verify all relevant old and new Search Console properties—including protocol, www/non-www, and affected subdomains—and submit Change of Address where required. Do not use Change of Address for an HTTPS-only move. Keep direct 301/308 redirects for at least one year and retain the old host, ownership, and logs until old traffic is zero through the approved observation window.

Monitor at several clocks. Minutes and hours are appropriate for server errors, form failures, accidental noindex directives, and redirect defects. Days are more useful for crawl discovery, indexed-page patterns, landing-page behavior, and event reconciliation. Weeks may be needed to interpret page-and-query performance without overreacting to ordinary volatility. Compare like-for-like days and annotate campaigns, holidays, outages, and releases. Report priority URL groups and accepted leads, not only sitewide averages that can conceal a failed service line.

A useful launch plan defines hard go/no-go gates before pressure arrives. Failed critical forms, blocked priority pages, unresolved redirect-map defects, an accidental noindex, broken production rendering, or missing acquisition fields stop launch. After deployment, those failures can justify rollback only when a tested rollback exists. Stateful changes—submitted leads, changed DNS, new URLs discovered, cache state, or third-party writes—may require recovery or roll-forward instead of reversal. Search fluctuation alone usually requires diagnosis first.

Set thresholds in the business’s own units and label them as internal controls: for example, zero tolerance for failed critical forms, an agreed maximum number of unmapped priority URLs, and a review trigger for sustained loss in accepted leads from a defined page group. Do not borrow universal percentage promises from case studies. Traffic, query mix, demand, and lead quality differ. The contract should force a response to strong evidence while allowing enough time for normal processing and noise.

Close the migration only when the URL map and critical conversion matrix are resolved, the old-host retirement rule is satisfied, Search Console and sitemap monitoring show no unexplained priority failures, measurement reconciles within its approved coverage bounds, accepted-lead paths pass, and every exception has an owner and disposition. A launch date is not a closeout condition.