Freeze the candidate, pass five evidence-based launch gates, test the real business journey, and use the downloadable record to make a clear ship or hold decision.

A client website launch checklist should answer a more useful question than ‘Did we look at every page?’ It should tell the agency and client exactly what is going live, what was tested, who approved it, and what would stop the launch.

That distinction matters for an AI-built site. A useful prompt can alter copy, layout, links, metadata, and application behavior in one pass. The speed is valuable, but it also makes a vague ‘final version’ surprisingly easy to lose. If someone asks for one last improvement after quality assurance, the candidate has changed. The affected checks need to reopen.

I would run the launch through five gates: truth, journey, transaction, control, and discovery. Each gate needs an owner, evidence, a status, and a re-test trigger. The result is not a claim that a site is perfect. It is a defensible decision about one identified release.

Separate the launch from the handoff

Launch and handoff overlap, but they are not the same deliverable.

The launch proves that a specific release is ready for visitors. Handoff proves that the client has appropriate access, can handle agreed updates, and knows how to get help. I would finish the launch record first, then use a separate website handoff checklist for ownership, training, and the client’s first edit.

This boundary prevents a polished training call from covering up a broken form. It also prevents an agency from calling a launch complete while the client’s approval still refers to an older version.

Start the client website launch checklist with one candidate

Before final quality assurance, record the candidate URL and a version identifier such as a snapshot, commit, release number, or platform revision. Add the planned production hostname, launch window, agency deployment owner, client approver, and rollback decision owner.

Then pause ordinary edits. This is not a permanent content freeze. It is a short control period that makes the test results meaningful.

For an AI-built site, I would add a simple rule to the project:

Any prompt or direct edit that changes the candidate after final verification must name the affected launch gates and repeat their checks before approval.

A typo correction may reopen truth and discovery if it changes metadata. A spacing fix may reopen journey. A new form field reopens journey, transaction, accessibility review, privacy review, and possibly analytics. The point is not to make small changes bureaucratic. It is to stop old evidence from being attached to new behavior.

On Fork, file-changing agent work is checkpointed automatically, and read-only checkpoint previews can support review. The history documentation also warns that restoring a snapshot replaces current workspace state. I would record the exact snapshot and preserve later work before any restore. I would not describe that snapshot as a backup of a CRM, mailbox, payment provider, DNS account, or another external system.

Use five launch gates instead of one flat list

A long collection of boxes can hide the one failure that matters. I prefer five gates because each one represents a reason to hold the release.

Use four statuses: pass, hold, pass with a known item, and not applicable. A known item needs an owner and due date. A hold needs a clear condition for retesting. ‘Almost done’ is not a status.

Gate 1: Verify truth, approval, and asset rights

AI can make unfinished copy sound finished. That is exactly why I would review facts separately from tone.

Check names, job titles, addresses, opening hours, phone numbers, prices, dates, service areas, guarantees, and offer terms against an approved source. Ask who can substantiate every testimonial, statistic, certification, client logo, and outcome claim. Confirm the rights for photographs, fonts, illustrations, PDFs, and other assets.

Compare the visible page with its title, description, social card, and structured data. A generated schema block should not contain a price, rating, address, or availability claim that the visitor cannot verify on the page.

Legal and regulated language needs the appropriate client or specialist review. I would record who approved the text, not ask an AI tool to declare it compliant.

Finish this gate with written client approval for the exact candidate. The record should include the approver, time, candidate identifier, and known exceptions. A message saying ‘looks great’ beside an old staging link is not enough.

Gate 2: Test the visitor journey with people and tools

Start with the routes a visitor actually uses: homepage to primary service, navigation to contact, landing page to form, and an invalid URL to the 404 page. Test on a phone and desktop browser. Open menus and dialogs, scroll through long pages, enlarge text, rotate the phone if the layout supports it, and check that controls remain inside the viewport.

Then use only a keyboard for the primary journey. Confirm that focus is visible, the order makes sense, menus open and close, dialogs do not trap the user, and every important control is reachable. Review headings, landmarks, form labels, alternatives, errors, and status messages.

Automated tools are useful here, but they do not settle the gate. The W3C Web Accessibility Initiative says no tool alone can determine whether a site meets accessibility standards and that knowledgeable human evaluation is required. I would treat the launch pass as a practical review, not a claim of full conformance or legal compliance.

Record performance evidence on representative pages too. web.dev’s Web Vitals guidance distinguishes lab and field measurement: lab checks can catch regressions before release, but they do not replace real-user data across different devices, networks, and interactions. Save the conditions and result instead of turning one score into a universal promise.

Gate 3: Follow every critical transaction to its destination

A green success message proves that the browser displayed a green success message. It does not prove that the client received a lead.

For every launch-critical form, submit a clearly labeled test on the candidate. Check required fields, invalid input, failure behavior, the success state, and duplicate submissions. Then confirm the result in the approved destination. That might be an inbox, CRM, database, booking tool, or payment system.

Apply the same end-to-end rule to phone links, email links, downloads, appointment booking, account creation, checkout, donations, and gated resources. Record non-sensitive proof such as a test record ID, timestamp, or screenshot location. Remove test records when appropriate.

If analytics is part of the project, test the business event rather than only the pageview. Google’s DebugView documentation says it displays collected events in real time for troubleshooting after debug mode is enabled. It also notes that consent and privacy controls can prevent events from appearing. Check the intended consent states and record the property, event, device, and time. Seeing one event is useful evidence, not proof that every visitor is measured.

Gate 4: Verify control, secrets, and recovery

Control begins with accounts, not instructions. A prompt saying ‘do not publish’ guides a task. It does not prove that the account lacks deployment permission.

Fork’s roles and permissions documentation separates project permissions such as edit, approve, deploy, invite, and delete, and it distinguishes project access from runtime administration. Whatever platform you use, test the intended agency and client roles with their actual accounts. Try one allowed action and one action that should be restricted.

Review temporary users, debug routes, sample data, test integrations, and unnecessary administrator access. Record who owns the domain, runtime, analytics, form destination, recovery process, and launch decision.

Keep secret values out of prompts, source files, screenshots, launch records, and chat. The OWASP Secrets Management Cheat Sheet recommends least-privilege access, controlled secret lifecycles, and preventing pipeline output from leaking secrets. Your checklist needs the owner and approved access path, not a copy of the credential.

Finally, write the rollback trigger. ‘If something goes wrong, restore’ is too vague. Name the conditions, decision owner, version to restore, evidence to preserve, and external actions that need separate handling.

Gate 5: Check the production origin and discovery paths

Discovery covers people opening links, browsers enforcing HTTPS, social networks rendering previews, and crawlers finding the intended URLs.

Confirm the production hostname, certificate, internal links, canonical URLs, callbacks, cookies, generated links, social metadata, robots rules, and sitemap. Fork’s custom domain documentation describes ownership verification, routing, and TLS provisioning as separate states and recommends one canonical application origin. A DNS edit alone is not the final check. Open the live hostname and test it.

For a redesign or migration, create an old-to-new URL map before launch. Google’s site move guidance recommends updating internal links and canonicals, using server-side permanent redirects where possible, testing redirects, removing migration-only noindex rules, and monitoring after the move. Redirect removed pages to relevant destinations, not automatically to the homepage.

Inspect the sitemap rather than assuming the CMS generated the right one. Google’s sitemap documentation recommends fully qualified canonical URLs and makes an important limitation explicit: submitting a sitemap is a hint, not a guarantee of crawling or indexing.

Worked example: turn checks into a launch decision

Consider an illustrative five-page site for a fictional professional-services firm. Assume it replaces an older domain, has one contact form routed to a shared inbox, uses Google Analytics, and has no checkout or customer login. This is a planning example, not a client result.

The site does not launch yet. Twenty successful checks do not cancel two blockers. Once the focus indicator and canonical are fixed, those changes reopen journey and discovery. The team retests those gates against candidate R18 and records a new decision.

This approach also makes scope visible. Because the example has no account area or checkout, those tests are marked not applicable rather than silently skipped.

Repeat the business-critical checks on production

Staging approval is not the finish line. Production can introduce a different hostname, certificate, cookie scope, callback URL, environment configuration, analytics property, form credential, cache, or redirect rule.

After deployment or the planned domain change, open a fresh browser session and run a short production pass:

1. Open the homepage, primary landing page, contact page, and one invalid URL.
2. Complete the primary conversion with a labeled test and confirm its destination.
3. Observe the key analytics event in the intended production property.
4. Test representative old URLs, the canonical, robots rules, sitemap, and social preview.
5. Check production logs and monitoring for new failures without copying sensitive data into the launch record.
6. Record ship, ship with known items, or roll back, plus the decision owner and time.

Then schedule the follow-up. Review form delivery, errors, broken links, crawl reports, and field performance when enough real traffic exists. Move non-blocking work into an owned list with dates. Close temporary access that is no longer required.

Download the reusable launch record

I turned the five gates into a downloadable client website launch checklist. It includes the candidate record, gate table, detailed checks, launch-day production pass, decision log, and post-launch follow-up.

Use it as a starting point, then add checks for the site’s actual risk. An ecommerce launch needs payments, tax, inventory, refunds, and transactional messages. A membership site needs account creation, authorization, password recovery, and data isolation. A brochure site should not inherit those boxes just to look thorough.

The most important fields are not the checkboxes. They are candidate, owner, evidence, status, and re-test trigger. Those fields turn a list into an operating record.

Common questions about launching AI-built client sites

Should the AI agent run the whole launch checklist?

Use an agent for bounded inspection, repeatable tests, link checks, screenshots, and evidence collection. Keep factual approval, accessibility judgment, regulated language, secret handling, business-flow confirmation, and the final release decision with the appropriate people. Ask the agent for an outcome and verification target, then inspect the result.

Does a successful page load mean the site is ready?

No. It establishes that one request returned something the browser could display. It does not prove that the right content loaded, the form reached its destination, the client role is restricted, analytics recorded the event, or a rollback will work.

Can we launch with known issues?

Sometimes, if the issue is genuinely non-blocking and the client understands it. Record the impact, owner, due date, and why it does not threaten truth, the critical journey, the transaction, control, or discovery. Do not rename a blocker as a known item to protect the date.

When do we give the client AI editing access?

Choose the role and process before launch, but conduct the full editing handoff after the release is stable. If the client must edit during the final verification window, treat that edit like any other candidate change and reopen the affected gates.

Make launch evidence-based, not confidence-based

I want a launch record to be boring in the best way. It should identify the release, show the evidence, expose the blockers, name the decision maker, and tell the team what must be repeated after a change.

AI makes it faster to create and revise a client website. The launch discipline stays familiar: verify what the site says, follow what visitors do, confirm where the business result lands, control who can change the system, and check the production paths people and crawlers will use.

Fork is built for client websites with AI access, with agent work and verification happening inside the website workspace. If that workflow fits the service you want to offer, join the Fork waitlist and use the checklist on your next release while access opens in batches.