A B2B website redesign can improve clarity, but it can also move URLs, erase evidence, break forms, and reproduce the same unclear positioning in a newer template. Before approving a redesign, identify the business decision, audience, page jobs, proof, technical constraints, handoff, and measurement contract.
1. State the redesign decision
Write what is failing: audience fit, service explanation, trust, navigation, technical debt, accessibility, form quality, speed, localization, CRM route, or maintenance. Name the market, sales cycle, owner, budget, deadline, risk, and stop rule.
Separate a visual refresh from an information-architecture change, migration, replatform, content rewrite, and conversion intervention. Each has different evidence and rollback needs.
Make a one-page problem statement for each proposed workstream. Include the observed symptom, affected audience, current baseline, likely cause, smallest safe intervention, owner, and evidence that would falsify the hypothesis. This keeps a redesign from becoming a container for unrelated requests that cannot be evaluated together.
2. Collect user and sales evidence
Review search questions, page paths, calls, form messages, objections, lost reasons, accepted quality, sales cycle, and customer interviews. Ask what the visitor was trying to decide and what Sales needed to know. Keep role, industry, stage, market, device, and page version.
Do not treat stakeholder preference as user evidence. Preserve disagreements and unknowns until the team can test them.
Weight evidence by decision proximity. A recorded buyer objection or an accepted lead is closer to commercial truth than a preference poll; a page-path pattern is useful but still needs interpretation. Note sample size and collection period so that a loud anecdote does not erase a recurring pattern—or turn a short seasonal spike into a permanent information-architecture rule.
3. Map page jobs and URLs
Inventory homepage, service, industry, location, comparison, proof, resource, support, and request pages. Record audience, question, stage, evidence, CTA, canonical, internal links, owner, status, and redirect intent. Mark distinct, overlapping, supporting, obsolete, or unknown.
If the redesign proposes one template for every job, test whether a single structure can express the necessary differences. Count page jobs, not only URLs.
4. Audit offer, proof, and claims
List capability, outcome, process, pricing, timeline, integration, compliance, team, client, and availability claims. Add source, date, reviewer, confidence, and expiry. Label anonymized examples and do not invent results, logos, quotes, or benchmarks.
The redesign must make the promise more truthful and useful, not merely more polished. Include boundaries and a not-fit route so the website does not send every request to Sales.
5. Check information architecture and migration
Map old to new URLs, redirects, canonicals, internal links, breadcrumbs, sitemap, robots, language versions, images, documents, and search. Preserve valuable content and decide which pages should merge or retire. Test old bookmarks, campaign links, partner links, and shared documents.
Keep a migration inventory with owner, status, evidence, exception, and rollback. A staging crawl is not proof that the public release persisted.
Add a release sequence to the inventory: content freeze, export, redirect deployment, template release, forms and integrations, analytics validation, accessibility pass, representative crawl, and post-release monitoring. Define which defects block launch and which can be corrected in a reversible follow-up. Keep the old map and a dated redirect file so that an unexpected loss can be diagnosed rather than guessed at.
6. Test forms, routing, and capacity
Run form, call, booking, email, chat, and partner tests. Check consent, validation, duplicates, source, owner, response SLA, wrong-fit, existing customer, urgent, out-of-market, and after-hours paths. Trace a request to accepted quality and mature outcome.
If the CRM handoff is broken, include it in scope or hold the redesign. A new layout cannot make an unowned queue serviceable.
7. Check accessibility and performance
Test keyboard, focus, labels, errors, contrast, zoom, language, touch targets, mobile, slow connection, and interrupted submission. Record template, device, network, script, image, font, and third-party observations. Google’s Core Web Vitals guidance is a measurement boundary, not a conversion guarantee.
8. Define analytics and governance
Snapshot page views, CTA, form, call, booking, consent, error, CRM, accepted quality, opportunity, and mature outcome events. GA4 event guidance can name interactions, but an event is not revenue. Use Search Console Performance reporting as visibility evidence, not proof of buyer fit.
Assign content, technical, data, Sales, privacy, and service owners. Set review triggers for offer, regulation, proof expiry, broken forms, capability, and migration defects.
Document the minimum reporting view that all owners will use. It should join page version and source with interaction, response, accepted quality, opportunity, and mature outcome while keeping unknown and not-yet-mature states explicit. If teams use separate dashboards, record the reconciliation rule and the person responsible for resolving a disagreement.
9. Run a bounded redesign test
Choose one audience, funnel stage, or page cluster. Snapshot baseline, preserve a comparison where safe, change one class of issue, and set a maturity date. Review quality, response, opportunity, and delivery—not only clicks or form count.
Stop if the job is unclear, evidence is unsourced, the route is unserviceable, data rights are uncertain, or rollback is not possible. A redesign is ready only when it improves a defined decision without hiding what remains unknown.
Use a representative release set, not only the homepage. Include one service page, one proof page, one form, one mobile path, one redirect, one localized page, one slow-device case, and one wrong-fit request. Capture the expected result and the observed result for each. This small set exposes systemic template or handoff defects before the team spends effort polishing every page.
| Gate | Required evidence | Hold if | | — | — | — | | decision | failure, audience, stage, owner, stop rule | “make it modern” is the brief | | content | claims, proof, limits, reviewer | copy is generic or invented | | architecture | page jobs, redirects, canonicals, links | migration map is missing | | route | forms, calls, CRM, SLA, capacity | queue has no owner | | UX | accessibility, mobile, errors | happy path is the only test | | measurement | events, quality, outcomes, limits | event is called revenue | | governance | owners, triggers, rollback | no one maintains the release |
Approve a redesign when the evidence shows a defined problem and a reversible remedy. Otherwise, fix the smallest broken path first.
How did this article land?
Choose one reaction. You can change it anytime.
