Guide · launch checklist

Website launch checklist: 30 checks for AI-built sites

A website launch checklist covers six areas: core journeys, forms, links, mobile layout, accessibility, and SEO and analytics basics. Run it on the published URL, not just the builder preview. This pre launch website checklist has 30 checks for sites built with Lovable, Bolt, v0, Cursor or by hand, and marks which ones a tool can verify and which need a person.

Facts checked October 21, 2026

How to use this website QA checklist

Work through the six groups in order. The first groups cover what breaks a visit outright: a signup that never finishes, a form that swallows messages, a link that ends in an error. The later groups cover what makes a site harder to use or harder to find. Every item is tagged Automatable in Sybqa when Sybqa’s browser run checks it, or Manual when a person or another tool has to look.

Three habits make the list worth more than a quick click-around:

Using an AI builder? The vibe testing workflow turns one checklist item into a defined outcome, a useful fix handoff and an equivalent retest. Read the example QA report before starting a run.

Test the published domain. Builder previews often run with different environment variables, auth settings and data. Visitors only ever see the published site.
Use a fresh, signed-out browser. Your own session hides signup problems, cached assets and permission mistakes.
Keep the evidence. A screenshot, the URL and the steps for each problem make the fix and the re-check faster. Items you could not test are not passes; write them down as open.

1. Core journeys

Pick the one thing the site exists for (sign up, buy, book or send a message) and test it first, start to finish, at a phone width. A break on that path costs the most.

Core journey checks
Check	What to look for	Who checks it
The main action	A new visitor can finish the one task the site is for, from the homepage to the confirmation screen.	Automatable in Sybqa, as a journey in a plan you review before it runs.
Signup and login	A new account can be created, the expected confirmation appears, and you can sign out and sign back in.	Automatable in Sybqa, as a journey. Paid runs can use a throwaway signup that is deleted afterwards.
Checkout or booking in test mode	The payment or booking step completes with test data and shows the right total and confirmation.	Automatable in Sybqa with your test-mode keys only. A real live payment stays Manual.
Refresh and back button	Reloading mid-flow or pressing back does not lose what the visitor typed or land them on an error.	Automatable in Sybqa. Follow-up checks reload mid-flow and go back and forward.
Auth redirect URLs	After signup, email confirmation and password reset, the visitor lands on the published domain, not localhost or a preview URL.	Manual. Check the allowed redirect URLs in your auth provider, then confirm with a real signup.

2. Forms

Forms are where AI-generated code most often looks finished but is not wired up. Submit each one with good data, bad data and nothing at all.

Form checks
Check	What to look for	Who checks it
Required fields	Submitting an empty form is refused and the visitor is told which fields are missing.	Automatable in Sybqa, as journey steps with assertions you approve.
Error messages	Bad input shows a clear message next to the field, and the message is tied to that field for screen readers.	Automatable in Sybqa. A checklist rule checks that errors are associated with their fields.
Success state	Valid input shows a confirmation, and the form does not silently reset or hang.	Automatable in Sybqa, as a journey assertion.
Long and unusual input	Very long text, emoji and pasted markup do not break the layout or the page.	Automatable in Sybqa. A follow-up check enters long, emoji and markup values.
The email actually arrives	Confirmation, password reset and contact-form notifications reach a real inbox and their links work.	Manual. A browser run cannot see your inbox; send one of each yourself.

3. Links and navigation

Broken links are cheap to find and embarrassing to ship. Redirects matter too: Google treats a permanent server-side redirect as a strong sign of which URL should show in results.

Link and navigation checks
Check	What to look for	Who checks it
Internal links	No link on the site ends in a 404, an error screen or a blank page.	Automatable in Sybqa. Page checks record HTTP errors and error screens on the routes they reach.
External links	Links to other sites, app stores and social profiles go to the right place.	Manual. Sybqa stays on your domain and does not follow links away from it.
404 page	A made-up URL shows a helpful not-found page and returns an HTTP 404 status, not 200.	Manual. Open a made-up URL and check the status in your browser’s network tab.
One canonical host	`http` goes to `https`, and `www` and the bare domain redirect to one version with a permanent (301) redirect.	Manual. Type each variant into a fresh browser and confirm where it lands.

For the tools that cover the manual rows here, from link crawlers to uptime monitors, see the best pre-launch website testing tools.

4. Mobile and layout

Most AI builders preview at desktop size. Many visitors arrive on a phone. Check the narrowest common widths, not just the one your laptop shows. The responsive design testing guide explains what each width catches.

Mobile and layout checks
Check	What to look for	Who checks it
No sideways scrolling	The page does not scroll horizontally at phone widths.	Automatable in Sybqa. Overflow is checked at 1440, 390 and 320 px.
Reflow at 320 px	Content still reads in one column at 320 CSS pixels wide, without losing information.	Automatable in Sybqa. A follow-up check covers WCAG 1.4.10 Reflow.
Tap targets	Buttons and links are large enough, or spaced enough, to hit with a thumb.	Automatable in Sybqa. A checklist rule covers WCAG 2.5.8 Target Size, approximating its spacing exception.
Nothing cut off or overlapping	Text, images and buttons are not clipped, stacked on top of each other or hidden off screen.	Automatable in Sybqa with AI review on paid plans. Treat AI findings as leads to confirm.
Sticky bars and banners	Cookie banners, chat widgets and sticky headers do not cover buttons or the main content on a phone.	Manual. Scroll each key page on a real phone.

5. Accessibility

Accessibility checks catch problems that also hurt everyone else: low-contrast text, unlabelled fields, images that carry meaning with no description. Automated rules find some of these reliably; others need a person. The automated accessibility testing guide explains where the line falls.

Accessibility checks
Check	What to look for	Who checks it
Text contrast	Body text meets 4.5:1 against its background (3:1 for large text), as WCAG 2.2 success criterion 1.4.3 sets out.	Automatable in Sybqa. Journey steps measure contrast, and axe-core runs in the page.
Alt text	Images that carry meaning have a text alternative; decorative images are marked as decorative.	Automatable in Sybqa for missing alt text through axe-core. Whether the text is useful stays Manual.
Form labels	Every field has a visible label that stays visible while typing, not just placeholder text.	Automatable in Sybqa. A checklist rule checks persistent visible labels.
Page language and title	The page declares its language and has a title that says what it is.	Automatable in Sybqa. Both are WCAG rules axe-core runs.
Keyboard and focus	You can reach every control with Tab, see where focus is, and close dialogs with Escape.	Manual. Screenshots do not prove keyboard behaviour; unplug the mouse and try.

6. SEO and analytics basics

None of these stop a visitor, so they are easy to skip. They decide whether search engines index the right pages and whether you can tell what happened after launch. Google Search Central documents each one.

SEO and analytics checks
Check	What to look for	Who checks it
Title and meta description	Each page has its own descriptive title tag and meta description, not the builder’s default.	Manual. View the page source of each key page.
Canonical URL	The canonical tag points at the published URL on your one canonical host, not a preview or staging address.	Manual.
robots.txt and noindex	`robots.txt` does not block the site, and no page you want found still carries a `noindex` tag from staging.	Manual. Google notes that robots.txt is not a way to keep a page out of results; use noindex for that.
sitemap.xml	A sitemap lists your live pages and is submitted in Google Search Console.	Manual.
Social preview and favicon	Open Graph title, description and image render when the link is shared, and the favicon shows in the tab.	Manual. Paste the link into a chat app or a preview tool.
Analytics and consent	Your analytics records a page view on the published domain, and only after consent where your cookie banner requires it.	Manual. Load the site in a fresh browser and watch your analytics live view.

AI-builder gotchas to check before launch

Sites built with Lovable, Bolt, v0 or Cursor fail in a few predictable ways. None is a reason to avoid these tools; each is a reason to test the published site rather than trust the preview.

Preview and production use different settings. Environment variables are usually set per environment, so an API key or URL that works in the preview may be missing on the published site. Vite, which many AI builders use, exposes only variables prefixed with VITE_ to browser code, and anything exposed that way is visible to every visitor.
Auth redirects still point at the preview. Supabase, for example, only redirects to URLs on its allow list. If the published domain is not listed, signup confirmation and password-reset emails send visitors to the wrong place.
Database rules were never switched on. Supabase says Row Level Security must be enabled on tables in exposed schemas, and that the secret or service-role key must never be used in the browser. A browser run cannot prove these rules are right; review them against your own users and roles.
Placeholder copy shipped. Visible {{name}}, undefined, NaN, lorem ipsum or a “Your Company” footer. Sybqa’s placeholder rule fails on unresolved template tokens, [object Object], undefined, NaN and %s when the reviewed plan includes it. Lorem ipsum and fake company names still need a read-through.
A demo or test mode is still on. Test payment keys, seeded demo accounts or a “coming soon” gate left enabled. Check your settings, then do one real signup on the live domain.

The Lovable launch testing guide goes deeper on builder tests versus a check of the published site.

Run it on every deploy, not just launch day

A launch checklist passes once. The next prompt to your AI builder can undo any line of it. The automatable rows are the ones worth repeating on every release: journeys, forms, links, layout at phone widths, contrast, labels and touch targets.

Sybqa can run the same reviewed plan on every pull request and compare each run with the previous one on the same site, so you see regressions and recoveries rather than one long list. See run website QA on every deploy for the setup, and the website QA report example for what a report contains. The manual rows (email delivery, redirects, SEO tags, keyboard use) are worth a short re-check whenever you change domains, auth settings or templates.

Copyable website launch checklist

The same 30 checks as a plain list. Copy it into your issue tracker or notes.

Journeys: the main action works end to end, signed out, at phone width.
Journeys: signup, sign out and sign back in work.
Journeys: checkout or booking completes in test mode.
Journeys: refresh and back button do not lose progress.
Journeys: auth redirects land on the published domain.
Forms: required fields are enforced.
Forms: errors are clear and tied to their fields.
Forms: valid input shows a success state.
Forms: long, emoji and markup input does not break the page.
Forms: confirmation, reset and contact emails arrive.
Links: no internal link ends in a 404 or error screen.
Links: external links go to the right place.
Links: a made-up URL shows a 404 page with a 404 status.
Links: http, https, www and bare domain resolve to one host with 301s.
Mobile: no sideways scrolling at phone widths.
Mobile: content reflows at 320 px.
Mobile: tap targets are large enough.
Mobile: nothing is cut off or overlapping.
Mobile: sticky bars and banners do not cover content.
Accessibility: text contrast meets 4.5:1.
Accessibility: meaningful images have alt text.
Accessibility: every field has a visible label.
Accessibility: the page declares its language and has a title.
Accessibility: everything works by keyboard with visible focus.
SEO: every page has its own title and meta description.
SEO: canonical tags point at the published URL.
SEO: robots.txt allows crawling and no stray noindex remains.
SEO: sitemap.xml is live and submitted in Search Console.
SEO: social preview and favicon render when the link is shared.
Analytics: page views record on the live domain, after consent where required.

Common questions

What should be on a website launch checklist?

Six groups of checks: core journeys (the main action, signup, checkout), forms (validation, errors, success, email delivery), links and navigation (broken links, 404 page, redirects), mobile layout (overflow, reflow, tap targets), accessibility (contrast, alt text, labels, keyboard) and SEO and analytics basics (titles, canonical, robots.txt, sitemap, analytics). Run them on the published URL.

How do I test a website before launch?

Open the published site in a fresh, signed-out browser at phone width and complete the one task the site exists for. Then work through forms, links, layout, accessibility and SEO basics, keeping a screenshot and steps for anything that fails. A tool like Sybqa can cover the automatable rows; email delivery, redirects, SEO tags and keyboard use still need a person.

What is the difference between website QA and a Lighthouse score?

Lighthouse scores a page load against performance, accessibility, best-practice and SEO audits. Website QA works through journeys in a real browser and checks whether a visitor can actually sign up, submit a form or read the page on a phone. They answer different questions; see Lighthouse and PageSpeed vs website QA.

Can an AI-built site pass a launch checklist without manual testing?

Not completely. Automated checks can cover journeys, forms, broken internal links, layout at phone widths, contrast, labels and touch targets. They cannot prove that emails arrive, that redirects and SEO tags are right, that the site works by keyboard, or that database rules keep one user’s data from another. Plan a short manual pass for those.

How much does website QA cost?

Sybqa’s free plan gives 10 runs a month without AI review after you sign up, with no card needed. Sybqa Starter is $19 a month with 500 AI credits, about 15 to 29 full AI checks depending on site size, and a top-up adds 250 credits for $9. See pricing for the current plans.

Sources

Try Sybqa on your site

Explore bugs, UI consistency and user journeys from a reviewed plan. Inspect browser evidence and visual review leads in the report. The free plan gives 10 runs a month without AI review after you sign up. See pricing.

Test my site Create a free account