B2B Website Redesign RFP: Requirements and Acceptance Criteria

A B2B website redesign RFP should make competing proposals easier to compare. That requires more than a page list and a request for a new visual direction. The brief must show what buyers need to accomplish, what the project includes, what the organization will still own after launch, and how delivery will be accepted.

This guide provides a buyer-side structure for writing that brief. It sits between a pre-redesign website audit and the later decision to evaluate a web designer or delivery team. The audit defines the problem; the RFP turns the approved problem into comparable requirements; the selection process tests who can deliver them.

The short answer: write a decision document, not a wish list

A useful B2B website redesign RFP answers eight questions:

1. Which buyer tasks and business decisions must the website support?
2. Why is the current site unable to support them?
3. Which pages, content, systems and migration work are in scope?
4. Which requirements are fixed, and where can a supplier propose alternatives?
5. Who owns content, accounts, approvals and maintenance?
6. What evidence must each proposal include?
7. Which acceptance checks define a completed delivery?
8. How will proposals be compared using the same decision criteria?

The section order is a CHCZ editorial framework. It is designed to reduce hidden assumptions, not to prescribe a universal procurement format. Adapt it to your organization’s governance and purchasing process.

1. Start with the buyer problem

Open the RFP with the problem that needs to be solved, not the interface you expect to receive. Name the priority audience, the task that person is trying to complete, the evidence they need, and the action the website should make possible.

Verified principle: GOV.UK guidance on learning about users and their needs says teams should begin by learning who their users are, what they are trying to do, how they currently do it, and which problems they experience. It also advises treating suggestions that do not come from users as assumptions to be tested. Its guidance on how the discovery phase works separates the problem from a pre-selected solution and asks teams to identify constraints and how success will be measured.

Editorial application: a B2B redesign brief should state the buyer problem in plain language before prescribing a layout, platform or feature. For example, “technical evaluators cannot find the evidence needed to shortlist us” is a problem statement. “Build an interactive product carousel” is already a solution.

Include a concise context block:

• the business and offer the site must explain;
• the primary buyer roles and the decisions they make;
• the current website constraint, supported by available evidence;
• the inquiry or handoff the site should enable;
• the internal owners who will use and maintain the site.

2. Separate outcomes, requirements and proposed solutions

Mixing these three layers makes proposals difficult to compare. An outcome describes the change the organization needs. A requirement describes a condition the delivered site must meet. A proposed solution is one way a supplier might meet it.

Mark fixed requirements as fixed. Mark assumptions as assumptions. Invite alternatives where the supplier may have better evidence. This makes it possible to assess reasoning instead of rewarding the proposal that mirrors the brief most closely.

3. Define scope with an inventory, not adjectives

“Modern,” “premium,” “fast” and “SEO-ready” do not define scope. Attach or summarize the assets that determine the real work:

• current URL inventory and intended treatment for each important page;
• content types, languages and approval owners;
• forms, integrations, downloads and gated resources;
• analytics, search, consent and tag-management dependencies;
• CMS roles, publishing workflow and maintenance responsibilities;
• brand assets, reusable components and known technical constraints;
• environments, hosting, backups and deployment ownership.

For each item, label it retain, revise, merge, remove, create or unknown. Do not force an early answer where discovery is still needed. A visible unknown is safer than an assumption hidden inside one supplier’s estimate.

Also write an explicit out-of-scope list. Content production, translation, photography, data migration, CRM configuration, ongoing optimization and post-launch support are separate bodies of work unless the brief assigns them.

4. Make content and search migration first-class requirements

A redesign can preserve the visual intent of a page while breaking its URL ownership, internal links or index signals. The RFP should therefore define who owns the content inventory, redirect map, canonical review, metadata transfer, sitemap validation and post-launch monitoring.

Verified fact: Google’s site-move documentation recommends preparing and testing the new site, mapping current URLs to new destinations, using server-side permanent redirects, updating canonicals and internal links, submitting the new sitemap, and monitoring both user and crawler traffic. Google notes that processing happens per URL and does not follow a fixed crawl schedule.

Editorial application: ask every supplier to explain the artifact and acceptance check for each migration responsibility. “SEO included” is not enough. The response should identify who produces the URL map, who approves consolidation decisions, how redirects are tested, and how unexpected crawl or indexing errors will be triaged.

• Require one canonical owner for each search intent.
• Preserve important URLs unless a documented consolidation decision justifies a change.
• Map every changed URL to the most relevant destination.
• Update internal links so the new site does not depend on redirect chains.
• Define launch and post-launch checks for status codes, canonicals, robots directives and Sitemaps.

5. Specify the CMS operating model and ownership

The RFP should describe how the site will be operated after the project. Name the people who publish, review, approve, measure and maintain content. Ask suppliers to show how the proposed content model supports those responsibilities.

Verified fact: WordPress documents roles as collections of capabilities that control which actions a user can perform. That makes role design, named accounts and handover access part of the operating model rather than a launch-day detail.

Request a handover register covering the domain, hosting, CMS, source files, repositories, analytics, search properties, integrations, licenses, backups and recovery documentation. State which accounts must be held by your organization and which access is temporary. Ask for role-appropriate access rather than one shared administrator account.

6. Turn accessibility, performance and measurement into testable work

Requirements such as “accessible,” “fast” and “trackable” must name the scope, evidence and acceptance method.

Accessibility: W3C describes WCAG 2.2 as a stable standard with testable success criteria at A, AA and AAA levels. Its WCAG-EM methodology begins by defining the evaluation scope, goal and conformance level, then identifying key views and functionality, selecting a representative sample, evaluating it and reporting findings. W3C also says accessibility should be integrated through planning, design and development rather than left until the final evaluation.

The RFP should therefore name the intended WCAG version and level where applicable, the views and journeys that must be tested, the balance of automated and knowledgeable human review, and the format of the final evidence. Confirm any jurisdiction-specific obligations with the appropriate specialist; this article is an editorial planning guide, not legal guidance.

Performance: ask the supplier to separate lab diagnostics from field measurement, identify the page templates and devices in scope, and state which team owns hosting, media, third-party scripts and future regression monitoring. Avoid accepting a single test screenshot as proof of ongoing performance.

Measurement: list the buyer actions that need events, the environments used for validation, the consent dependencies, and the evidence required before launch. An event name in a measurement plan is not complete until a reproducible test shows that the intended action produces the intended record.

7. Define deliverables as evidence packages

For each deliverable, request four fields: the artifact, its owner, the approval point and the acceptance check. This prevents “done” from meaning a file was sent without proving that it works in the delivered system.

8. Require a comparable proposal response

Give every respondent the same response structure. Ask them to provide:

• their interpretation of the problem and the assumptions they would validate first;
• the proposed phases, artifacts and decision gates;
• the named roles responsible for strategy, content, design, development, migration and QA;
• what is included, excluded, dependent on the buyer, or delegated to another party;
• the evidence they will use to demonstrate each requirement;
• the risks they see and how those risks affect scope;
• the accounts, files and documentation transferred at handover;
• questions that must be answered before they can make a reliable commitment.

Score the evidence, ownership and assumptions separately from presentation style. A polished proposal that hides dependencies is less comparable than a plain proposal that makes uncertainty explicit.

A copy-ready B2B website redesign RFP outline

1. Project context: business, offer, audience and reason for the project.
2. Buyer problem: priority tasks, current evidence and assumptions to validate.
3. Desired outcomes: observable changes, measurement owner and constraints.
4. Scope: URL inventory, content types, systems, languages and exclusions.
5. Operating model: publishing roles, approvals, maintenance and account ownership.
6. Requirements: content, CMS, accessibility, performance, measurement and integrations.
7. Migration: retained URLs, redirect ownership, canonicals, internal links, Sitemaps and monitoring.
8. Delivery model: phases, decision gates, dependencies and change control.
9. Acceptance: artifact, owner, approval point and reproducible check for each workstream.
10. Proposal format: team, method, evidence, assumptions, exclusions, risks and handover.
11. Evaluation: the same criteria and evidence questions for every respondent.

Complete the B2B website audit before filling this outline. If you are already comparing suppliers, use the verified agency shortlist and selection framework to structure due diligence without turning the decision into a ranking contest.

Frequently asked questions

Should an RFP prescribe the CMS?

Prescribe it when the platform is a verified constraint, such as an established operating model or required integration. Otherwise, state the editing, governance, integration and ownership requirements, then ask respondents to explain how their proposed platform meets them.

How detailed should the website inventory be?

Detailed enough to expose volume, ownership and migration risk. Important URLs should have an intended treatment. Repeated templates can be grouped, but content types, integrations, languages and uncertain items should remain visible.

What belongs in acceptance criteria?

Use conditions that both parties can reproduce: an approved artifact exists, the intended page or workflow works in the agreed environment, ownership is transferred, and the verification record is stored. Avoid adjectives that have no shared test.

Should design references be included?

Yes, as evidence of a preference or interaction pattern, not as a substitute for the buyer problem. Explain what is useful in each reference so respondents do not infer that the project is only a visual imitation exercise.

Evidence note: official GOV.UK, Google Search Central, W3C and WordPress documentation was checked on 11 August 2026. Statements labeled “verified” summarize those sources. The RFP structure, evidence-package method and proposal comparison rules are CHCZ editorial viewpoints. No customer outcome, supplier ranking, commercial cost, delivery promise or personal-experience claim is asserted.

Explore the B2B Website Strategy cluster. If your team needs an independent diagnosis before it writes the brief, contact CHCZ.