Web development
Website acceptance testing before launch: checklist, evidence and go/no-go decision
Website acceptance testing should not produce an average score. It should show whether journeys, data and public access have been verified well enough to authorize launch.
This method organizes 54 checks into seven families and three go/no-go gates, followed by 15 post-launch checks. Every line connects an acceptance criterion to evidence, an owner and a blocking rule. The XLSX matrix is available without a form.
Short answer
Website acceptance testing connects every check to an expected result, evidence and a launch decision.
Useful acceptance testing is not a quick tour of a few pages before clicking “publish.” It verifies journeys, content, data, server responses and responsibilities that were defined before testing began.
Every line should include at least a check, an acceptance criterion, expected evidence, an owner, a status and a blocking rule. An untested check has not passed. A critical issue accepted verbally does not become non-blocking.
A failed or untested blocking gate results in a no-go. A non-blocking reservation must be owned, dated and accepted before a go.
Operational definition
Acceptance testing answers a more demanding question than “does the website work?”
It determines whether the agreed scope has been verified well enough to be exposed to users, search engines, business systems and internal teams. That decision cannot rest on a general impression or on the average of unrelated results.
The website redesign brief defines commitments and their acceptance criteria. Acceptance testing replays those criteria in a known environment, retains the evidence and assigns each deviation. When URLs change, the SEO migration protocol provides the URL-by-URL decision; acceptance testing verifies its execution.
| Field | Question it answers | 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” |
Controlled taxonomy
Seven families make all 54 checks readable without reducing them to a score.
Every check in the matrix belongs to one family and one decision gate. A family may still contain checks from more than one gate. This dual view helps teams prepare the required expertise, then make the go/no-go decision according to the vital function at risk.
| 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.
54 checks make up the complete pre-launch matrix. 18 representative checks are detailed in this article. 15 additional checks organize monitoring at D+1, D+7 and D+30; they are not included in the 54.
Three decision gates
A website should not enter production while any one of its three vital functions remains unproven.
Business journeys
A useful action reaches the target system from the browser.
Form, quote request, registration, download, authentication or application: success, errors, notifications and created data are checked end to end.
Security, data and recovery
The website does not expose protected information and can 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.
Public access and discoverability
People and permitted crawlers reach the intended version of the content.
HTTP status codes, redirects, canonicals, robots directives, sitemaps, structured data, languages, links and public content are verified at the final destination, including the CDN and firewall.
An average can hide a form that loses enquiries, a tracker that fires without consent or an entire website left in noindex. Twenty successful cosmetic checks cannot offset those failures.
Critical matrix
Eighteen representative checks to connect to the website’s actual scope.
The lines below are a discussion baseline, not automatic compliance. Blocking status must be decided before acceptance testing according to the project’s journeys, obligations and risks. The downloadable XLSX contains the complete protocol and evidence columns.
| 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 | 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 | Accessibility and compatibility | Priority journeys are keyboard-operable, with no trap and a visible, logical focus order. | Dated manual scenario. | Yes |
| Screen reader | 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 |
Two environments, two kinds of evidence
Acceptance testing in staging does not prove how the final destination behaves.
| 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. |
A capture without the URL, time, environment, role, test data or target result rarely documents enough to replay the check.
Failure scenarios
Three no-go scenarios should be replayed at the final destination.
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: we do 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
Separating the observed result, severity and decision prevents hidden trade-offs.
| Dimension | Allowed values | Rule |
|---|---|---|
| Test status | Passed · Failed · Not applicable · Not tested | “Not tested” can never be interpreted as passed. “Not applicable” requires justification. |
| Severity | Critical · Major · Minor | Severity describes the impact of an issue; it does not replace the agreed blocking rule. |
| Blocking | Yes · No · Conditional | The condition belongs in the acceptance criterion, not in a free-text status. |
| Decision | GO · NO-GO · GO with reservations | Every reservation includes an owner, deadline, expected fix evidence and acceptor. |
The matrix calculates an alert from statuses and blocking rules, but it does not replace the decision-makers’ sign-off. A “Conditional” check requires an explicit decision; it must not become an automatic path to go.
Acceptance-testing process
Seven passes turn the checklist into a traceable decision.
Freeze
Identify the tested version and acceptance scope.
Build, date, environment, templates, journeys, languages, browsers, devices, accounts and test data.
Assign
Separate execution, correction, acceptance and decision.
One person may hold several roles, but every responsibility remains visible.
Prepare
Create the data and conditions that make the scenario replayable.
Roles, consent states, errors, content, emails, target records and expected results.
Test
Run the scenario without rewriting the criterion after observing the result.
Record the result, environment and evidence when the check is performed.
Qualify
Distinguish failure, severity, blocking and responsibility.
A ticket connects the issue to its acceptance line and retains the decision made.
Retest
Replay the check after correction and look for side effects.
A fixed issue closes only after the expected result has been observed.
Decide
Sign off the go, no-go or reservations before the switch.
The decision names the open gates, reservations, owners, rollback and monitoring window.
Sign-off and reservations
The sign-off does not replace evidence: it summarizes its state when the decision is made.
An actionable decision includes the delivered version, environments, test period, participants, non-applicable checks, open failures, state of the three gates, accepted reservations, launch window, rollback procedure and authorized signatories.
| Element | Control question | Stop signal |
|---|---|---|
| Impact | Is the effect on users, data, visibility and operations described? | “Low” with no scenario or scope. |
| Owner | Can an identified person commit to the correction and provide evidence? | “Agency” or “client” with no name or role. |
| Deadline | Is the date compatible with the risk and monitoring period? | “After launch” with no date. |
| Retest | Are the expected result and the person who will accept it known? | Ticket closed on the fixer’s statement alone. |
D+1, D+7 and D+30
Launch ends switch acceptance, not observation of the live website.
| 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, operating costs and editorial tasks. | Compare with the baseline without automatically attributing changes to the redesign. |
Open resource
Download the XLSX website acceptance and go/no-go decision matrix.
The workbook contains instructions, a prefilled matrix, a summary with no global score, post-launch checks, controlled vocabularies and official sources. Formulas flag failed or untested blocking gates; they do not sign the decision on behalf of the project.
Pre-launch website acceptance-testing matrix
Checks, criteria, evidence, owners, severities, statuses, blocking, reservations and monitoring from D+1 to D+30.
The matrix and its public Markdown version are licensed under Creative Commons Attribution 4.0 International. Requested attribution: Edikka, with a link to this canonical page.
Deliberate limitation
This matrix does not certify a website’s compliance, security or performance.
Edikka is a website redesign agency: this resource describes a method we use and is not an independent standard. It does not replace the contract, an RGAA audit, legal review, penetration testing, the complete ASVS, risk analysis or project-specific criteria.
Performance thresholds, browsers, devices, journeys, obligations and blocking rules must be defined before testing. Successful acceptance testing proves only that the documented checks obtained the recorded results under the stated conditions.
Official sources
References used to build the control families.
- W3C · Web Content Accessibility Guidelines 2.2 — testable criteria and automated evaluation supplemented by human checks.
- DINUM · RGAA 4.1.2 — the French digital-accessibility assessment framework in force on the preparation date.
- Google Search Central · Site moves and migrations — mapping, direct redirects, internal links, sitemaps and migration monitoring.
- web.dev · Core Web Vitals thresholds — LCP, INP and CLS thresholds interpreted at the 75th percentile of visits.
- CNIL · Cookies et traceurs: que dit la loi? — prior consent, a real choice and withdrawal.
- OWASP · Application Security Verification Standard 5.0 — an open basis for specifying and verifying technical security controls.
- OpenAI · Publishers and Developers FAQ — OAI-SearchBot access to public content and referral-traffic measurement.
Sources accessed August 14, 2026. Standards, versions and policies must be rechecked for every project.
Conclusion
The quality of acceptance testing is measured by the decision it can justify.
A website ready to launch does not necessarily have zero issues. It has a known scope, open critical gates, reviewable evidence, accepted reservations and a prepared rollback. That discipline turns a launch into a controllable decision.
Edikka’s position
A launch is decided through critical gates, not an average.
A check becomes useful when the expected result, evidence, responsibility and blocking rule are known before testing.
Replay an expected result
Every scenario starts from known conditions and produces an observable result.
Retain challengeable evidence
URL, environment, time, role and evidence make the check replayable.
Sign the go or no-go
Critical gates and assigned reservations make the decision explicit.
Go further on this topic
Additional answers to clarify the key points covered in this article.
