To test a site built with AI, run your normal QA but start with what you cannot see: who can read the data, what is exposed in the browser and what happens when a form gets bad input. Leave layout until later, because a generated site can look finished long before it is.

Vibe coding means building software by describing it to an AI tool and accepting what comes back, often without reading the code. It is a quick way to get something working. If nobody has read the code, your testing has to catch what a code review would have caught.

Know what kind of tool built it

The tools below describe themselves differently, and that changes where you should look first. Descriptions are from each tool's own site at the time of writing (November 2026).

Tool	What it says it is	Test this first
Lovable	A full-stack AI development platform whose apps can include a backend, database and authentication	Database access rules
v0	An AI agent for creating code and full-stack apps, with one-click deployment on Vercel	Anything connected to a backend, then deployment settings
Bolt	An AI builder for websites, apps and prototypes, which also lists databases, authentication and hosting	Whether a prototype is really ready for real users
Cursor	A coding agent used from a desktop IDE, the terminal and the cloud	Regressions, since changes usually land in an existing codebase

These tools do include their own safeguards. Lovable, for example, runs a Quick scan when you publish. Its security documentation is also upfront that its tools "do not replace a thorough security review".

What AI builders commonly get wrong

None of these show up in a visual review, which is why they get missed.

Authentication and access control

A generated app can hide a page from logged-out users and stop there, but hiding a page does not protect the data behind it. OWASP says access control is "only effective in trusted server-side code or server-less API".

Log in as one user and copy the URL of something private. Log in as a second user and open it. Then change any ID you can see in a URL or request. If the app uses Supabase, check every table: its docs warn that a table in an exposed schema without row level security "is readable and writable by any role with a grant on it". Lovable's docs likewise call misconfigured rules "a common cause of data leaks".

Exposed API keys

Not every key in the browser is a problem. Supabase says its publishable key is safe to expose, because it only reaches what row level security allows. Its secret key is different: it "bypasses every Row Level Security policy you have" and should never go in a browser.

Search the built JavaScript for secret, service_role, sk_live and api_key, and pay particular attention to payment, email and AI provider keys. If you find a live secret, removing it from the code is not enough. Rotate it, because it may already have been copied.

Form validation

A form that shows a neat red error in the browser may still accept anything sent to it directly. OWASP's input validation guidance says to validate on the server even when the browser checks the same fields. Also check that the form really does something, because a thank you message proves nothing until the enquiry reaches an inbox.

Accessibility

Generated interfaces can look right and still be hard to use without a mouse. Watch for clickable elements that are not real buttons, placeholder text standing in for labels, missing focus outlines, and low contrast text over images or gradients. W3C's Easy Checks are a good first pass, and our guide to WCAG compliance goes further.

SEO metadata

Client-rendered apps can ship one title on every route and an almost empty HTML document. Google can render JavaScript, but its JavaScript SEO guide warns that with the app shell model "the initial HTML does not contain the actual content", and explains how client-side routing can make meaningful status codes difficult. Google also asks for a distinct title on every page.

Edge states

Generated screens tend to be built around the happy path and a tidy set of demo data. Test what happens with no data, with far too much data, with a very long name, with an expired session and with a failed request. Look for leftover sample content and buttons that do nothing.

Save countless hours on your projects

Raise tasks in under 3 seconds using our revolutionary widget

The AI-generated website checklist

Print this or paste it into your own document, then tick off each row. Test on a staging copy with test accounts and test payment keys. Run this alongside your usual website QA checklist, which covers the general checks.

Access and accounts

Done	Test	A pass looks like
☐	Open a logged-in page in a private window	Redirected to login, no data loads
☐	Open user A's private URL while logged in as user B	Denied or not found
☐	Change an ID in a URL or API request	No other user's data comes back
☐	Open an admin page as a normal user	Denied by the server, not only hidden from the menu
☐	Sign up with an email already in use	Clear message, existing account untouched
☐	Use a password reset link twice	The second attempt fails
☐	Log out, then press Back	No private data is visible
☐	Review the access rules on every database table	No table is open to anonymous reads or writes unless intended

Keys and secrets

Done	Test	A pass looks like
☐	Search the built JavaScript for key names	Publishable keys only
☐	Watch the Network tab during paid actions such as AI or email calls	Requests go through your server
☐	Check the repository history for `.env` files	No secrets committed
☐	Rotate any key that was ever exposed	The old key no longer works

Forms and payments

Done	Test	A pass looks like
☐	Submit every form empty	A clear message on each required field
☐	Send invalid data straight to the endpoint	Rejected by the server
☐	Enter `O'Brien`, an emoji, `<b>test</b>` and 5,000 characters	Stored and shown as typed, with no broken layout
☐	Double-click every submit button	One record is created
☐	Submit each form with a real address	The message arrives in the right inbox
☐	Pay in test mode, including a declined card	Correct message, correct order status

Edge states

Done	Test	A pass looks like
☐	View every list with no data	A helpful empty message
☐	Load a list with hundreds of items	Pagination or scrolling works
☐	Block an API request in developer tools	An error message, not a blank screen
☐	Throttle the connection to Slow 4G	Loading states appear and nothing breaks
☐	Let a session expire, then submit a form	Sent to login, with a clear message
☐	Search for lorem ipsum, example.com and sample names	None remain
☐	Click every button and link	Each one does something real

Accessibility

Done	Test	A pass looks like
☐	Tab through every page	All controls reachable, focus visible, sensible order
☐	Check every form field	A visible label, not only placeholder text
☐	Check images	Meaningful alt text, empty alt on decorative images
☐	Check text contrast, including over images	At least 4.5:1 for normal text
☐	Zoom to 200%	Nothing is cut off or overlapping

SEO and launch

Done	Test	A pass looks like
☐	Check the title and description on each template	Unique and accurate, with builder defaults gone
☐	Open a made-up URL and check the Network tab	A 404 status, not 200
☐	Look for a noindex tag	Absent on live, present on staging
☐	Open robots.txt and sitemap.xml	Both exist and list production URLs
☐	Replace the default favicon and social image	Your own branding appears
☐	Open the browser console on each template	No unexplained errors

Retest after every prompt

Asking an AI tool to fix one thing can change several files. Commit before each prompt so you can roll back, read what changed, and run a short smoke test after it: log in, submit the main form, complete the main journey. A change to a shared component can break something elsewhere, and a fix that removes a validation rule will look like a success.

Get the results back to the builder

A prompt saying "the form is broken" gets a guess. Give it the page, the element, the steps, the expected result and any console error, one issue at a time. A visual bug reporting tool such as QualityHive, which is our own product, captures the screenshot and the element you clicked so you are not retyping them. The workflow in fixing client feedback with AI applies just as well to your own QA list.

When to bring in a developer

If the site takes payments, holds personal data or has user accounts, get someone who can read the code to review it before launch. Lovable's own documentation says to "consider an additional professional security review" for apps handling sensitive data. A brochure site with one contact form carries less risk, but it still needs this checklist.

Revolutionise your QA processes

Frequently asked questions

Is a vibe-coded website safe to launch?

It can be, but only after testing. A simple marketing site needs much less than an app with logins and payments. If real users will trust it with their data, have a developer review it first.

Can the AI test its own work?

It can write and run tests, and that is useful. It should not be the only check, because tests written from the same assumptions as the code can pass while the assumption is wrong. Have a person run the access and payment checks.

Is a Supabase key in my front-end code a problem?

Not if it is the publishable or legacy anon key and your row level security rules are correct. A secret or legacy service_role key in front-end code is a serious problem and needs rotating straight away.

Do I need to know how to code to test an AI-built site?

Not for most of this checklist. You will need a browser's developer tools for a few rows, and they only take a few minutes to learn. Reviewing database rules and access control may need a developer.

Vibe Coding Testing: How to QA an AI-Generated Website

Know what kind of tool built it