# B2B website redesign brief: complete template and acceptance criteria

Published by Edikka on 11 August 2026.  
Canonical page: https://www.edikka.com/en/insights/digital-strategy/b2b-website-redesign-brief  
Editable DOCX: https://www.edikka.com/docbd/data/b2b-website-redesign-brief.docx  
Licence: Creative Commons Attribution 4.0 International — https://creativecommons.org/licenses/by/4.0/

## Short answer

A useful website redesign brief makes every material commitment verifiable. For each important requirement, document five fields:

1. the expected outcome;
2. the acceptance criterion;
3. the expected evidence;
4. the owner;
5. whether the requirement blocks launch.

This structure makes proposals easier to compare, reduces ambiguity during delivery and turns acceptance into a documented decision rather than an impression.

## What the organisation decides and what the provider recommends

| The organisation decides | The provider recommends | The proposal must state |
|---|---|---|
| Business objectives, priority audiences, operational constraints, internal owners, budget envelope and fixed deadlines. | Architecture, journeys, design method, technical foundation, measurement approach and migration sequence. | Assumptions, inclusions, exclusions, dependencies, deliverables, approvals, ownership, maintenance and change conditions. |

Do not lock in a CMS without a demonstrated constraint. Describe administration needs, roles, integrations, portability, performance and security, then ask each provider to justify the proposed solution.

## Requirement, acceptance, evidence, owner and blocking status

| Requirement | Acceptance criterion | Expected evidence | Owner | Blocking |
|---|---|---|---|---|
| Lead form | A valid submission creates the expected contact, displays a clear confirmation and triggers the planned notification. Errors are announced and associated with their fields. | Time-stamped acceptance scenarios and the test contact visible in the target system. | Agency + CRM owner | Yes |
| Administration | An authorised editor can create, preview, correct and publish a representative content item without technical intervention. | Back-office user test and delivered operating guide. | Agency + content editor | Yes |
| Content and templates | For every template declared priority and launch-critical, the agreed required fields, display rules, evidence, call to action, editorial owner and update rule are present. | Template inventory, integrated test content and editorial review of representative pages. | Agency + content owners | Conditional |
| Internal search | When internal search belongs to a declared critical journey, the agreed query set returns relevant results, the empty state offers a useful next step and the journey remains keyboard-operable. | Dated query set, observed results, defects and confirmation after correction. | Agency + subject owner | Conditional |
| Accessibility | Scope, standard and version, sample, testing method and target level are defined before acceptance. Any defect classified as blocking by the agreed protocol prevents launch until corrected or covered by a documented exception. | Test report, classified defects, corrections and confirmation testing. | Named assessor | Conditional |
| Performance | Pages, test conditions and contractual thresholds are fixed. Thresholds that determine go/no-go are named before measurement. A single Lighthouse score is not the only evidence. | Repeatable report, stated environment and field data once sufficient data exists. | Agency | Conditional |
| SEO migration | Every critical legacy URL receives a documented decision: retain, direct 301/308, consolidate or return 404/410. | Approved matrix, acceptance crawl, HTTP status and final destination. | Agency + content owner | Yes |
| Measurement and consent | Authorised events are received with the expected parameters. No tracker that requires consent fires before the user’s choice. | Measurement plan, test log and browser inspection before and after consent. | Agency + DPO or adviser | Yes |
| Security and recovery | Roles, backups, recovery time, maximum accepted data loss and incident procedure are defined, then an agreed recovery scenario is replayed. Blocking applies to scenarios declared critical before acceptance. | Recovery test log, observed duration, gaps, corrections and escalation owners. | Host + agency + security owner | Conditional |
| Ownership and portability | Repositories, accounts, data, domains, licences and agreed deliverables are owned or transferable under the written proposal. | Handover inventory, tested access, open exports and a transfer procedure tested on the agreed scope. | Client leadership + agency | Yes |

The “Blocking” field uses a controlled vocabulary: **Yes / No / Conditional**. When the status is Conditional, write the condition in the acceptance criterion. “No” means the requirement remains testable but failure does not prevent launch.

## The eight sections of the brief

### 1. Context and current state

- organisation, offers, markets and languages;
- the current website’s role and reasons for redesign;
- technology, hosting, connected tools and known debt;
- governance, available access and known constraints.

### 2. Objectives and baseline

- desired outcomes, ordered by priority;
- definition of qualified enquiries and other conversions;
- current data, calculation method, period and seasonality;
- the decision each indicator will support.

### 3. Audiences and B2B journeys

- decision-makers, users, influencers and other audiences;
- research context, maturity and objections;
- information and evidence required;
- the next action for each journey.

### 4. Content and scope

- pages to retain, consolidate, remove, rewrite or create;
- templates, mandatory fields and content volumes;
- languages, media, authors, evidence and approvals;
- migration and ongoing editorial ownership.

### 5. Functions and integrations

- business scenarios rather than module names;
- users, inputs, outputs, errors and permissions;
- CRM, ERP, recruitment, newsletter, SSO and other systems;
- administration roles, export and portability.

### 6. Quality and compliance

- UX tasks and representative journeys;
- accessibility standard, version, scope, sample and human tests;
- performance pages, conditions, metrics and thresholds;
- compatibility, security, privacy and blocking defects.

If a national framework applies, include a review clause for standards that may change before delivery. For French projects extending into 2027, this may include the announced RGAA 5 transition, without presuming that it applies to the project.

### 7. Visibility and measurement

- URL inventory and URL-by-URL migration decisions;
- canonicals, hreflang, internal links, metadata and sitemaps;
- structured data, crawler access and AI citability conditions;
- authorised events, consent and dashboards.

### 8. Delivery and post-launch

- milestones, deliverables, owners and approvals;
- client availability and response times;
- acceptance, defect handling and go/no-go authority;
- ownership, documentation, maintenance and portability.

## Baseline before launch

| Dimension | State to preserve | Limitation to document |
|---|---|---|
| Commercial | Forms started and submitted, meetings, downloads, identifiable calls and manual lead qualification. | Definition, consent, duplicates, seasonality and unattributable activity. |
| Content | Pages, templates, owners, dates, evidence, inbound links, usage and migration decisions. | Incomplete inventory, missing data or off-site content. |
| Search | Impressions, clicks, queries, pages, indexability, canonicals, links and sitemaps. | Window, aggregation, reporting delay and canonical changes. |
| Experience and quality | Tested journeys, known friction, available field performance, accessibility defects and incidents. | Sample, devices, network, insufficient traffic and tests that cannot be replayed. |

## Compare agencies without a false total score

Resolve three pass/fail gates before detailed comparison:

| Gate | Minimum expected answer | Stop signal |
|---|---|---|
| Ownership and portability | Who owns code, content, domains, accounts, data and access, and in which formats they are handed over. | Undisclosed dependency or essential access held without a transfer procedure. |
| Acceptance and migration | Acceptance criteria, responsibilities, URL matrix, test environment, defect handling and the launch decision. | Launch treated as a visual check or migration deferred until after development. |
| Scope and responsibilities | Deliverables, actual team, client dependencies, exclusions, options and change procedure. | Broad wording that cannot be attached to a deliverable or owner. |

Edikka is a website redesign agency. This framework is therefore not an independent agency ranking. Edikka’s public offer documents its deliverable families, method, accessible projects and first-conversation process. Budget, named team, detailed schedule, acceptance thresholds, responsibilities and exclusions belong in each proposal.

## Five requests to reframe

| Fragile request | More useful wording |
|---|---|
| Lighthouse 100 everywhere | Define pages, devices, conditions, metrics, thresholds and evidence required for real use. |
| First position in Google | Require controllable SEO deliverables and checks; no provider controls a ranking. |
| Cited by AI systems | Require technical access, sourced answers, evidence, dated monitoring and attribution limits; no citation is guaranteed. |
| Pixel-perfect design before discovery | Set objectives, content, components, brand principles, journeys and approval stages. |
| Redirect every old URL to the homepage | Decide URL by URL according to intent equivalence: retain, redirect, consolidate or remove correctly. |

## Deliberate limitation

This template is not a contract, a legal audit or a guarantee of results. Applicable obligations depend on the organisation, audiences, data, services and jurisdictions concerned. Competent specialists must validate them before they are incorporated into contractual documents.

The example criteria support repeatable acceptance. They do not prove a before-and-after gain and do not guarantee conversion, search ranking or citation by an AI service.

## Reuse

The DOCX template and this Markdown version are released under the Creative Commons Attribution 4.0 International licence. Adaptation and commercial redistribution are permitted provided Edikka is credited and the canonical article is linked.

Suggested attribution: “B2B website redesign brief — Edikka, 2026 — https://www.edikka.com/en/insights/digital-strategy/b2b-website-redesign-brief”.

## Sources

- France Num, “Bâtir le cahier des charges du site internet de son entreprise” (French): https://www.francenum.gouv.fr/guides-et-conseils/developpement-commercial/site-web/batir-le-cahier-des-charges-du-site-internet
- France Num, “Modèles de cahiers des charges pour un site internet d’entreprise” (French): https://www.francenum.gouv.fr/guides-et-conseils/developpement-commercial/site-web/modeles-de-cahiers-des-charges-pour-un-site
- Google Search Central, “Site moves and migrations”: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
- W3C, “Web Content Accessibility Guidelines (WCAG) 2.2”: https://www.w3.org/TR/WCAG22/
- DINUM, “Une nouvelle version du RGAA prévue fin 2026” (French): https://www.numerique.gouv.fr/actualites/nouvelle-version-rgaa-2026/
- European Data Protection Board, “Guidelines 05/2020 on consent under Regulation 2016/679”: https://www.edpb.europa.eu/documents/guideline/guidelines-052020-on-consent-under-regulation-2016679_en

## Related Edikka resources

- B2B website redesign: https://www.edikka.com/en/website-redesign
- SEO migration protocol: https://www.edikka.com/en/insights/seo/seo-migration-website-redesign
- Editable DOCX: https://www.edikka.com/docbd/data/b2b-website-redesign-brief.docx