An AI-built site reaches the “looks finished” stage alarmingly fast. The hero section glows, the testimonials sound warm, the contact form has a nice rounded button. Then a customer fills in that form on launch day and the message goes nowhere, because nobody ever connected it to an inbox. The model built a form-shaped object. It did what it was asked.
This website launch checklist is for that gap between a convincing build and a site a business can actually run. It covers the ordinary launch work every site needs (content, navigation, forms, mobile layout, keyboard use, search settings, analytics, consent, HTTPS, access, backups, ownership) and then adds a separate pass for the things AI tools tend to leave behind: placeholder testimonials, invented facts, dead buttons and dashboards full of pretend numbers. The tool documentation linked below was checked on 26 October 2026. Where the checklist touches law or security, it points to the official source and stops there. It is a launch routine, not legal advice or a security audit.
A convincing concept is a different product from a production site
Direktorium has a documented example of the first kind: a website concept built with ChatGPT and Claude Code in under 30 minutes, where the stated goal was a visually convincing prototype to show a client, not the full production architecture. That is a perfectly good thing to build. A concept exists to make a direction easy to judge. Its numbers can be sample numbers and its buttons can lead nowhere, because the audience knows what they are looking at.
A production site has a different audience. Strangers will believe what it says, submit their details into it, and judge the business by whether it answers. So the launch questions get duller: does every part that looks functional actually work, and is every claim on the page true? Those are boring questions. They are also the ones that cost money when skipped.
The checklist also needs a reference point. If the original requirements were never written down, you cannot say whether the site meets them. The Brief Decoder walks through separating explicit requirements from guesses, and its output makes a decent first column for this exercise: every requirement should map to at least one line below.
How to use the checklist without fooling yourself
Each item has a test method, an owner and a column for evidence. The evidence column is the point. “Checked, looks fine” is not evidence. A screenshot of the received test email, the response headers from the live URL, a short screen recording of tabbing through the menu: those are evidence, and they settle arguments later when someone asks whether the form ever worked.
Owners here are roles. On a small project the business owner and the builder may be the only two people involved, and that is fine. What matters is that the person who built a feature is not the only one who tests it, since builders test the path they built and customers rarely take that path. Mark an item Pass, Fail or Not applicable, and don’t launch with an unexplained Fail.
The website launch checklist
Copy this into a spreadsheet or doc and add a date column if you like. It is grouped so different people can work through sections in parallel.
| Item | Test method | Owner | Pass/fail evidence |
|---|---|---|---|
| Content and navigation | |||
| Facts are accurate | Read every page against a list of verified business facts: prices, hours, address, services, team names | Business owner | Marked-up page text with each claim ticked |
| Contact details work | Call the number, email the address, open the map link | Business owner | Note of each test and result |
| Every link and menu item lands somewhere real | Click through on desktop and phone; run a link checker | Builder | Link report with zero broken internal links |
| Legal pages exist where needed | Privacy notice and any required notices match what the site actually collects | Business owner | Links to live pages; adviser sign-off if used |
| Forms and functions | |||
| Forms deliver | Submit each form with real test data | Second person | Screenshot of the received message, with time |
| Notifications and replies | Check spam folders, autoresponders, booking confirmations | Second person | Screenshots from the customer side and the business side |
| Errors are handled | Submit empty and invalid fields | Builder | Screenshot of a clear error message |
| Layout and access | |||
| Mobile layout | Real phone, portrait and landscape, plus one older device if available | Second person | Screenshots of key pages |
| Keyboard use | Tab through menu, forms and buttons without a mouse; focus must stay visible | Builder | Screen recording |
| Images | Meaningful images have alt text, decorative ones empty alt; no stretched or oversized files | Builder | List of images with alt text |
| Search settings | |||
| Page titles | Each page has its own descriptive title, not “Home” or the theme name | Builder | List of URLs and titles |
| Production is indexable | No noindex meta tag or header on live pages; robots.txt not blocking the site | Builder | Header output and URL Inspection result |
| Redirects where URLs changed | Visit each old URL | Builder | Old URL, new URL, 301 status |
| Analytics and consent | |||
| Analytics records visits and key events | Trigger a form submission, check DebugView or Realtime | Analytics owner | Screenshot of the event arriving |
| Consent matches your situation | Check which scripts run before and after the banner choice | Business owner | Notes on scripts loaded; adviser input if needed |
| Security, access and ownership | |||
| HTTPS everywhere | Load http:// and www variants; check for mixed content warnings | Builder | Redirect results and clean console |
| Access is controlled | Remove test accounts and old collaborators; admin uses strong unique passwords | Business owner | Current user list |
| Backups restore | Run a backup and test a restore, not just the backup | Builder | Restore date and result |
| Business owns the accounts | Domain, hosting, analytics and Search Console sit under the business’s own login | Business owner | Account list with owner email |
| Handover done | Short doc: logins location, how to edit pages, who to call when it breaks | Builder | Link to the doc |
A few rows need more than a table cell, so here is the reasoning behind them.
Forms, keyboards and images: the quiet failures
Forms fail silently, which is why they go first. The site shows “Thanks, we’ll be in touch”, the visitor leaves happy, and the message dies in a misconfigured mail setting or lands in spam. Test from an address outside your business, fill in every field, and check what arrives on both ends. If the form saves submissions to a database or CRM as well as email, confirm the record exists there too.
Keyboard testing takes five minutes and catches a surprising amount. W3C’s success criterion on keyboard operation asks that all functionality works through a keyboard interface, and the one on visible focus exists because sighted keyboard users cannot operate a page when they can’t see where they are. Custom AI-generated menus and modal windows are frequent offenders. This check is a quick sanity test, not an accessibility certification, and W3C’s own Easy Checks page is a good next step if you want more.
For images, W3C’s alt decision tree is the fastest way to decide what each image needs. Generated sites often either skip alt text entirely or fill it with “image of modern office”, which helps nobody.
Preview and production are supposed to behave differently
Most hosting setups give you a preview or staging address and a production domain, and the search settings should differ between them. Vercel, for example, adds an x-robots-tag: noindex header to preview deployments and outdated production deployments automatically. Netlify adds it to Deploy Previews but not to the most recent deploy of each branch, so a staging branch URL can end up indexed unless you protect it (Netlify suggests password protection or a private project). On WordPress, the “Discourage search engines” box adds a noindex, nofollow robots meta tag, which is handy on staging and a disaster when it gets copied to the live site.
Two details from Google’s documentation trip people up. A robots.txt file is not a mechanism for keeping a page out of Google; use noindex or password protection. And for noindex to work, the page must not be blocked by robots.txt, because a crawler that can’t fetch the page never sees the rule. After launch, the Search Console URL Inspection live test shows whether Google can fetch and index the production URL.
If you are replacing an old site, list its URLs before switching anything off. Google recommends permanent redirects when a page moves for good, so old links and bookmarks land on the new equivalent instead of a 404. Page titles are worth one pass too: Google’s title link guidance asks for a unique, descriptive title on every page, and AI builders love giving every page the same one.
Analytics and consent belong together. Google Analytics’ DebugView lets you watch events arrive while you click around, though events won’t show if consent mode is on and you declined analytics cookies, which confuses plenty of people on the first try. What consent you need depends on where the business and its visitors are. In the UK, for instance, the ICO describes a statistical purposes exception for some analytics, with conditions including clear information and a simple way to object. Other jurisdictions set different rules. If you are unsure, ask someone qualified rather than a chatbot. On HTTPS, web.dev’s guide to fixing mixed content covers the common case where the page loads securely but an image or script still comes over plain HTTP.
The AI-specific pass
Run this after the ordinary checklist, by someone who did not write the prompts. Generative tools are good at filling space with plausible material, and plausible is exactly what slips past a quick read.
| What gets left behind | How to find it |
|---|---|
| Placeholder testimonials and reviews | Ask for the source of each quote; no named, real customer with permission means it goes |
| Invented facts | Highlight every number, year, award, certification and client logo; each needs a source you can show |
| Dead buttons | Click every button and icon, including footer social links |
| Mock dashboards and stats | Find any chart or counter; is it fed by real data or hardcoded? |
| Features that only look functional | Search bars, filters, pricing toggles, chat widgets, newsletter boxes: use each one end to end |
| Template leftovers | Search the code and text for “lorem”, “example.com”, “John Doe”, “Acme” and “TODO” |
Testimonials deserve the hardest line. In the US, the FTC’s rule on fake reviews and testimonials specifically covers testimonials attributed to people who don’t exist, and names AI-generated fake reviews as an example (the rule text is in 16 CFR 465.2). Other countries have their own consumer rules, but you don’t need a regulator to tell you that a made-up quote from “Sarah, small business owner” is a bad look. Delete it and leave the space empty until a real customer agrees to be quoted.
A model can help with the hunt, as long as it is asked to find claims rather than judge them. Paste the full page text in and use something like this:
Below is the text of every page on a website that is about to launch. List every factual claim a visitor might rely on: numbers, dates, prices, qualifications, awards, client names, testimonials, guarantees, product capabilities and contact details. For each, quote the exact sentence and the page it appears on. Do not say whether the claims are true. Also list any text that looks like placeholder or template copy.
The output is a to-do list for a human with access to the real facts. If a claim can’t be backed up, rewrite it or remove it. That second option is underrated.
Ownership is the item people regret skipping
Nothing on launch day hurts as much as discovering, two years later, that the domain is registered to a freelancer who has stopped answering emails. Put the domain, hosting, analytics property and Search Console under accounts the business controls, with the builder added as a user rather than the other way round. Store the logins in a password manager. Then test a backup restore, because a backup nobody has ever restored is really just a hopeful file.
The handover document can be one page: where things live, how to edit a page, how to add a blog post, which plugins or services renew when, and who to call. Write it while the builder still remembers.
After launch
Passing this checklist means the site is ready to go live. It doesn’t mean the copy converts or the structure suits your customers. Once real visitors arrive, an evidence-based AI website audit is the next tool, since it works from actual pages, analytics and measured results instead of a pre-launch guess.
Direktorium keeps publishing practical guides like this one for people using AI on real business work. If you would rather have someone else build and launch the site properly, BBDirector does that as a done-for-you service.
