Most website redesign checklists begin with colours, layouts and features. By then, several of the decisions that determine whether the project will work have already been skipped. A redesign can look dramatically better and still weaken the message, confuse existing customers, lose useful search visibility or leave the internal team with a site nobody can maintain.
A B2B website is part sales conversation, part evidence library and part technical product. Treating it as a visual reskin is why so many redesigns launch on time and disappoint six months later. The twelve decisions below create a stronger brief before design starts.
1. Define what the redesign must change
Replace “improve the website” with one business problem you can observe. The site attracts the wrong enquiries. Buyers cannot understand the offer without a call. A new service has no clear place. Sales keeps rebuilding the same explanation in every proposal. The brand looks smaller than the work it represents.
Choose one primary outcome and a few supporting measures. Useful baselines might include qualified enquiries, form completion, demo requests, organic landing-page traffic, time spent on key service pages, or the number of times sales has to clarify the same point. A redesign cannot be judged if success only means that the team likes it more.
2. Record the current baseline
Export the evidence before changing anything. Record analytics for important pages, Search Console queries, current rankings, backlinks, form conversion, top entry pages, device mix and the questions prospects ask after visiting the site. Save the current sitemap and crawl every indexable URL.
The aim is not to preserve every page. It is to know what already works. A visually weak article may bring qualified traffic. An unfashionable service page may answer the exact question that closes a deal. Without a baseline, useful assets are easy to delete because they did not look important in the old navigation.
3. Name the primary visitor
A homepage written for everyone becomes a lobby with twelve doors and no reception desk. Decide whose decision the site must make easier. For a B2B company, that may be a founder, marketing lead, procurement team or technical evaluator. They can all visit, but they should not all control the first screen.
Write down what the primary visitor already knows, what they are trying to decide, what makes them hesitate and what evidence reduces that hesitation. This becomes a practical filter for messaging, navigation, case studies and calls to action.
4. Settle the message before the interface
The first screen should answer three questions quickly: what is this, who is it for, and what should I do next? If the team cannot agree on those answers in plain text, visual design will only make the disagreement harder to see.
Build a message hierarchy before a page hierarchy. Start with the central promise, the supporting reasons to believe it, the offers that deliver it and the proof available for each offer. The interface can then create emphasis instead of trying to invent meaning.
5. Audit every piece of content
Give each existing page one decision: keep, improve, merge, remove or redirect. Check whether the content is accurate, useful to the intended visitor, supported by proof and connected to a next step. Do the same for PDFs, gated resources and image assets that may receive traffic or links.
This is also where content gaps become visible. A service without a case study, a case without a measurable outcome, or a technical product without an explanation for a non-technical buyer is not a layout problem. Put the missing evidence into the production plan.
6. Protect URLs and search equity
Create a page-to-page URL map before development. Every valuable old URL needs a relevant destination on the new site. Google recommends permanent server-side redirects for pages that have moved, warns against sending many unrelated URLs to the homepage, and advises keeping redirects for at least one year.
Preserve useful page topics, metadata, internal links and canonical rules. Remove development noindex instructions before launch, submit the new sitemap, and verify both properties in Search Console if the domain changes. Expect some temporary fluctuation while search engines recrawl the site. A migration is a process, not a switch.
7. Design the conversion path
Decide what a ready visitor should do and what a not-yet-ready visitor should do. One may start a project or request a demo. The other may read a case study, compare services or save a useful guide. Giving every visitor the same contact button ignores how consideration works.
Keep forms proportional to the decision. Ask only for information someone can reasonably provide at that stage, explain what happens after submission, and name the expected response time. The best conversion detail is often certainty.
8. Set the accessibility standard
Treat accessibility as a design and development requirement from the start. WCAG 2.2 is the current W3C Recommendation. A practical baseline includes logical headings, sufficient contrast, descriptive links, keyboard access, visible focus states, labelled forms, meaningful alternative text and support for people who prefer reduced motion.
Retrofitting these decisions after approval creates unnecessary compromise. Accessibility also improves the site for people using small screens, slow connections, temporary injuries or unfamiliar interfaces. It is part of quality, not a compliance layer added at the end.
9. Agree on a performance budget
Decide how fast and stable the experience needs to be before high-resolution images, video and animation fill the design. Google’s current Core Web Vitals targets are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less at the 75th percentile of visits.
Those numbers are not a creative restriction. They force useful choices: responsive images, reserved media dimensions, fewer font files, deliberate motion and less JavaScript competing for the main thread. Measure real-user data after launch because a fast laptop on office Wi-Fi is not the audience.
10. Decide who owns the site after launch
Name the person responsible for publishing, approvals, analytics, technical updates and stale content. Then design the content model around that reality. A perfect CMS nobody trusts will create workarounds. A flexible page builder without governance will recreate the inconsistency the redesign was meant to solve.
Define the smallest set of reusable page types, components and editorial rules the team needs. Training, documentation and permissions belong in the project scope, not in an optimistic handover email.
11. Build a launch QA plan
Test representative templates, not only the homepage. Check content, links, forms, email delivery, analytics events, consent behaviour, metadata, structured data, redirects, canonical URLs, sitemap access, robots rules, heading order, keyboard navigation and responsive layouts.
Test on real phones and at least the browsers your analytics show people use. Confirm that error states are understandable and that the server returns real status codes for missing pages. Assign owners and deadlines to every launch issue so the final week does not become a shared spreadsheet with no decisions.
12. Plan the first 30 days
Watch Search Console coverage, redirect errors, form submissions, analytics events, Core Web Vitals and the behaviour of key landing pages. Ask sales whether enquiries are better informed and whether old objections have changed. Fix broken paths quickly, but do not redesign the redesign based on two unusual sessions.
Schedule a 30-day review while the project team is still available. Compare the new evidence with the baseline, record what changed, and turn the next improvements into an owned roadmap.
The checklist in one line
A successful website redesign moves in this order: business problem, audience, message, content, structure, design, build, migration, measurement. When the order is reversed, polish carries decisions it was never meant to make.