Website Acceptance Evidence Pack: What to Deliver Before Launch

This article provides a structured approach to assembling website acceptance evidence, ensuring every requirement is traceable and verifiable before launch.

Core Principles of an Evidence Pack

A website acceptance evidence pack is not a random collection of screenshots and reports. It is a structured, requirement-linked dossier that proves the delivered website meets every agreed specification.

The core principle is traceability: each piece of evidence must correspond to a specific requirement ID, creating a clear mapping from the original contract or specification through to the final proof of implementation.

This mapping allows stakeholders—project managers, quality assurance teams, and client representatives—to quickly verify that nothing has been overlooked and that any deviations are documented and approved.

The evidence pack must cover all critical areas of the website delivery. At a minimum, this includes pages, functions, performance, security, SEO, locales, backups, training, defects, sign-off, and exit assets.

Each of these areas requires its own type of evidence, from page inventories and functional test records to performance reports and security scans.

The pack should be organized by requirement area, with each item clearly labeled and cross-referenced to the relevant requirement ID.

This structure not only facilitates the acceptance process but also serves as a valuable reference for future maintenance and audits.

Crucially, the evidence pack must be finalized before launch. It is the basis for the final acceptance and sign-off, meaning that all evidence must be collected, verified, and approved prior to the website going live.

This pre-launch completion ensures that any issues are identified and resolved before they impact end users.

It also provides a clear contractual record that the vendor has fulfilled their obligations, reducing the risk of disputes and ensuring a smooth handover.

Page and Functionality Evidence

The first major component of the evidence pack is the verification of pages and functionality. This begins with a comprehensive page inventory. For every required page, list its URL, provide a screenshot or access permissions, and note its purpose.

This inventory should cover all page types, including static pages, dynamic pages, and any landing pages created for campaigns. The goal is to demonstrate that every page specified in the requirements exists and is accessible.

Beyond the page inventory, functional test records are essential. For each module or feature—such as forms, search, payment processing, user registration, or content management—document the test cases executed and the results.

This includes both positive tests (e. g. , a form submits successfully) and negative tests (e. g. , validation errors appear when required fields are left blank).

Each test case should be linked to the relevant requirement ID, and the results should be recorded as pass, fail, or pending. Any failures must be accompanied by a defect report and a remediation plan.

Responsive design verification is another critical element. With the variety of devices and screen sizes in use, it is essential to prove that the website functions correctly across different viewports.

Capture screenshots of key pages on various devices, such as desktop, tablet, and mobile. These screenshots should be annotated to show that the layout, navigation, and content are properly displayed.

This evidence ensures that the website meets the responsive design requirements and provides a consistent user experience.

Performance and Security Evidence

Performance and security are non-negotiable aspects of a modern website. Performance evidence should include a detailed test report that documents page load times, server response times, and other relevant metrics.

These tests should be conducted under conditions that simulate real user traffic, and the results should be compared against the performance benchmarks defined in the requirements.

For example, if the specification requires a page load time of under two seconds, the report should show that this target is met. Any deviations must be explained and justified.

Security evidence is equally important. This includes a vulnerability scan report that outlines the results of automated security testing. The report should list any vulnerabilities found, their severity, and the remediation status.

Ideally, all critical and high-severity vulnerabilities should be resolved before launch. Additionally, provide proof of SSL certificate validity, such as a screenshot of the certificate details or a link to a certificate validation service.

This demonstrates that data transmitted between the user and the server is encrypted.

It is also important to document any security measures implemented, such as firewalls, intrusion detection systems, or regular security updates. While these may not be directly testable, they provide context for the security posture of the website.

The evidence pack should clearly state the scope of the security testing, including the tools used and the date of the scan, to ensure transparency and allow for future verification.

SEO and Locale Evidence

To help you organize your evidence, use the following checklist template. For each requirement, list the acceptance item, define the criteria, specify the evidence type, and track the status.

This template is a starting point. Customize it to fit your specific requirements and project. The key is to ensure that every requirement is addressed and that the evidence is clear and verifiable.

Backup, Training, and Defect Management

SEO and locale evidence proves that the website is technically discoverable and correctly localized for each target market.

This section of the acceptance pack should be organized by requirement, with each piece of evidence linked to a specific specification item.

Start with the foundational SEO elements. For each page, capture a screenshot showing the title tag and meta description as rendered in the browser or a crawler view. Verify that the robots.

txt file is accessible and correctly disallows any staging or private areas, and that the sitemap. xml is generated and submitted to search consoles.

Use a crawler tool to produce a report listing all pages with their status codes, ensuring no broken links or orphan pages. If structured data is used, run each page through a validation tool and save the output as evidence.

For locale evidence, document the URL structure for each language or region. If using subdirectories (e. g. , /en/, /fr/), verify that the correct language is served based on the URL. If using subdomains or separate domains, confirm the configuration.

For each locale, check that all user-facing text is translated accurately and that date, currency, and number formats are localized.

Capture screenshots of key pages in each language, and if translation memory tools were used, include a report showing translation consistency.

Also verify that hreflang tags are correctly implemented if multiple locales exist. Use a tool to check that each page has the appropriate hreflang annotations and that they point to the correct alternates. Save the output as evidence.

Finally, ensure that any locale-specific SEO elements, such as localized keywords in titles and meta descriptions, are in place. This may require a separate review by a native speaker or a localization specialist.

Document the review process and any issues found.

Sign-off and Exit Assets

This section documents the operational readiness of the website, including backup procedures, training provided to the client team, and the status of all known defects.

For backups, provide a detailed strategy document that includes the frequency of backups (e. g. , daily, weekly), the storage location (e. g. , offsite cloud storage), and the retention period. Crucially, include records of recovery tests.

A recovery test involves restoring a backup to a test environment and verifying that the site functions correctly. Save the test date, the person who performed it, and the outcome. If backups are automated, include a log of successful backup runs.

Training evidence should include the training materials provided, such as user manuals, video tutorials, and quick reference guides. List the topics covered, such as content management, user administration, and basic troubleshooting.

Also include attendance sheets or sign-in logs from training sessions, along with the trainer’s name and date. If training was recorded, provide links to the recordings.

Defect management is a critical part of acceptance. Maintain a defect list that tracks every issue found during testing and post-launch. For each defect, record its status: fixed, pending, or accepted.

For fixed defects, provide evidence of the fix, such as a screenshot or a link to the resolved page. For pending defects, document the expected resolution date and any workaround. For accepted defects, include a note explaining why it was accepted (e. g.

, low impact, out of scope) and who approved it. This list should be reviewed and signed off by both the client and vendor.

Formal acceptance is documented through a sign-off form and the transfer of all project assets.

This section ensures that both parties agree that the website meets the requirements and that the client has everything needed to operate and maintain the site independently.

The acceptance sign-off form should be a formal document that lists the key deliverables and states that they have been reviewed and accepted. It should be signed by authorized representatives from both the client and vendor.

Include the date of signing and any conditions or caveats. This form is the final piece of evidence that the project is complete.

The exit asset list is a comprehensive inventory of all items transferred to the client. This includes source code (with version control history), documentation (technical and user), design files (e. g.

, PSD, Figma), database dumps, third-party account credentials (e. g. , hosting, domain registrar, analytics, search console), and any other digital assets. For each asset, provide a description, location (e. g.

, repository URL, file path), and access details. Ensure that all credentials are securely transferred, perhaps via a password manager.

Finally, include the ongoing maintenance and support agreement. This document outlines the terms for post-launch support, such as response times, scope of support, and costs.

It should be signed by both parties to ensure clarity on responsibilities after the project ends.

To organize all this evidence, use a checklist template with the following fields: Requirement ID, Acceptance item, Acceptance criteria, Evidence type (screenshot/report/link), Status (pass/fail/pending), and Notes.

This template helps map each requirement to its evidence and status, making the acceptance process transparent and auditable.

This template can be expanded to cover all requirements. By systematically collecting and organizing evidence, you can ensure a smooth acceptance process and avoid disputes.

Next step

Download the acceptance evidence pack template to start organizing your project evidence.