# Website acceptance testing before launch: checklist, evidence and go/no-go decision

Scheduled for publication by Edikka on August 18, 2026.  
Canonical page: https://www.edikka.com/en/insights/web-development/website-acceptance-testing-before-launch  
XLSX matrix: https://www.edikka.com/docbd/data/website-acceptance-testing-before-launch-matrix.xlsx  
License: Creative Commons Attribution 4.0 International — https://creativecommons.org/licenses/by/4.0/  
License URL: https://creativecommons.org/licenses/by/4.0/

## Short answer

Website acceptance testing connects every check to an expected result, evidence and a launch decision.

An actionable line contains at least:

1. the check to run;
2. the observable acceptance criterion;
3. the expected evidence;
4. the owner;
5. the test status;
6. the blocking rule.

An untested check has not passed. A failed or untested blocking gate results in a no-go. A non-blocking reservation must be owned, dated and accepted before a go.

## The six minimum fields

| Field | Question | Insufficient wording |
|---|---|---|
| Check | What exactly are we testing? | “Check the form” |
| Acceptance criterion | Which observable result validates the check? | “The form works” |
| Evidence | Which record allows the result to be replayed or challenged? | “Tested by the agency” |
| Owner | Who runs, fixes and accepts the check? | “The project team” |
| Status | Did it pass, fail, not apply or remain untested? | “Almost done” |
| Blocking | Does failure prevent launch? | “Review after launch” |

The website redesign brief defines commitments and acceptance criteria. Acceptance testing replays those criteria in a known environment, retains evidence and assigns deviations. When URLs change, the SEO migration protocol provides the URL-by-URL decision; acceptance testing verifies its execution.

## The seven control families

Every check in the matrix belongs to one family and one decision gate. A family may still contain checks from more than one gate.

| Family | Checks | Scope covered | Distribution by gate |
|---|---:|---|---|
| Content, navigation and administration | 8 | Pages, navigation, search, public resources and editorial publishing. | 7 Business journeys · 1 Public access and discoverability |
| Functional journeys and integrations | 6 | Forms, notifications, CRM, accounts and exchanges with target systems. | 6 Business journeys |
| Accessibility and compatibility | 5 | Responsive behavior, browsers, keyboard, screen reader, reflow and zoom. | 5 Business journeys |
| Performance and observability | 3 | Reproducible thresholds, blocking regressions, logs and critical alerts. | 2 Business journeys · 1 Security, data and recovery |
| Security, data, consent and recovery | 15 | Transport, access, data, consent, obligations, backup and rollback. | 15 Security, data and recovery |
| SEO, GEO and public access | 15 | Migration, indexability, crawling, languages, metadata and tool access. | 15 Public access and discoverability |
| Measurement and attribution | 2 | Conversion events, permitted parameters and attribution continuity. | 2 Public access and discoverability |
| **Pre-launch total** | **54** | Every line belongs to one family and one gate. | **20 Business journeys · 16 Security, data and recovery · 18 Public access and discoverability** |

**The number of checks reflects the technical surface to cover, not their weight in the decision:** blocking is determined by the gates, not by volume.

The three published numbers do not describe the same scope: **54** checks make up the complete pre-launch matrix, **18** representative checks are detailed in the article and **15** additional checks organize monitoring at D+1, D+7 and D+30. The 15 post-launch checks are not included in the 54.

## Three go/no-go gates

### 1. Business journeys

A useful action must reach the target system from the browser: form, quote request, registration, download, authentication, payment or application. Success, errors, notifications and created data are checked end to end.

### 2. Security, data and recovery

The website must not expose protected information and must be able to return to a safe state. Access, roles, test data, trackers, backup, restore and rollback are verified across the agreed scope. Acceptance testing does not replace a security audit.

### 3. Public access and discoverability

People and permitted crawlers must reach the intended version of the content. HTTP status codes, redirects, canonicals, robots directives, sitemaps, structured data, languages, links and public content are checked at the final destination, including the CDN and firewall.

An average cannot offset a form that loses enquiries, a tracker that fires without consent or an entire website left in `noindex`.

## Critical pre-launch matrix

Blocking status must be decided before acceptance testing according to the project’s journeys, obligations and risks.

| Area | Family | Observable acceptance criterion | Minimum evidence | Indicative blocking |
|---|---|---|---|---|
| Critical pages | Content, navigation and administration | Home, offer, contact, legal and priority-journey pages respond without a 5xx error or loop. | Dated crawl and HTTP responses. | Yes |
| Navigation | Content, navigation and administration | Primary navigation, footer, breadcrumbs and links in declared critical journeys reach their final destination. | Link crawl and human review. | Conditional |
| Primary form | Functional journeys and integrations | A valid submission creates the expected data, confirms the action and triggers the planned notifications. | Time-stamped scenario and visible record in the target system. | Yes |
| [Form errors](https://www.edikka.com/en/insights/web-development/accessible-forms-lost-leads) | Functional journeys and integrations | In a declared critical journey, every error is announced, connected to the relevant field and retains previously entered valid data. | Keyboard and screen-reader capture or video. | Yes |
| Integrations | Functional journeys and integrations | Declared critical integrations — CRM, email, recruitment, payment or API — receive the agreed fields, formats and consent data. | Test log and target record. | Conditional |
| [Keyboard and focus](https://www.edikka.com/en/insights/web-development/real-accessibility-audit-automated-tools-miss) | Accessibility and compatibility | Priority journeys are keyboard-operable, with no trap and a visible, logical focus order. | Dated manual scenario. | Yes |
| [Screen reader](https://www.edikka.com/en/insights/web-development/real-accessibility-audit-automated-tools-miss) | Accessibility and compatibility | Headings, landmarks, controls, fields, states and critical messages are named and announced usefully. | Test report with the environment identified. | Yes |
| Responsive behavior | Accessibility and compatibility | Priority templates and journeys remain readable and operable at the agreed widths and zoom levels. | Device-browser matrix and targeted captures. | Conditional |
| Performance | Performance and observability | Contractual pages, conditions and thresholds are met; laboratory results are not presented as field data. | Reproducible report and measurement context. | Conditional |
| Consent | Security, data, consent and recovery | No tracker requiring consent is read or stored before a choice; accept, refuse and withdraw remain accessible. | Network and storage inspection before and after each choice. | Yes |
| Access and roles | Security, data, consent and recovery | Each role can access only the planned content, data and actions. | Role-based scenarios and deviation log. | Yes |
| Backup and rollback | Security, data, consent and recovery | The backup, restore point, decision-maker and rollback procedure are identified and tested across the agreed scope. | Test log, duration and observed result. | Yes |
| Redirects | SEO, GEO and public access | Every critical URL receives the approved decision and reaches its final destination directly, without an avoidable chain. | Approved matrix and post-switch crawl. | Yes |
| Indexability | SEO, GEO and public access | Pages intended for indexing return 200, expose the expected canonical and retain no staging restriction. | Final HTML, HTTP headers and URL test. | Yes |
| Crawlers and AI | SEO, GEO and public access | `robots.txt`, the CDN and firewall apply the decided policy to Googlebot, Bingbot and OAI-SearchBot on public pages. | User-agent requests and final responses. | Conditional |
| Structured data | SEO, GEO and public access | JSON-LD is valid, consistent with visible content and does not reference missing resources. | Validation, graph extraction and human review. | Conditional |
| Measurement | Measurement and attribution | Declared critical events fire once with the expected parameters and honor the consent choice. | Analytics debugger and visible event. | Conditional |
| Administration | Content, navigation and administration | An authorized editor can create, preview, correct and publish a representative content item without technical intervention. | User test and content published, then restored. | Conditional |

## Staging and production do not prove the same things

| In staging | Must be replayed in production | Why |
|---|---|---|
| Templates, content, components, roles, errors, responsive behavior and business scenarios using test data. | DNS, TLS, cache, CDN, firewall, HTTP responses, redirects and canonical domain. | These layers depend on the final infrastructure. |
| Tagging plan, simulated consent and events in debug mode. | Live trackers, third-party domains, deduplication and reception in the production property. | Identifiers and policies may differ. |
| Planned `robots.txt` and metadata. | No residual `noindex`, final robots policy, public sitemap and access for permitted crawlers. | A staging restriction is sometimes deployed with the website. |
| Targeted load tests and laboratory measurements. | Response time, errors, cold and warm cache, and future field-data collection. | Traffic, network and infrastructure change the result. |

Final evidence must be dated and located: URL, time, environment, role, test data and target result.

## Three no-go scenarios to replay

In the Edikka method, these scenarios are verified after the technical switch because a functioning staging environment does not demonstrate the behavior of the final domain. They are not presented as the most frequent incidents: Edikka does not yet publish consolidated counts that would support that claim.

| Scenario | Misleading observation | Evidence to retain | Decision |
|---|---|---|---|
| Residual staging restriction | The page loads in an already authorized browser but retains `noindex`, authentication or crawler filtering. | Dated final HTML and response, then requests using permitted user agents through the CDN and firewall. | NO-GO for pages intended to be public. |
| Form confirmation without created data | The interface reports success, but no usable enquiry appears in the CRM or target system. | Time-stamped submission, test identifier, target record and received notifications. | NO-GO when this is a critical business journey. |
| Tracker active before choice | The banner is visible, but a tracker requiring consent has already been called, read or stored. | Network and storage inspection before choice, after refusal, after acceptance and after withdrawal. | NO-GO when the tracker requires prior consent. |

## Controlled vocabulary

| Dimension | Allowed values | Rule |
|---|---|---|
| Status | **Passed / Failed / Not applicable / Not tested** | “Not tested” never means passed. “Not applicable” requires justification. |
| Severity | **Critical / Major / Minor** | Severity describes impact; it does not replace the agreed blocking rule. |
| Blocking | **Yes / No / Conditional** | The condition belongs in the acceptance criterion, never in a free-text status. |
| Decision | **GO / NO-GO / GO with reservations** | Every reservation includes an owner, deadline, expected evidence and acceptor. |

The matrix calculates an alert, but it does not sign the decision on behalf of the project’s decision-makers.

## Seven-pass process

1. **Freeze** the tested version, environment and scope.
2. **Assign** execution, correction, acceptance and decision.
3. **Prepare** accounts, data, error states and expected results.
4. **Test** without changing the criterion after observing the result.
5. **Qualify** failure, severity, blocking and responsibility separately.
6. **Retest** after correction and look for side effects.
7. **Decide** the go, no-go or reservations before the switch.

## Sign-off and reservations

An actionable decision includes:

- the delivered version and environments;
- the test period and participants;
- non-applicable checks;
- open failures and the state of the three gates;
- accepted reservations, each with an owner and date;
- the launch window;
- the rollback procedure;
- authorized signatories.

An acceptable reservation documents its impact, an identified owner, a deadline, the expected retest result and the person authorized to accept it.

## Post-launch checks

| Due | Priority checks | Associated decision |
|---|---|---|
| D+1 | Server errors, live forms, email, CRM, consent, analytics, critical redirects, indexability, sitemap, cache and backup. | Fix immediately or trigger the planned rollback. |
| D+7 | Logs, 404s, redirect chains, events, internal search, team feedback, index coverage and open reservations. | Prioritize observed deviations and close retested reservations. |
| D+30 | Available field data, comparable conversions, queries and pages, stability, incidents and operating costs. | Compare with the baseline without automatically attributing changes to the redesign. |

## Deliberate limitation

Edikka is a website redesign agency. This resource describes a method we use and is not an independent standard.

The matrix does not certify a website’s compliance, security or performance. It does not replace the contract, an RGAA audit, legal review, penetration testing, the complete ASVS, risk analysis or project-specific criteria.

Successful acceptance testing proves only that the documented checks obtained the recorded results under the stated conditions.

## License and reuse

The XLSX matrix and this Markdown version are licensed under Creative Commons Attribution 4.0 International. They may be adapted and redistributed, including commercially, provided that Edikka is credited and the canonical page of this article is linked.

## Official sources

Sources accessed August 14, 2026.

- W3C, Web Content Accessibility Guidelines 2.2: https://www.w3.org/TR/WCAG22/
- DINUM, RGAA 4.1.2: https://accessibilite.numerique.gouv.fr/
- Google Search Central, Site moves and migrations: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
- web.dev, Core Web Vitals thresholds: https://web.dev/articles/defining-core-web-vitals-thresholds
- CNIL, Cookies et traceurs : que dit la loi ?: https://www.cnil.fr/fr/cookies-et-autres-traceurs/que-dit-la-loi
- OWASP, Application Security Verification Standard 5.0: https://owasp.org/www-project-application-security-verification-standard/
- OpenAI, Publishers and Developers FAQ: https://help.openai.com/en/articles/12627856-publishers-and-developers-faq

## Edikka resources

- Website redesign service: https://www.edikka.com/en/website-redesign
- B2B website redesign brief: https://www.edikka.com/en/insights/digital-strategy/b2b-website-redesign-brief
- SEO migration protocol: https://www.edikka.com/en/insights/seo/seo-migration-website-redesign