AI-Built Website Checklist: 8 Checks Before Launch and After Changes

Choose the checks that apply to your site

These are checks for essential customer journeys. They do not replace a full security, accessibility or performance assessment.

1. Check the offer and the next action

Read your main pages as a customer. Confirm the price, what it includes, delivery terms, and any results or testimonials. Read the contact details as a customer who intends to use them: the phone number, the postal address and the opening hours all have to be the ones your business actually keeps. Replace invented examples or unsupported promises left in generated copy.

Then follow each important button and link. A button promising a quotation should lead somewhere that explains how to request one. A booking button should open the right calendar. Check the mobile menu, footer and any language versions you publish, and open every link that leaves the page, including ones to your own social profiles and to documents you have linked.

Pass: the offer is accurate and each action reaches its intended destination. Record the page and destination. If a claim has no supporting source, correct it before directing customers to it.

2. Follow an enquiry through to the person answering it

Submit a clearly labelled test enquiry using an address you control. Put a unique label in the message so you can find the same submission later. Repeat this for each separate contact form, quote form, booking widget or chat route.

Before anything else, read the recipient address the form is configured to notify. A form that sends perfectly to an address nobody opens, or to one with a typo in it, behaves exactly like a broken form. Check that no placeholder recipient address remains in the configuration.

Check the stages your setup uses:

1. The website acknowledges the submission.
2. The enquiry appears in the form dashboard or CRM, if one is configured.
3. The email service records the notification, if email is part of the route.
4. The intended inbox receives it, and the responsible person can reply to the test address.
5. The customer receives the confirmation or auto-reply, if your form sends one.

Email status needs interpretation. Resend distinguishes a sending request from delivery to the recipient's mail server. Neither status proves that a person saw the message. Search all mail rather than the inbox alone, including spam and any promotions or updates tab, and check the customer-side address for the auto-reply as well as your own. Resend's event definitions

If the message is missing or lands in spam, check the sending provider's delivery details and domain-verification status. Ask your provider or administrator to verify the SPF and DKIM setup required for your sending domain or subdomain, using that provider's instructions. Google Workspace contact form troubleshooting Resend domain verification For Google Workspace recipients, an administrator can also inspect Email Log Search. Correct authentication addresses one class of problem; it does not guarantee inbox placement.

Pass: you can trace the test to the person or system meant to handle it. Save the reference, time and delivery result. If you only saw a success screen, delivery remains unverified. Where a provider hides logs, record the inbox result and ask support about the missing stage.

3. Test payments and refunds in the provider's test environment

For a store, use the payment provider's sandbox or test mode. Simulate a successful payment, a decline and a refund. If you sell subscriptions or take deposits, include those paths. Test each payment method you have switched on, not just a card: a wallet or a pay-later option can be configured separately and fail on its own.

Check the amount as well as the outcome. Change quantity, shipping method and any option that affects price, and confirm the total the provider receives matches the total the customer saw. Then confirm the customer lands on the success page rather than a blank screen, because a completed charge with a failed redirect looks to the buyer like a payment that did not go through.

Have your developer verify that repeated payment notifications do not create duplicate orders or fulfilment tasks. Stripe documents that webhook events can arrive more than once. Stripe webhook guidance

Pass: one successful transaction produces the expected order; a decline does not mark it paid; refund records and customer/staff notifications match your refund workflow. A refund notification may be correct. An instruction to manufacture or ship an order that should be stopped is not.

Keep simulations away from live fulfilment. Before launch, separately verify production configuration, then reconcile genuine orders when they arrive. Sandbox success alone does not prove the live setup is correct.

4. Check account access with test users

Skip this section if the site has no customer accounts or staff roles. Otherwise, create authorised test accounts with dummy records. Confirm that each role can do its own job and cannot access another customer's or team's restricted information.

An owner can test login, logout, password recovery and what each account displays. A developer should also check server-side permission enforcement; hiding a link is not enough to establish that access is blocked.

Pass: the expected task works for each role, and prohibited access is denied in the checks performed. Save the role and test result without exposing real customer data. If an account can read or change another account's private records, restrict that feature and get it fixed before wider use.

5. Complete the main task on mobile and with a keyboard

Use an actual phone to open the menu, read the offer and complete the enquiry or booking journey. Check a tablet or intermediate screen width too; layouts can change between breakpoints. Check that a banner, sticky button or on-screen keyboard does not cover the action you need.

On a computer, repeat the task using the keyboard. Focus should remain visible, labels should identify the fields, and errors should explain what to fix. Try an empty required field and an invalid email format. Confirm that valid entries are retained where appropriate.

Pass: you complete the tested task with both input methods and can recover from the tested errors. Save the device/browser and any blocked step. This is a basic usability check; W3C notes that easy checks can pass while other accessibility barriers remain. W3C accessibility checks

6. Check the pages you want search engines to find

Use Google Search Console's URL Inspection to compare its indexed-page information, where available, with a fresh live test. Those are separate observations, not one reading. Choose representative public pages: your homepage, an important service or product page, and a recently added page. Include different page templates where possible.

Read the indexed-page result first. Then select Test live URL, followed by View tested page → HTML, to inspect the current deployment's rendered content. Confirm that the main content is present and the intended public page is accessible for indexing.

Keep the results separate: the live test does not guarantee indexing, and Google's selected canonical is determined during indexing. An intentional private or excluded page should not be made public just to pass this check. Google's URL Inspection instructions

Pass for this check: the sampled intended public pages have accessible content and no unexplained indexing block. Record indexing status separately. For a Lovable-specific problem, use our Lovable search diagnostic.

7. Reconcile measurement with business records

Choose a period with enough activity to compare, and use the same timezone and definitions. Compare recorded enquiries with the form system or CRM, and orders with the commerce/payment records. Separate test submissions, spam, failed payments, duplicates and refunds.

A button click is not necessarily an enquiry. A payment notification is not necessarily a new order. Check which event your analytics counts before comparing totals.

Consent choices, blocked scripts and processing delays can explain differences. Record the gap you can explain and investigate the rest; do not force totals to match by changing definitions. Where source attribution matters, distinguish captured referrers or campaign details from customers saying how they found you.

Pass: the events represent the intended actions, and the scope and known gaps are documented. A small or incomplete sample should remain inconclusive. Identical totals alone do not prove every order or enquiry was matched correctly.

8. Confirm who notices a failure and how you recover

Open the monitoring settings available in your builder, hosting and connected services. Check what is enabled, the last successful run, the alert recipient, and any plan or credit conditions. A site-availability check answers a different question from a completed checkout test.

Use a provider's alert-test feature where available, or a controlled test environment. Confirm that the responsible person receives the alert and knows the next step. Do not break a live checkout to test monitoring.

Also establish who can access the domain and provider accounts, restore important data and roll back a bad release. A developer should demonstrate recovery in an appropriate test environment. Our website ownership guide explains what to confirm at handover.

Pass: the monitored conditions, recipient and response owner are known, with a tested alert where supported and a recorded recovery route. Unknown coverage remains a gap even when the dashboard is green.

What current AI builders already check

The tools are improving. Blanket claims that they only generate a page once are inaccurate. These are documented examples checked on 17 September 2026, not a ranking or a test of your project.

Use the help already available. Keep a record of the complete business result, including any stage the builder's own report cannot establish.

Why we check beyond the success screen

PandaCodeGen's own quote-form code contains an anti-spam path that deliberately returns a success response without sending an email. An automated test can trigger that path. That demonstrates why the browser response alone is insufficient evidence of delivery; it does not establish that a real customer's enquiry was lost.

We also have a dated internal source-audit record from 15 September 2026: two newly added email templates in our own operations platform could not send until a syntax error was found and fixed that day. The record does not establish how many messages, if any, staff or customers missed.

That operations platform runs Panda Patches, the business owned by PandaCodeGen co-founder Imran Raza Ladhani. It is our own operating experience. The case study describes the platform; the incident account above comes from our internal audit, not an independent assessment or a published production-delivery dataset.

The same questions apply to custom code, an AI-built site or a hosted template: what did you test, what happened downstream, and what evidence did you keep?

When to repeat the checks

Repeat the affected journey after changes to a form, recipient, payment integration, permissions, domain or publishing setup. Check domain and certificate expiry, service renewals, payment details and alert recipients. A missed renewal can interrupt the site, connected services or monitoring without a code change. Check new public page templates for usability and search access. There is no useful universal promise that this takes one hour or two.

• ✓
  A small enquiry site: a weekly delivery check can be a starting policy.
• ✓
  A busy store: consider daily reconciliation and automated alerts for critical failures.

These are suggested starting points: choose a frequency based on transaction volume, the impact of a missed failure and the monitoring already available.

If you can complete the checks and someone owns the follow-up, you may not need an agency. If you are deciding whether to build or hire, our DIY website cost guide covers that separate decision. Where a check keeps failing because the platform cannot do what the business needs, that is the work our custom engineering service covers.

Method: current vendor and provider documentation, this repository's form code and a dated internal operations audit. We did not run a controlled comparison across the seven builders or measure their failure rates. The check record is a reusable template, not a claim that these tests have been completed on your site. How we publish and correct information.