Check an AI-built website: what to look for

The preview shows the page, not what the server sends

The builder shows you the page as your browser renders it, once everything has loaded. That is what a visitor who lands on the homepage sees. It is not what a crawler reads when it downloads the page without running its scripts, nor what happens to someone following a link to a deleted page, nor what the browser sends to third parties while the page renders.

Prompts to a site builder are about what you can see: copy, sections, colors. A security header, a legal notice or a consent banner that actually blocks trackers doesn't show up in the preview. They live in the server's responses, in the files that get published and in what leaves the browser during a visit, and that is where they need to be checked.

The near-empty shell search engines receive

When the builder produces a JavaScript app, the server may send little more than an empty shell and some scripts. The browser then builds the text, the title, the description and the canonical URL, the one search engines should keep. Google's JavaScript SEO documentation explains that pages wait in a rendering queue before they are indexed, and that if Google finds a noindex tag in the page as sent, it may never run the JavaScript that would remove it.

So have the raw server response compared with the rendered page, on the homepage at least: in this kind of app the tags usually come from one shared template, and what is wrong on one page tends to be wrong on the others. The canonical URL and the noindex tag should be present and identical on both sides, and sit in the head of every page. When they differ, or only the browser adds them, a search engine may keep the wrong version. Our guide on JavaScript SEO explains what Google does with these pages.

Also have someone check what a URL that doesn't exist returns. When the host serves the same page for every URL and lets the script decide what to show, an unknown page answers "200", like a real one, with an error message drawn on screen. The same Google documentation has a section on these errors in single-page apps, and the guide on soft 404 errors explains why the status code matters.

If robots.txt or the sitemap is missing, both can be added without touching the site. Tags built in the browser and the wrong status code mean reworking the app itself: that is a project for whoever maintains the code, along with the list of affected pages.

Keys, source maps, libraries: code any visitor can read

Every script a page loads is public: any visitor can read it. The keys that connect the site to its services are visible there as soon as someone puts them in the front-end code.

Some keys have no business being there: a payment provider's secret key, a cloud account access key, an access token, a private key. If one of them is there, treat it as known: have it replaced, not just deleted from the code. Keys that are public by design, such as a payment provider's publishable key, are meant to be read.

Source maps link the minified code served to visitors back to the original code, with its folder structure and comments. They are a development aid; published with the site, they hand anyone the code as it was written. Ask for them to stay off the live site.

Generated code also pulls in libraries written by other people, at whatever version was picked the day the app was generated. When vulnerabilities are published later for that version, they stay in the code served until someone updates the library. Ask who keeps those updates going once the site is live.

Security headers depend on the host more than on the builder: a generated site inherits the settings of the platform that publishes it. So the question goes to that platform, or to whoever manages the hosting: does the site send HSTS, which keeps the browser on HTTPS, and a Content Security Policy (CSP), which limits the scripts a page can run? Our guide to HTTP security headers covers what each one protects.

Legal notice, trackers, hosting: what the builder couldn't know

If your business is established in the EU, your website must say who runs it and who hosts it. A site builder doesn't know your company name, your registration number or your host's details, so that information stays missing until you provide it. Check that the page exists, that the site links to it and that it carries every required detail; the guide on EU website imprint requirements lists them.

An analytics tag, a font loaded from a third-party service, an embedded map or video each take one prompt to add. They can set a cookie or send the visitor's IP address as soon as the page renders, before the visitor has answered the consent banner, if there is one. Having a banner isn't enough: what counts is what leaves before the visitor answers, and that shows on a page loaded without a single click.

A site builder publishes the site on the hosting it picked, and may wire it to the services it integrates: database, email sending, analytics. Know who those providers are, which country they operate from and which law applies to them. A server located in Europe doesn't settle the question, and our guide to the CLOUD Act's reach explains why.

Also ask what you would take with you if you left. The two samples we publish show both cases. The report on a B2B business website, built with the no-code builder Webflow, notes that the site runs on a hosted platform and that moving away means a partial rebuild. The one on an online store, a custom application, rates it portable from one host to another. Moving to another host or database is a project, best decided once you know what the site depends on: that is the question the hosting and vendor dependency audit answers.

Keys first, then whatever doesn't touch the app

The order follows two questions: what exposes you most, and what can be fixed without reworking the app.

1. Get the published site checked by someone outside the project, before you send traffic to it or right after launch, and get the results in writing, page by page.
2. If a secret key shows up in the public code, have it replaced without waiting.
3. Fix what doesn't mean touching the app: the legal notice, blocking trackers until consent, robots.txt and the sitemap.
4. Hand whoever maintains the code the fixes that mean reworking the app: tags only the browser builds, the status code for unknown URLs, published source maps, libraries to update.
5. Have what can't be seen from outside, such as the access rules on your database, checked separately by someone with access to the project.
6. Choose your host and connected services knowing their country and the law they answer to, then have the site checked again once the fixes are in.

The same flaws, whatever the tool

These percentages cover about 30 websites we audited between August 14, 2026 and September 24, 2026. Each one counts only the sites where the point could be checked. Many were audited because a defect showed up quickly, so these figures describe our audits, not websites in general.

These figures don't separate sites by how they were built: none of these flaws is specific to AI site builders. They are the ones no preview shows, whatever the tool.

In the online store we publish as a sample, the main script includes axios 1.7.7, a library with 30 published vulnerabilities, 15 of them high or critical. The report notes that a single update removes them all. The check can also return the other verdict: in both published reports, no secret and no source map turned up in the code served.

No builder access, no code: the URL is enough

An AI-built website gets the same review as any other, an audit across 9 pillars: security and encryption, performance, SEO, accessibility, compliance and privacy, domain and network, independence and resilience, content and trust, user experience and reliability. Checklists for AI-built sites mostly cover the copy, the forms or the security of the code. The audit reads the published site, and every point on this page ends up in the same report.

Every analyzed page is loaded in a browser. On the reference page, usually the homepage, the server's response before any script runs and the rendered page are kept from a single visit, and the tags that decide indexing are compared; on every page, their place in the head is checked. A made-up URL is requested, and the status code recorded. The scripts the analyzed pages load are downloaded, with their libraries and versions, and searched for keys that should never reach the browser, leaving out keys that are public by design. The page is opened without a single click, to record what has already been stored and what has already gone out to third parties. Each layer is traced to its provider, its country and the law it answers to.

For every finding, the report names the page and the value observed, and you can hand it, unedited, to whoever takes over the site. The audit covers what can be observed from outside the site. Every limit of the review is stated in the report, and a point that couldn't be verified is never presented as compliant. The EU compliance and data transfer checks apply to businesses established in the EU, the EEA, the UK or Switzerland: for others, the report records what it observed without counting it against the score. If someone built the site for you, the guide on checking web agency work covers that case.

Plans start at €200 excl. VAT; only the number of pages analyzed and the price change. They are listed on the pricing page. The report is delivered in 5 working days up to 60 pages, payment collected on delivery. Before you order, you can read the sample reports, taken from two real audits.