# Client website launch checklist for AI-built sites

Use this record for the exact release candidate you intend to launch. Replace the examples with your project details. Do not put passwords, API keys, recovery codes, tokens, or other secret values in this file.

## 1. Identify the release

- Project:
- Candidate URL:
- Candidate version, snapshot, or commit:
- Production hostname:
- Planned launch date, time, and time zone:
- Agency deployment owner:
- Client approver:
- Rollback decision owner:
- Support contact during the launch window:

## 2. Track every gate with evidence

Use these statuses: `PASS`, `HOLD`, `PASS WITH KNOWN ITEM`, or `NOT APPLICABLE`.

| Gate | Owner | Evidence location | Status | Re-test trigger |
|---|---|---|---|---|
| Truth |  |  |  | Any copy, image, price, claim, or metadata change |
| Journey |  |  |  | Any layout, component, navigation, or form change |
| Transaction |  |  |  | Any form, integration, consent, or tracking change |
| Control |  |  |  | Any deploy, domain, access, secret, or runtime change |
| Discovery |  |  |  | Any URL, redirect, canonical, robots, or sitemap change |

## Gate 1: Truth

- [ ] Final copy matches the approved source.
- [ ] Names, titles, addresses, phone numbers, hours, prices, dates, and offer terms are current.
- [ ] Claims generated or revised with AI have a named factual source or client approval.
- [ ] Testimonials, logos, photographs, fonts, and downloads have documented permission for this use.
- [ ] Placeholder copy, invented statistics, unapproved testimonials, and draft images are absent.
- [ ] Page titles, descriptions, social previews, and structured data match the visible page.
- [ ] Privacy, cookie, terms, disclaimers, and regulated claims have the appropriate client or specialist approval.
- [ ] One person has given written approval for the exact candidate and known exceptions are listed below.

Known content exceptions:

## Gate 2: Journey

- [ ] Primary navigation, footer links, logo link, and custom 404 route work.
- [ ] The primary visitor journey is complete on a phone and desktop browser.
- [ ] Important menus, dialogs, and forms fit inside the viewport at narrow widths.
- [ ] Keyboard-only navigation reaches every important control in a logical order with visible focus.
- [ ] Headings, landmarks, labels, alternatives, error messages, and zoom behavior received a manual review.
- [ ] Automated accessibility findings were reviewed by a person, not accepted as proof by score alone.
- [ ] Images load at useful sizes and do not obscure copy or controls.
- [ ] A lab performance check was recorded on the homepage and the heaviest key template.
- [ ] Console and network failures were reviewed during the key journey.

Devices, browsers, widths, and assistive technology checked:

## Gate 3: Transaction

- [ ] Every launch-critical form was submitted on the candidate and the destination was confirmed.
- [ ] Required fields, invalid input, failure state, success state, and duplicate submission behavior were checked.
- [ ] Booking, checkout, donation, account, download, or other critical actions were completed where applicable.
- [ ] Phone, email, map, and external booking links point to the approved destination.
- [ ] CRM, mailbox, database, webhook, and notification ownership is documented without copying secret values.
- [ ] Consent choices produce the intended analytics and marketing behavior.
- [ ] Each key analytics event was triggered and observed in the intended property or debugging view.
- [ ] Test records are clearly labeled and a cleanup owner is named.

Test record IDs or non-sensitive evidence links:

## Gate 4: Control

- [ ] The exact candidate version is recorded and ordinary edits are paused during final verification.
- [ ] A new AI request cannot silently change the candidate without reopening affected gates.
- [ ] Client and agency roles were tested with the intended accounts, including one restricted action.
- [ ] Task instructions are not being treated as technical permissions.
- [ ] Secrets are stored through the approved secret-management path, not in prompts, source, screenshots, or project notes.
- [ ] Temporary users, debug routes, sample data, test integrations, and unnecessary admin access are removed or restricted.
- [ ] Recovery covers site files and configuration, and external systems have separate recovery owners where needed.
- [ ] The rollback trigger, decision owner, and rollback procedure are written down.
- [ ] The agency has preserved any work that a restore could overwrite.

Rollback trigger and procedure:

## Gate 5: Discovery

- [ ] Production HTTPS works without mixed-content warnings.
- [ ] The preferred hostname is consistent in canonicals, generated links, callbacks, cookies, and social metadata.
- [ ] Internal links use production destinations.
- [ ] Old URLs map to relevant new destinations when this is a redesign or migration.
- [ ] Redirects were tested to their final destinations without accidental chains.
- [ ] Production `robots.txt` and `noindex` rules match the launch decision.
- [ ] The sitemap contains the intended canonical production URLs and no staging URLs.
- [ ] Search Console ownership and sitemap submission responsibility are assigned where relevant.
- [ ] Social cards were previewed with the actual title, description, and image.
- [ ] Staging and preview environments are not being presented as the canonical public site.

Migration notes and intentionally removed URLs:

## 3. Launch-day production pass

- [ ] Record final approval, time, approver, candidate version, and known exceptions.
- [ ] Make the planned deployment or domain change through the named owner.
- [ ] Open the production hostname in a fresh browser session.
- [ ] Check homepage, primary landing page, contact page, and one invalid URL.
- [ ] Repeat the primary conversion with a clearly labeled production test.
- [ ] Confirm the destination received the result.
- [ ] Confirm the key analytics event in the intended production property.
- [ ] Re-test redirects, indexing controls, sitemap, canonical, and social metadata.
- [ ] Inspect production logs and monitoring for new errors without copying sensitive values into this record.
- [ ] Record `SHIP`, `SHIP WITH KNOWN ITEMS`, or `ROLL BACK` below.

Decision:

Decision owner:

Decision time and time zone:

Reason and known items:

## 4. Post-launch follow-up

- [ ] Recheck forms and integrations after the initial production test.
- [ ] Review error logs, broken links, redirect failures, and crawl reports.
- [ ] Review field performance data when enough real traffic exists; do not treat launch-day lab data as field evidence.
- [ ] Confirm client access and begin the separate handoff process.
- [ ] Move non-blocking items into an owned follow-up list with due dates.
- [ ] Close temporary access that is no longer required.

Follow-up owner and review date: