AI website launch checklist: from preview to public site

Check the content first

Search the entire site for placeholder names, sample prices, generic contact details, and invented claims. Verify opening hours, service areas, and links with the business owner. Check that images can legally be used and accurately represent the product or service. Make sure every important page has a clear title and purpose.

Complete the main action

Submit an enquiry and inspect the destination inbox. If the site takes bookings, verify the calendar event and notifications. If it accepts payments, use the provider’s test workflow and confirm the backend receives the correct status. Test failure paths as well as success: invalid input, duplicate submission, and interrupted connection.

Use the site in different ways

Try a small screen, a larger computer, and keyboard navigation. Check that text is readable when enlarged, focus is visible, and controls have understandable labels. Ensure menus, dialogs, and forms do not become inaccessible when the screen is narrow. A decorative animation should not be necessary to understand the page.

Review private features separately

For accounts or portals, use at least two test identities. Check that users cannot open each other’s records or change their own permissions. Keep sensitive data out until access rules are reviewed. Identify backup and recovery responsibilities; a public marketing page and a private business application need different levels of operational care.

Verify the live address

After deployment, repeat the key checks on the production domain. Confirm redirects, canonical URLs, sitemap access, and a genuine not-found response for missing pages. Make sure preview-only restrictions or sample integrations have not accidentally carried over. Keep a known working version available if you need to roll back.

Run a launch rehearsal with a defined visitor journey

Choose the most important action the site supports and perform it as a visitor would. For a service business, that may be reading a service description and sending an enquiry. For a portal, it may be signing in and opening an assigned document. For a store, it includes payment and the resulting order state. A checklist is more useful when tied to that journey than when it is a collection of disconnected technical tasks.

Use a test record you can recognise later. Record the page, device, input, expected result, and observed result. If a test creates a real booking, account, or message, plan how the test data will be identified and removed through the normal process. Do not mix invented test customers into production reports without a label.

Review facts and promises before design details

Search for placeholder names, sample addresses, invented testimonials, unsupported results, and old dates. Verify service descriptions, opening hours, pricing, availability, and contact details with the business owner. Check that images are approved and that captions accurately describe them.

Read the main CTA and the destination together. “Book now” should not lead to an unexplained general contact page. “Start a free trial” should not conceal a different paid commitment. If the next step is a request or an application, say so. The wording should set the expectation the product actually fulfils.

Test forms through to the receiving system

Submit a valid message and verify that the intended person or system receives it. Reply to the test message and confirm the address is usable. Test missing required fields, invalid input, a double click, and a slow or failed connection. Ensure errors explain what to correct without deleting the visitor’s work.

A form can show success while delivery fails. Inspect the actual destination, not only the screen. If messages are stored and emailed asynchronously, use confirmation wording that reflects the accepted submission rather than promising that a human has read it. Keep a fallback route for important enquiries.

Inspect mobile and keyboard use

Try a narrow phone layout and a larger desktop view. Enlarge text and check that controls remain usable. Navigate with the keyboard: focus should be visible, interactive elements should have understandable names, and menus should open and close without trapping the user unexpectedly.

Check long content, not only short placeholders. A long service name, email address, or table cell can create horizontal overflow. Verify that sticky headers or bottom CTAs do not cover form errors or the last item on a page. Decorative motion should not be necessary to understand the content.

Review private and paid features separately

For private records, use two test identities with different data. Attempt to open one user’s direct record and file links from the other account. Test expired sessions and removed access. A navigation menu that hides records is not proof that the data request is protected.

For payments, use the provider’s supported test environment. Confirm that a successful payment produces the correct order or entitlement and that a failed payment does not. Test repeated notifications and cancellation. Keep raw payment credentials and service secrets out of browser-delivered code.

These checks are a practical launch baseline, not a complete professional security assessment. Applications handling important private records or business-critical transactions need review appropriate to their scope. Document who owns that review rather than assuming the generated interface establishes readiness.

Verify the published environment

Repeat the main journey on the final domain after deployment. Check HTTPS, root/www redirects, direct internal URLs, and a genuine not-found response for a missing route. Confirm that canonical URLs and the sitemap use the intended primary domain. Remove accidental preview restrictions from pages meant to be public.

Inspect integration settings that depend on the address. Login callbacks, payment return URLs, and email links may still point to a preview host. Production data may be separate from preview data. Use a clearly labelled test to confirm the live connection rather than assuming that successful preview behaviour transfers automatically.

Check measurement and recovery

Define the events that matter. An outbound affiliate click, a form submission, and a paid signup are different outcomes. Name them accurately. Verify that tracking does not prevent normal navigation if an analytics service is unavailable. Exclude your own test activity from business conclusions where practical.

Preserve a known working deployment or version and document how to restore it. For data-backed applications, a code rollback does not necessarily reverse database changes. Keep backups appropriate to the data and test restoration with sample records. Assign an owner for domain renewal and service billing.

Make a short launch decision

Separate blockers from improvements. A broken enquiry path, incorrect price, or exposed private record blocks launch. A minor spacing preference may not. Write the unresolved items with an owner and a next action so cosmetic work does not obscure a functional failure.

After launch, monitor the first real journeys and review recurring questions. Schedule a small maintenance check for forms, links, pricing, and domains. The purpose of a launch checklist is to establish dependable behaviour and a way to maintain it, not to declare that a website will never need attention again.

Record evidence, not just ticks

• Save the test enquiry and received message.
• Record which devices and browsers you checked.
• List any unconnected or sample features.
• Record the live URL and deployment date.
• Assign a person to monitor messages and resolve launch issues.