An AI builder can produce a convincing homepage, signup flow, dashboard, or checkout remarkably quickly. That visible result is useful, but it is not the same as a production-ready website.

A real launch decision needs evidence. You need to know who controls the code and accounts, whether private data stays private, whether the critical journey works outside the happy path, whether search engines can index the right pages, and whether someone can detect and reverse a bad release.

This checklist is for a founder or business owner with an existing AI-built website or web app. It works whether the first version came from Lovable, Bolt, Replit, v0, Cursor, another AI-assisted workflow, or a mix of generated and manually written code. Those names describe possible tools, not affiliations or guarantees.

The short answer: should you launch?

Use three outcomes instead of a vague readiness score.

Decision	Meaning	Minimum evidence
GO	The agreed launch scope has no open critical blocker.	Critical journeys pass, access is controlled, recovery exists, production monitoring works, and the owner accepts the documented lower-priority limitations.
CONDITIONAL	Launch is possible with explicit limits.	No critical blocker is open; every accepted issue has an owner, deadline, workaround, and reason it does not expose users, data, payments, or the core business journey.
NO-GO	Stop and fix before exposing real users or data.	Any critical journey is broken, authorization is unverified, secrets are exposed, production ownership is unclear, or no tested recovery path exists.

Do not average a serious failure into a high score. A beautiful site with nine passing sections and one exposed database is still a no-go.

If the project already has a public URL, start with the free AI website audit. It can collect public SEO, performance, indexing, mobile, trust, and conversion evidence. It cannot log into private accounts, prove database permissions, inspect unshared source code, or certify security and accessibility compliance.

How to use this checklist

Create one launch record with five columns:

Check	Result	Evidence	Owner	Fix or accepted limitation
Example: contact form	Pass	Test submission ID and received email	Marketing owner	—
Example: mobile checkout	Fail	Screen recording on iPhone Safari	Developer	Fix tax error before launch

Run the checks against the production domain or a production-like environment. “The AI said it is fixed” is not evidence. Useful evidence includes a test account, screenshot, screen recording, request log, analytics event, Search Console inspection, performance report, pull request, backup restoration record, or named account owner.

Classify each check:

P0 — launch blocker: user safety, access, data, payments, ownership, recovery, or the main business journey.
P1 — fix before meaningful traffic: mobile, accessibility basics, indexing, analytics, performance, trust, and important failure states.
P2 — improve after launch: polish that does not block use, measurement, recovery, or informed consent.

1. Confirm ownership and recovery access — P0

Write down who controls each asset:

Domain registrar and DNS.
Hosting or deployment platform.
Source repository and its organization account.
Database and file storage.
Transactional email and SMS services.
Analytics, Search Console, and tag manager.
Payment provider, if applicable.
Builder workspace and any connected third-party account.

The business should not depend on an inaccessible personal account or an AI-builder session that nobody can recover. Export or synchronize the code when the platform supports it, document the production branch, and confirm that another authorized person can reach the necessary accounts.

Pass evidence: an ownership sheet, authorized account list, repository access, and a recovery method tested by someone other than the original builder.

No-go examples: nobody controls the domain login; production exists only inside a former contractor’s account; the code cannot be exported and the owner did not knowingly accept that dependency.

2. Create and test a rollback or restore path — P0

A backup is useful only if it can be restored. Before launch:

Identify the last known good application version.
Back up production data using the platform’s supported process.
Record how a deployment is rolled back.
Test restoration in a safe environment where practical.
Define who can authorize a rollback and who performs it.

Generated code can change many files while solving one prompt. Version control and a reviewable change set make it possible to see what changed and return to a working version.

Pass evidence: a tagged release or commit, backup timestamp, restore or rollback steps, and a named owner.

No-go example: the only recovery plan is asking the same AI tool to regenerate the previous behavior.

3. Remove exposed secrets and separate environments — P0

API keys, database credentials, private tokens, signing keys, and service-account credentials must not be shipped in browser code or committed as plaintext. Development and production should not casually share privileged credentials or a database containing real customer data.

The OWASP Secrets Management Cheat Sheet recommends controlled storage, least-privilege access, rotation, auditing, and tested backup/restore procedures for secrets.

Check:

Browser bundles and page source for keys or credentials.
Repository history, not only the current file.
Build logs and error messages.
Environment-variable configuration in hosting.
Whether exposed keys were revoked and rotated rather than merely deleted from the latest commit.

Pass evidence: secret scanning plus a list of production credentials, their storage location, access scope, and rotation owner.

No-go example: a privileged API or database key is visible in client-side JavaScript.

4. Test authentication and authorization separately — P0

Login proves identity. Authorization decides what that identity is allowed to read or change. A user who successfully logs in must not automatically gain access to another user’s records, admin actions, storage objects, or hidden API routes.

OWASP’s Authorization Cheat Sheet makes the distinction explicit: authenticated users are not necessarily authorized for every resource or action.

Create at least these test roles when the product uses accounts:

Signed-out visitor.
Ordinary user A.
Ordinary user B with different records.
Staff or admin role.
Suspended, expired, or deleted account where relevant.

Try to access another user’s resource by changing an ID, URL, request body, or storage path. Test authorization on the server or data layer, not only by hiding buttons in the interface.

Pass evidence: a permissions matrix and repeatable tests showing that each role can perform only its intended actions.

No-go example: user A can read or modify user B’s data by changing a request parameter.

5. Complete every critical journey with real test data — P0

List the shortest journeys that create business value. Examples:

Visit service page → submit enquiry → receive confirmation → lead reaches the correct inbox or CRM.
Create account → verify email → sign in → complete first useful action.
Add product → checkout → payment result → order confirmation → operations receives the order.
Book appointment → select availability → confirm → receive notification → staff sees the booking.

Run each journey on the production-like environment using test data. Check the user-facing outcome and the back-office result. A green success message is insufficient if the email, CRM record, order, or booking never arrives.

Test duplicate clicks, refreshing after submission, going back, an expired session, and a second attempt. These reveal duplicate records, double charges, and confusing states that a happy-path demo can hide.

Pass evidence: a dated test case with the front-end result and matching back-office record.

6. Test integrations and failure states — P0 or P1

Third-party services fail, slow down, reject a request, or return unexpected data. Test what the user sees when:

Email delivery is delayed or rejected.
A payment is declined, cancelled, or succeeds after the page times out.
An API rate limit is reached.
The database returns no result.
A webhook arrives twice or out of order.
A file upload is too large or uses an unsupported format.
The network disconnects during an action.

The interface needs an honest state: retry, save progress, contact support, or explain that the action did not complete. It must not show success when the underlying operation failed.

Pass evidence: test logs or recordings for the expected success path and important failure paths.

7. Test mobile and target browsers — P1

Do not approve the launch from one desktop preview. Test the real site on representative devices and browsers used by the target audience.

At minimum, review:

Header, navigation, modals, and cookie controls.
Forms with the on-screen keyboard open.
Tables, dashboards, long text, and error messages.
Touch targets, sticky buttons, and horizontal overflow.
Portrait and landscape where the product needs both.
Slow or unstable mobile connectivity.

MDN’s cross-browser testing guidance recommends testing stable browsers, keyboard navigation, and real mobile platforms, then expanding based on the browsers important to the actual audience.

Pass evidence: a device/browser matrix with results for the critical journeys, not only screenshots of the homepage.

8. Check accessibility basics with humans and tools — P1

Automated checks catch useful problems, but they do not prove full accessibility. Perform a short manual review:

Navigate the main journey using only a keyboard.
Confirm visible focus and a logical focus order.
Check that form controls have programmatic labels and understandable errors.
Give meaningful images useful alternative text and decorative images empty alt text.
Avoid using color alone to communicate status.
Check headings, landmarks, link purpose, zoom, and text contrast.
Try a screen reader on the critical journey if the team has the capability.

Use the WCAG 2.2 Quick Reference to connect findings to the relevant success criteria and techniques. If the product has contractual or legal accessibility obligations, obtain an appropriately scoped specialist review rather than treating this checklist as certification.

Pass evidence: automated results plus a dated manual keyboard/form review and named limitations.

9. Measure performance on mobile — P1

Test the production URL, not only a builder preview. Look for oversized images, excessive JavaScript, layout shifts, slow fonts, blocked rendering, and third-party scripts that delay the main experience.

The current Core Web Vitals guidance defines the recommended “good” thresholds at the 75th percentile as:

Largest Contentful Paint (LCP): 2.5 seconds or less.
Interaction to Next Paint (INP): 200 milliseconds or less.
Cumulative Layout Shift (CLS): 0.1 or less.

Lab tests are useful before launch; field data needs real eligible visits and may not exist yet. Record both without presenting an empty field report as a pass.

Pass evidence: a production mobile performance report, known constraints, and a plan for collecting field data after launch.

10. Verify crawlability, indexability, and canonical URLs — P1

For public pages intended to appear in search:

Return a useful 200 response for the canonical URL.
Remove accidental noindex directives and staging authentication from public pages.
Make sure robots.txt does not block pages or important resources that need crawling.
Use one self-referencing canonical for each preferred public page.
Redirect obsolete duplicates deliberately.
Link important pages through crawlable navigation or contextual links.
Include preferred canonical URLs in the XML sitemap.
Inspect the live URL in Search Console after deployment.

Google explains that robots.txt controls crawling and should not be used as the mechanism for preventing indexing; use noindex or access controls for that purpose. Its technical SEO guidance also recommends using URL Inspection to see what Google receives. Google’s sitemap documentation says to list fully qualified canonical URLs you want considered for search.

Pass evidence: response status, rendered HTML, canonical, robots/meta directives, sitemap entry, internal link, and a live URL inspection.

11. Review content, trust, and business information — P1

Replace generated filler with approved facts. Check:

Business name, location, contact details, and service area.
Prices, availability, delivery times, and product details.
Testimonials, client logos, certifications, and statistics.
Author or company identity where trust matters.
Privacy, terms, returns, cancellation, and consent language appropriate to the actual business.
No leftover prompts, placeholder names, demo records, fake counters, or unsupported claims.

Do not ask AI to invent proof or legal policies. A generic policy copied from another business may not describe the data, payments, jurisdiction, or process of this product. Obtain qualified legal advice where the launch has regulatory or contractual requirements.

Pass evidence: content-owner approval and a list of every claim that depends on external proof.

Every important public page needs a clear title, description, one descriptive primary heading, and a social preview that represents the page. Check the real shared URL in the channels that matter to the launch.

Structured data must describe visible, current content. Google’s general structured-data guidelines warn against hidden, irrelevant, misleading, or incomplete markup and do not guarantee a rich result even when markup is valid.

Verify:

Canonical URL and language information.
Open Graph title, description, image, and image dimensions.
Favicon and application icons.
Relevant JSON-LD types with required properties.
Rich Results Test where the chosen type is supported.
No fake review, offer, FAQ, organization, or product data.

Pass evidence: rendered metadata, a social share preview, and structured-data validation that matches the visible page.

13. Prove analytics and conversion events — P1

Installing a tag does not prove that useful actions are measured. Define the small set of events needed to judge the launch:

Lead or contact submission.
Checkout start and purchase where applicable.
Account registration or activation.
Booking completion.
Important error or failed action when it can be measured responsibly.

Confirm that each action fires once with the intended parameters and that test or internal traffic is handled according to the measurement plan. Google’s current GA4 troubleshooting guidance recommends DebugView, Tag Assistant, and browser network requests for immediate verification.

Also test consent behavior and whether analytics still respects the business’s privacy implementation.

Pass evidence: DebugView or realtime event evidence tied to the exact test journey, plus the report or conversion definition that will use it.

14. Add monitoring, useful errors, and an incident owner — P1

After launch, someone needs to know when the system fails. Decide:

Which application, server, database, email, payment, and integration errors are logged.
Which failures trigger an alert.
Who receives it and during what support window.
What information is safe to include without logging secrets or personal data unnecessarily.
How the team distinguishes a user mistake from a system failure.
Where users can report a problem.

Use a test error to confirm the monitoring path. A dashboard nobody checks is not an alerting system.

Pass evidence: one controlled test error reaches the named owner with enough context to investigate and no exposed secret.

15. Write the launch and first-24-hours runbook — P0 or P1

Record:

Release version and deployment owner.
DNS or environment changes.
Smoke tests to run immediately after deployment.
Rollback trigger and steps.
Who monitors forms, payments, signups, logs, and performance.
How customer-facing incidents will be communicated.
When the team reviews the launch record again.

Immediately after release, repeat the critical journey on the real domain, inspect analytics, check logs, test contact routes, verify the sitemap and robots directives, and confirm that the previous version can still be restored if necessary.

Pass evidence: a dated runbook completed by named people, not a plan stored only inside an AI conversation.

Copyable final launch record

Use this compact record for the decision meeting:

Area	Priority	Result	Evidence link or record	Owner	Due date
Ownership and recovery	P0
Backup and rollback	P0
Secrets and environments	P0
Authentication and authorization	P0
Critical journeys	P0
Integrations and failure states	P0/P1
Mobile and browsers	P1
Accessibility basics	P1
Performance	P1
Search and indexing	P1
Content and trust	P1
Metadata and structured data	P1
Analytics	P1
Monitoring	P1
Launch runbook	P0/P1

Final decision: GO / CONDITIONAL / NO-GO
Decision owner:
Decision date:
Accepted limitations:
Next review:

What AI can help with—and what it cannot prove

AI can help generate test cases, summarize logs, draft a permissions matrix, explain a performance report, or turn findings into tasks. It can also miss context, accept a superficial fix, or report success without observing the real production result.

Use AI to accelerate preparation and analysis. Keep the evidence outside the conversation:

A real request and response.
A real account with the correct role.
A real mobile device.
A real performance measurement.
A real analytics event.
A real backup restoration or rollback.
A human owner who accepts the launch decision.

Do not paste production credentials, private keys, customer data, or confidential source material into an AI tool unless the approved data-handling rules explicitly allow it.

When should you involve a developer?

Professional review becomes more important when the project handles payments, customer data, multiple user roles, private files, external integrations, regulated information, custom business logic, or meaningful paid traffic.

Ask for help before launch when:

You cannot explain where authorization is enforced.
You do not know whether a key is public or privileged.
The project has no repository, backup, or rollback path.
The main flow works only in the builder preview.
Failures create duplicate payments, orders, messages, or records.
Search, analytics, or production hosting is outside your experience.
You are relying on repeated prompting without a repeatable test.

This does not mean the entire project must be rebuilt. A responsible review separates what can be kept, what needs repair, and what genuinely requires replacement.

For a public first pass, run the AI website audit. For an existing business website with performance, indexing, or technical SEO problems, review performance and technical SEO implementation. If the project is really a portal, workflow, dashboard, or integration product, use the custom web application scope.

AI website pre-launch questions

Is an AI-built website safe to launch after it passes an automated audit?

No automated public audit can prove complete security or inspect every private behavior. It can identify useful public evidence and blockers. Private code, accounts, permissions, data rules, integrations, and recovery still require scoped verification.

Do I need a developer for a simple AI-built landing page?

Not always. A low-risk page with approved content, a working contact path, controlled accounts, analytics, mobile testing, and no sensitive application behavior may be manageable without a custom build. The decision changes when the site handles money, accounts, private data, or custom integrations.

Can I launch with some checklist items incomplete?

Only when no P0 blocker remains and each accepted limitation has an owner, due date, workaround, and documented reason it does not endanger users, data, payments, recovery, or the core journey. That is a conditional launch, not a full pass.

Does passing Core Web Vitals guarantee rankings?

No. Core Web Vitals measure important aspects of page experience; they do not guarantee indexing, ranking, traffic, or conversions. Content relevance, competition, links, trust, technical accessibility, and other systems still matter.

Should I submit the site to Google before or after these checks?

Publish and submit the canonical production URL only after it returns the intended content, allows indexing, appears in the sitemap, and has passed the launch checks relevant to the page. Then use Search Console URL Inspection for the priority URL and monitor indexing rather than repeatedly requesting it without changes.

Your next step

Start with evidence you can collect now. Run the free AI website audit on the exact production URL you plan to share. Use the report for public SEO, performance, indexing, mobile, trust, and conversion findings, then add the private access, authorization, data, integration, and recovery checks from this guide.

If the result is NO-GO or the private checks are outside your capability, send the project for review with the stack, current URL, main blocker, repository availability, and target launch date. Do not send credentials through the public form.

Next step

Plan the next step with performance and technical seo

Website performance optimization and technical SEO covering Core Web Vitals, images, JavaScript, crawlability, metadata, schema, and indexing signals.

Review performance and technical seo