Website Delivery Evidence Pack for Launch Acceptance

A technical runbook for assembling a Website Delivery Evidence Pack for Launch Acceptance, covering scope definition, code and configuration evidence, third-party access verification, and pre-launch performance and SEO checks.

Define the Evidence Pack Scope and Acceptance Criteria

Start by defining the exact artifacts the pack must contain. List every item that will be reviewed before launch: the code commit hash, configuration files, DNS records, third-party account details, backup files, performance reports, and SEO audit results.

Without a defined scope, reviewers will request inconsistent items and the launch will stall.

Set measurable acceptance criteria that must be true for approval. For example, a criterion might be: the production site returns HTTP 200 for all canonical URLs, and the homepage loads in under three seconds on a simulated mobile connection.

These numbers are illustrative; your team must set thresholds based on business needs.

Define who verifies each item. The launch acceptance team typically includes a developer, a DevOps engineer, a marketing lead, and a project manager. Each person signs off on the parts they own.

The pack is not complete until every criterion has a pass or a documented exception with a mitigation plan.

A failure branch here is missing evidence. If a required artifact is absent, the pack is rejected and the launch is blocked. The rollback is to postpone the launch until the evidence is gathered.

Record every decision in the verification record: who approved what, when, and what the evidence was.

Collect Code, Configuration, and Domain Evidence

Gather the exact code commit that will be deployed. Record the commit hash, branch name, and repository URL. For example, run `git rev-parse HEAD` to capture the current commit.

This hash is the fingerprint of the code; any change after this point means the pack is stale.

Collect environment-specific configuration files for production: database connection strings, API keys, caching settings, and feature flags. These files must match the approved release.

A common failure is a config file that points to a staging database; the signal is a connection error in the logs. The rollback is to restore the previous config from version control and re-run the deployment.

Verify domain evidence: DNS records and SSL certificates. Confirm that the domain’s A, CNAME, and TXT records point to the correct hosting provider. Use `dig` or an online DNS checker to confirm.

For SSL, check that the certificate is valid and covers the domain and its subdomains. A failure signal is a certificate mismatch warning in the browser; the rollback is to reissue the certificate and update DNS if needed.

Document the backup strategy. The pack must include a recent backup of the database and files, plus a tested restore procedure. If the backup is missing or the restore fails, the launch is not safe.

The failure branch is a failed restore test; the rollback is to fix the backup process and retest.

Verify Third-Party Accounts and Access Permissions

List every third-party service the site depends on: content delivery network (CDN), analytics, payment gateway, email service, and marketing automation tools.

For each, confirm the account is active, billing is current, and configuration matches the production environment.

Check access permissions. Each team member should have the minimum level of access needed for their role. For example, a developer might have deploy access, but a marketing intern should only have analytics view access.

Use a spreadsheet or an access management tool to record who has access to what. A failure signal is an account with admin rights that no longer needs them; the rollback is to revoke that access immediately.

Verify that API keys and webhooks are correctly set. For example, the payment gateway’s webhook URL should point to the production endpoint. Test a transaction in sandbox mode to confirm the integration works.

If the webhook fails, the signal is a failed notification in the gateway’s logs; the rollback is to correct the URL and retest.

Document the account owner and recovery email for each service. If a service is owned by a former employee, transfer ownership before launch.

The failure branch is a locked account due to a forgotten password; the rollback is to use the recovery process and update credentials in the pack.

Run Pre-Launch Performance and SEO Checks

Performance checks verify that the site loads quickly and handles traffic. Use tools like Lighthouse or WebPageTest to measure load time, time to first byte, and largest contentful paint. Run these tests on a production-like environment, not localhost.

A failure signal is a load time above your threshold; the rollback is to optimize images, enable caching, or upgrade hosting.

Check response codes for all key pages. Use a crawler or a script to fetch each URL and confirm it returns 200. A 404 or 500 error is a failure; the rollback is to fix the routing or server configuration and re-test.

SEO checks ensure the site is discoverable. Verify that meta titles and descriptions exist for all pages, the sitemap is generated and submitted to search engines, and robots. txt does not block important pages. Use a tool like Screaming Frog to audit.

A failure signal is a missing meta tag or a sitemap that references a 404; the rollback is to fix the content and regenerate the sitemap.

Record all results in the verification record. Include the test date, the tool used, the results, and any actions taken. This record is the proof that the site meets the acceptance criteria. If any check fails, document the exception and the mitigation plan.

The pack is complete only when every item has a pass or a documented exception.

Validate Tracking and Analytics Implementation

Your first job is to prove that analytics and tag management scripts fire correctly on the production environment. Start by listing every tracking tool you intend to use, such as Google Analytics, Google Tag Manager, or a privacy-focused alternative.

For each tool, record the exact version and the container or property ID. This version and environment detail is the precondition for every later check.

Open the site in a clean browser profile and load the page where the tracking script should appear. Use the browser’s developer tools to inspect the network requests. Confirm that the expected request to the analytics endpoint fires on page load.

For a tag manager, verify that the container loads and that the tags inside it are not blocked by a content security policy.

Next, trigger the key events that matter for your business. If you track form submissions, submit a test form. If you track outbound clicks, click a link to an external domain.

For each event, capture a screenshot of the network request or the tag assistant output. Save this as evidence. The expected result is that every event appears in the analytics debug view or in the network log with the correct parameters.

If a script does not fire, do not proceed. Record the failure branch: note the exact page, the browser, and the error message. Fix the configuration, clear the cache, and retest.

Only when all tracking events fire consistently across the main pages can you mark this section complete. The evidence for this section is the set of network logs, event screenshots, and a checklist showing each tool and event verified.

Confirm Backup and Rollback Readiness

Before launch, you must have a full backup of the current production site. This includes the database, all files, and the configuration that defines the environment. Document the backup location, the timestamp, and the person who created it.

A backup that is not tested is not a backup.

Write a rollback plan that lists the exact steps to revert to the previous version. This plan must include the command to restore the database, the command to replace the application files, and the command to clear any caches.

For example, if you use a typical Linux server with a database dump, the restore command might be `mysql -u user -p database < backup. sql`. Label this as an illustrative command, not a universal one.

Test the rollback in a staging environment that mirrors production. Run through the entire rollback procedure and confirm that the site returns to the previous state. Record the time it took and any issues you encountered.

This drill record is part of the evidence pack. The expected result is that the rollback completes without data loss and the site becomes accessible again.

If the rollback test fails, do not launch. Investigate the cause, fix the plan, and rerun the drill. Only when the rollback works in staging can you consider it ready.

The evidence for this section is the backup manifest, the rollback plan document, and the drill log with timestamps and outcomes.

Compile the Evidence Pack with a Unique Cover and Sign-Off

Now assemble all the evidence you have collected into a single, indexed document. This is the Website Delivery Evidence Pack for Launch Acceptance.

Create a unique cover page that includes the project name, the launch date, the version of the site, and the names of the team members responsible. The cover must be unique to this launch, not a generic template.

The body of the pack should follow the order of your launch checklist. Include the tracking validation evidence, the backup and rollback records, and any other required items such as performance test results, SEO checks, and access permissions.

For each item, state what was tested, how it was tested, and the result. Use screenshots and logs as supporting evidence.

Number every page and include a table of contents. This makes the pack easy to navigate for an approver who may only have a few minutes. The index should list each evidence item with its page number and a short description.

Finally, obtain formal sign-off from the launch approvers. This is not a casual email. It is a formal sign-off on the cover page or a separate sign-off sheet.

Each approver must confirm that they have reviewed the evidence and that the site meets the acceptance criteria. The sign-off must include the approver’s name, role, date, and signature. Without this sign-off, the pack is incomplete.

The evidence for this section is the compiled pack itself, with its unique cover, index, and the signed approval page.

Handle Post-Launch Verification and Failure Signals

Launch is not the end. Immediately after going live, run a set of post-launch checks to confirm the site is functioning as expected. These checks should be defined before launch and included in the evidence pack.

Typical checks include loading the homepage, verifying a key transaction, and confirming that tracking events still fire.

Define the failure signals that indicate a problem. These are specific, observable conditions that trigger an escalation. For example, if the site returns a 500 error on the homepage, or if the analytics events stop firing, or if the database connection fails.

Write these signals in the evidence pack so that anyone on the team can recognize them.

When a failure signal appears, follow the escalation path. The first step is to notify the on-call engineer. The second step is to assess the severity. If the issue is critical, execute the rollback plan you tested earlier.

If the issue is minor, you may choose to fix it in place, but you must document the decision.

Record every post-launch check and any incident in a log. This log becomes part of the evidence pack for future reference. The expected result is that the site remains stable and that any issues are handled quickly and transparently.

A Website Delivery Evidence Pack for Launch Acceptance is only complete when it includes this post-launch plan. It turns a one-time launch into a controlled process with clear criteria for success and failure.

By following this runbook, you give your approvers the confidence to sign off and your team the ability to respond when something goes wrong.

Next step

Ready to build your own evidence pack? Contact SHMLANG for a bilingual website delivery checklist tailored to your stack.