How to check an AI-built website before launch

Choose tools by what you need to verify

For a public marketing site, start with PageSpeed Insights for performance, WAVE for accessibility observations and Mozilla HTTP Observatory for HTTP security configuration. Use your builder's security review for code and configuration it can inspect. For a site with accounts, bookings or payments, add tests of the real user journeys and a separate permission review. These checks complement one another; a public URL scanner cannot inspect every private route or database rule.

1. Public page quality: PageSpeed Insights, WAVE and Mozilla HTTP Observatory.
2. Builder code and configuration: review the current project security findings. Lovable documents these in its Security view.
3. Real interactions: test manually first; use Playwright when repeatable browser tests are needed.
4. Private permissions: have an authorised reviewer inspect the application rules and test allowed and denied access with test accounts.

Check the published URL, not only the builder preview

Open the production domain on a real phone and desktop browser. Check important pages, navigation, images, contact information and the main call to action. A preview and a published site can differ in environment settings, redirects, email delivery and search directives. Record which deployment you tested so a later builder change does not silently replace your baseline.

1. Check the homepage and each important service or product page.
2. Follow links from an ordinary visitor's starting point.
3. Confirm the mobile menu, readable text and visible keyboard focus.

Test whether the enquiry or purchase actually completes

Submit an authorised test enquiry and confirm it arrives at the intended destination. A thank-you message alone does not prove delivery. For bookings or purchases, use the service's supported test environment and verify the confirmation and resulting record. Do not make real charges or send messages to customers as part of a check. Include failed and cancelled paths as well as the successful journey.

Review performance, accessibility and public security evidence

Run the independent tools against the exact published URLs. Save the URL, time, finding and supporting observation. WAVE can identify accessibility errors and support human evaluation; it cannot certify complete accessibility. Check the site with a keyboard and review important forms manually. Mozilla Observatory assesses HTTP headers and security configuration, which is a different scope from testing application authorisation or proving that a website is secure.

Keep private application testing private

If the site stores account or customer information, ask an authorised reviewer to test what a signed-out visitor, an ordinary test user and an administrator can access. Check the real rules on the server and data layer, not only whether a button is hidden. Review secrets and dependency findings through the project's security tools. Keep private routes blocked from crawlers. Never weaken login or data permissions to improve an audit score.

Where AuditHQ fits

AuditHQ provides a broader review of public website signals with recorded evidence and prioritised findings. The free Quick Scan samples six result categories in about 60 seconds, with no signup required. A Full Audit covers nine suites where applicable and typically takes about 30 minutes. The catalogue is not a promise that every check runs on every site. AuditHQ does not log into your application, submit its forms, review all private source code or automatically implement fixes. Use it alongside the journey and permission checks above.

Give your builder one finding at a time, then retest

Start with broken core journeys and confirmed exposure of private information. For each accepted finding, retain the affected URL or test environment, the observed behaviour, the expected result and the verification step. Share only redacted evidence. Ask the builder to explain the proposed change and its scope. After deployment, repeat the original check and a nearby user journey; a changed score alone is not proof that the problem is resolved.

Finding: [what you observed]
Location: [public URL or authorised test environment]
Expected result: [what should happen]
Evidence: [redacted observation and time]
Verify after the change: [repeatable check]
Owner and status: [person and next step]

Frequently asked questions

Turn website findings into an action plan

Create an account to start a Full Audit of your website, with supporting evidence and a prioritised action plan.