A B2B website redesign should make it easier for the right visitor to understand your offer, trust your business and take the next step. It should also make the site easier for your team to maintain. A new visual identity can support those goals, but it cannot compensate for unclear positioning or a broken enquiry process.
Use this checklist to prepare a brief, compare proposals and reduce surprises during the project.
1. Define the problem and the outcome
Write down what is not working today. Are prospective clients confused about your services? Are qualified visitors leaving before contacting you? Is the site difficult to update? Does it fail on mobile devices? Ask sales and customer-facing staff what questions they repeatedly answer.
Translate the problems into outcomes you can measure. For example, track qualified enquiries by service, successful form submissions, or the time your team needs to publish a case study. Establish a baseline before launch and agree how the metric will be collected.
Not every issue requires a complete rebuild. If positioning and technology are sound, improving a few service pages or repairing a form may be a better first step. A rebuild becomes more compelling when outdated infrastructure, content and user journeys all need substantial changes.
2. Understand your visitors and their decisions
Identify the people involved in buying your service and the information each needs. A founder may want to understand outcomes and cost; a technical lead may need to evaluate integration, security and maintainability. In many B2B purchases, both influence the decision.
Review actual enquiries and sales conversations. Note the words prospects use, the problems they describe and the objections that delay a decision. Avoid designing around an imagined customer if you can speak to real ones. The output can be a simple list of questions each important page needs to answer.
3. Inventory content and search traffic
Export the current URLs and group them by purpose: services, industries, case studies, articles and legal pages. Mark each page to keep, improve, combine or retire. Use search and analytics data where available to identify pages attracting relevant visitors and links.
Map old URLs to their new destinations before development begins. When a URL changes, use a permanent redirect to the most relevant replacement. Avoid redirecting every retired page to the homepage: a visitor looking for a specific service needs a useful destination. Google’s site move documentation explains the migration process in more detail.
4. Build the page structure around buyer questions
Plan the main navigation and service pages before polishing the visual design. A useful service page typically answers:
- Who is this service for, and what problem does it solve?
- What does the engagement include, and what is outside the scope?
- How does the process work, and what will the client need to contribute?
- What evidence supports the approach?
- What should a prospective client do next?
Use case studies where you have permission to describe the work. Explain the initial problem, your contribution and the result, with context for any numbers. A clear example is more useful than an unsupported claim that your work is “world class.”
5. Design the enquiry journey
Choose one primary action for each important page, such as requesting a consultation or describing a project. Secondary actions can help visitors who are not ready to enquire, such as reading a case study or exploring a related guide.
Ask for information that helps the next conversation. A long form may be appropriate for a complex project, but every required field should have a reason. Make labels visible, explain errors in plain language and confirm when a submission has been received. Test the whole path, including notification delivery and who follows up.
6. Set the technical and editorial requirements
Agree who will maintain the site and how frequently content will change. The appropriate content management system depends on the team’s needs, the complexity of the content and the ongoing cost of ownership. Specify accessibility, responsive behaviour, analytics, integrations, backups and hosting responsibilities in the brief.
For performance, use real-user data where available and test representative mobile devices. Google’s Core Web Vitals guidance explains the user-experience metrics and why both field and lab data matter. A fast demo does not guarantee a fast production site once real images and third-party scripts are added.
7. Check the site before launch
Review the final site with real content, not just placeholder copy. Test the navigation, keyboard access, form submission, mobile layouts and key browser combinations. Check page titles, descriptions, canonical URLs, image descriptions and sitemap output. Verify the planned redirects on a staging environment where possible.
Assign an owner for every launch task: publishing content, updating DNS, checking analytics, testing enquiries and monitoring errors. Keep a copy of the old URL inventory and the redirect map for the post-launch review.
8. Measure and improve after launch
Confirm that the site is accessible, forms deliver correctly and important redirects work. Monitor indexing and traffic trends in Search Console, while allowing time for search engines to process the move. Compare qualified enquiries and user behaviour with the baseline; annotate campaign or seasonal changes that may affect the comparison.
Schedule a review after the team has used the site in real conditions. Fix confusing content, broken paths and editorial bottlenecks first. A redesign is a starting point for learning, not a one-time conversion guarantee.
If you are planning a redesign, explore our website design services and prepare a brief using the questions above.
