ChatGPT Work Website Before Launch Checklist

Before launching a website built with ChatGPT Work, test the exact public release against a written checklist covering pages, forms, mobile layout, browsers, SEO, indexability, content, trust, hosting, analytics, privacy, accessibility, backups and ownership. Mark each item Pass, Fail or Not Applicable and keep evidence. ChatGPT Work can help assemble the project and organise the review, but it cannot prove a form reached the inbox or a live page is indexable without those checks being run. Stop the launch when a failure could lose enquiries, expose information or leave the business unable to recover the site.

How to use this checklist

Name the release, public URL, date, tester and owner. Use fictional form data and a private test record where necessary. A Pass needs observable evidence: a delivered enquiry, a visible metadata value, a successful mobile journey or a documented backup. “It looks right” is not evidence for behaviour behind the page.

• Pass: requirement works on the release being launched.
• Fail: requirement is broken, missing or cannot be verified.
• Not Applicable: requirement genuinely does not apply, with a reason.

1. Confirm the page structure

• List every page intended for launch and its purpose.
• Confirm navigation reaches each important public page.
• Check the homepage explains the business, audience and primary next step.
• Give major services enough detail instead of repeating a generic summary.
• Include contact and privacy information appropriate to the business.
• Remove demonstration pages, placeholders and unused menu items.
• Open deeper URLs directly and confirm they return the intended page.

If the generated site has no clear hierarchy, use the AI website builder check before expanding it with more pages.

2. Make the content specific and supportable

• Verify services, locations, prices, timescales and qualifications.
• Remove invented testimonials, statistics, clients and guarantees.
• Replace generic phrases with real process, evidence and constraints.
• Check names, telephone numbers, email addresses and opening hours.
• Make each search-led page answer a distinct customer question.
• Proofread headings, buttons, form labels and automated messages.
• Confirm the business has permission to use supplied text and assets.

3. Prove forms and enquiry routes

1. Submit every form with a clearly labelled test enquiry.
2. Confirm required-field and invalid-input messages are understandable.
3. Verify the expected recipient receives the complete message.
4. Check reply-to behaviour, spam folders and any stored submission.
5. Test telephone, email, booking, download and map links.
6. Confirm the success message appears only after genuine success.
7. Review consent wording and retention against what the form actually does.

A form that changes colour or shows “sent” without a verified destination has failed this check.

4. Check mobile layout, browsers and accessibility basics

• Test the complete enquiry journey at 390px and on a real phone.
• Check the longest headings and service names for clipping or orphaned words.
• Open and close mobile navigation using touch and keyboard.
• Confirm fields, buttons and cookie controls fit without horizontal scrolling.
• Test a current Chromium browser and a second browser engine.
• Use visible labels, useful alternative text and logical heading order.
• Tab through the main journey and confirm focus remains visible.
• Check colour contrast and that information is not communicated by colour alone.

5. Verify SEO metadata and indexability

• Give every important page a distinct, descriptive SEO title.
• Use one visible H1 that matches the page purpose.
• Write a natural meta description for the intended visitor.
• Confirm the canonical points to the preferred public URL.
• Check important pages return HTTP 200 and do not contain noindex.
• Review robots rules and sitemap inclusion.
• Confirm internal links use live destinations and useful anchor text.
• Check structured data matches visible content and is not duplicated.

Do not promise rankings or generate thin pages to make the sitemap larger. Search readiness begins with accessible, useful pages and technically consistent URLs.

6. Test hosting, domain and deployment

• Confirm the intended release is live on the correct domain.
• Check HTTPS and redirects between preferred and alternative hostnames.
• Open the website without a builder or ChatGPT session.
• Verify deeper routes after a direct visit and browser refresh.
• Review build and deployment logs for unresolved errors.
• Confirm required production settings exist without exposing secret values.
• Document how to deploy the next version and roll back this one.
• Check the business controls the domain and hosting accounts.

If preview and production disagree, pause. A structured diagnosis should identify whether the difference belongs to code, configuration, domain or hosting.

7. Validate analytics, cookies and privacy

• Run a controlled visit and confirm the analytics property receives it.
• Test the primary conversion event, not only a page view.
• Check consent choices affect non-essential scripts as intended.
• Make privacy information easy to reach before personal data is submitted.
• List third-party services receiving visitor or enquiry information.
• Remove unused tracking, test IDs and duplicate scripts.
• Confirm staff know where enquiries and reports will appear.

8. Establish ownership, backups and repairability

• Record who owns the domain, hosting, repository, analytics and form service.
• Store source files or repository history outside a single chat conversation.
• Create or verify a recoverable backup before launch.
• Document the current release and last stable version.
• List frameworks, plugins, packages and connected services.
• Confirm another competent person can receive access and run the project.
• Record renewal dates and any platform dependency the business accepts.

The ChatGPT Work website repair service can help when the website exists but its ownership or repair route is unclear.

9. Prepare the launch evidence pack

Keep a short record that someone other than the builder can understand:

• Release URL, version and launch date.
• Page list and primary customer journeys.
• Form recipients and successful test references.
• Mobile and browser combinations tested.
• SEO, analytics and consent checks completed.
• Known limitations, owners and planned dates.
• Backup location and rollback instructions.
• Support contact and escalation route.

Do not launch when these failures remain

Stop when enquiries are lost, critical pages fail, private information is exposed, the site cannot be recovered, production differs materially from the tested version or the business does not control its domain. Also stop when the copy includes claims nobody can verify or the website is intentionally hidden from search despite depending on organic visibility.

Smaller limitations can be accepted only when they are understood, documented and do not undermine the release purpose. Launch pressure does not convert an unknown into an acceptable risk.

Assign every failure to a person and a release

A checklist with unowned failures is only a list of concerns. For each failed or amber item, record who will decide, who will make the change, the target release and the evidence needed to close it. Keep business decisions separate from technical implementation. For example, the business owns whether a claim is supportable; a developer may own how the approved correction is published.

Use a new release identifier after a meaningful fix and repeat the affected checks. Do not copy a Pass from the previous version when a shared template, form handler, navigation component or deployment configuration has changed. This simple discipline makes a launch decision traceable.

Check the first week after launch

Launch is the start of production evidence. During the first week, verify form delivery daily, review error and uptime reports, check analytics for obviously missing page views, and look for unexpected 404s or indexing blocks. Compare customer questions with the page structure rather than immediately generating more content.

Define who receives alerts and who can roll back a failed change. Keep the pre-launch evidence pack available so a new problem can be compared with a known release. This monitoring does not replace the checklist; it catches conditions that appear only with real traffic and external services.

Repeat the right checks after every meaningful change

A launch pass applies to one release. Repeat the affected tests after a generated layout change, form edit, dependency update, hosting move or significant content restructure. Keep a small regression list for the journeys that matter most.

ChatGPT Work can help maintain the checklist and compare results, but the checks still need to be performed on the actual release. For broader existing ChatGPT-built sites, ChatGPT website repair can review faults that are not limited to the newer Work workflow.

Make the launch decision from evidence

Launch when the site’s essential pages, forms, mobile journey, search controls, hosting and ownership have passed and remaining limitations are explicitly accepted. Repair failed checks before adding more features. If several critical areas are unknown, use focused website repair rather than relying on another broad prompt. The goal is not a perfect website. It is a release the business understands, can verify and can recover.