AI website builders have crossed an important threshold: they can produce a credible first release quickly.
That does not make the output production-ready.
The generated pages are the easiest part to inspect. The harder questions appear after launch, when someone needs to change an offer, trace a missing lead, reverse a bad deployment or move the system to another operator.
Here are the seven checks I use to separate a fast build from an operable website.
Choose a real but low-risk edit: a service price, opening hour, team member or call-to-action.
Give the task to someone who did not create the site. They should be able to:
A CMS is not automatically the right answer. A small, rarely changed site may be clearer as versioned code. The useful standard is whether the intended operator can make the intended change safely without the original prompt history.
Submit the form with an address you can recognise. Then follow the request.
Check where validation happens, where the data is stored, who is notified and what the user sees when delivery fails. Test duplicates and rate limits if the form handles meaningful lead volume.
On SharpHaw's own site, the form path is explicit in the application: server-side validation, a honeypot, defined responses for rejected, duplicate and rate-limited submissions, and a separate success route after the system accepts the request.
That detail matters because a client-side “success” message can be wrong. Your conversion event should follow the accepted business outcome, not the optimistic click.
The business should own the domain, DNS and search property.
I check that another authorised person can manage Search Console users, inspect a changed URL, find the sitemap and explain which routes belong in it. I also look for intentional canonical URLs rather than defaults inherited from a template.
Indexing is not a one-time state. Search ownership means the team can investigate the next problem without waiting for a vendor.
Run one test conversion and compare three things:
On the SharpHaw site, the primary website conversion is associated with the success route rather than the initial form interaction. Analytics is also consent-aware. Those are small implementation decisions, but they prevent a click from masquerading as a lead.
Performance metrics still matter. They answer a different question. A page can have good Core Web Vitals and still lose the enquiry after submission.
Do not accept “the platform keeps backups” as the whole recovery plan.
In a safe environment, identify a previous release and restore it. Confirm that:
Exporting code is helpful. It does not necessarily export the system.
Depending on the platform, the files may not include structured content, form processing, customer data, user accounts, search, localisation, commerce, environment variables or deployment configuration.
I inventory these separately:
source and build instructions content and uploaded assets form submissions and customer data environment-variable inventory domain and DNS access analytics and search properties deployment history and backups licences and paid integrations
The point is not to reject managed services. They can remove a lot of undifferentiated maintenance. The point is to know which part of the business stops when a service is cancelled.
The cleanest test is an independent handover.
Give a competent developer or operator the repository, access map, content source, environment-variable inventory, deployment notes, recovery path and service ownership list.
Ask them to run the site, make one content change, trace a lead and describe a rollback.
They do not need to like the stack. They need to understand it well enough to operate it.
This test catches undocumented build commands, personal accounts, missing environment variables and architectural decisions that exist only in the original builder's head.
Not every site needs the same process.
For a throwaway validation page, speed and reversibility may be enough. For an operating marketing site, I expect owned access, traceable enquiries, accurate conversion events and basic recovery. For a revenue-critical system, I want a rehearsed restore, a complete data export and an independent handover.
AI has made the visible layer cheaper and faster. That is useful. It also means more websites can look complete before their operational model is complete.
What check has caught the most serious post-launch problem in your builds?