AI Website Audit: What Automated Checks Catch and Miss

An AI website audit reads your public pages the same way every time, so it is good at repeatable checks: broken links, dead buttons, a main button hidden on a phone, a headline the rest of the page disagrees with. It cannot tell you whether your claims are true, whether the tone fits your customers, or what happens behind a login. Run it first, then add a person for what is left.

If you built your site with an AI tool, you probably want a second opinion before customers see it. The useful question is not which kind of review is better. It is which questions each one can answer.

What is an AI website audit, and how is it different from a human review?

It is software that opens your live public pages, looks at what a visitor would see, and reports against a fixed list of questions. The result is usually a score and a list of fixes.

A human review is a person doing the same job by hand. They open the site, try to get something done, and notice how it feels.

Ours is the first kind. No person reads your app: an AI scores it against a fixed list of questions, which is why it comes back in minutes. That fixed list is the strength and the limit: every site gets the same questions, and only a public page's answers count.

What does an automated audit actually do on your site?

Here is what ours does, taken from how the product works today.

• Reads the page the way a visitor gets it. It looks at the rendered page plus desktop and mobile screenshots. Public pages only: it sees what a customer sees at your link, and nothing behind a login.
• Clicks through. It follows public pages and buttons, and may submit your forms once with clearly labeled test entries. That is why the site asks you to confirm you own it or have permission to test it.
• Scores six areas. Each area gets a "What works" note, a "Slop tells" note, and top fixes ranked by impact.
• Gives a verdict. The report carries a one-line label, such as "Real product".
• Checks for AI generator fingerprints and reads competitor pages. The comparison uses real pages the audit fetched, and it points out where others explain themselves better than you do.

What does an automated audit catch well?

Anything repeatable. A tool does not get tired, and it does not forget to check the phone version.

• Dead ends. Links that fail and buttons that do nothing. A tool can click through your public links and buttons far faster than you can by hand, and it writes down which ones failed. It also writes down what it did not finish, which matters, as the next section shows.
• Trust basics. Whether a visitor can find a way to reach you and read your policies.
• The phone view. Under Mobile and Access, whether something on the small screen stands between the visitor and your main action.
• Mixed messages. Under Clarity and Promise, whether your opening lines and the rest of the page tell the same story.
• Generator leftovers. The fingerprint check looks for the defaults that AI builders leave behind, and the report says so when it finds none.
• Consistency. Every site gets the same questions, so you can see whether a fix moved a score.

What did a real run find, and what could it not settle?

The audit ran on our own site, ismyappslop.com, on 28 September 2026. It scored 92 out of 100 with the verdict "Real product". The recorded evidence shows 6 pages crawled, 21 links checked (0 broken), and 9 buttons clicked (0 dead). The lowest score was Mobile and Access, at 75.

The reason: the report says the cookie banner (the small notice asking about tracking) is overly large on mobile and obscures the main call-to-action button when the page first loads. The "Where to start" panel puts the fix first: shrink the banner's height on mobile.

The same report is just as useful for what it would not claim:

The "Opt out" line is the lesson. The click happened, but nothing visible followed, and a visitor-level read cannot tell "nothing happened" from "it worked quietly". So the report does 2 honest things at once. It treats the missing response as a usability problem worth fixing, and it labels the underlying question "not confirmed" and leaves it open for someone who can look.

The unclicked pages are a second reminder. A tool is fast, but it works inside a time limit, and a good report lists what it skipped.

What do automated audits miss?

Whether a claim is true. A tool can see that a price is shown. It cannot know that the price is right, or that "trusted by" has anyone behind it. If a ranked fix suggests adding a customer counter or a testimonial line, use it only with a real number or a real quote.

Fit. A page can pass every check and still sound wrong for your buyers. Only someone who knows your customers knows the words they use.

Anything that happens after the screen. Whether a saved setting stays saved, whether the receipt email shows up an hour later, whether the payment goes through.

Real-world variety. One run is one snapshot. web.dev makes this point about speed measurement (page updated 18 July 2022, read 5 October 2026): a lab test loads a page in a controlled setup with set network and device conditions, while real visitors arrive on many devices and networks and behave in many ways. See web.dev on lab and field data. The same caution fits any single automated read.

What does a human review add, and where does it fall short?

A person brings judgment. They read your page as a first-time visitor and ask 3 plain questions: do I understand this, do I trust it, and do I know what to do next? They notice awkward moments that technically work, like wording that sounds off.

People have their own limits. A person is slower and costs more, and 2 people notice different things. Friends are polite. Someone who knows your product well skips the confusing parts without realizing it. That is the case for letting the audit go first: it clears the repeatable problems cheaply, so the human time goes to what only a human can judge.

How do you combine both without doing the work twice?

1. Run the audit on your live public URL. Not a staging link, and not a page behind a login.
2. Read the verdict and the lowest-scoring area first. Our report points to its first ranked fix, so you start in one place instead of reading everything.
3. Check each top fix yourself. Open the page and repeat the click, on a real phone as well as a laptop.
4. Sort what you find into 3 piles: confirmed, could not reproduce, and "not confirmed". The third pile, plus any pages the report says it did not finish, is your list for anyone with access to the settings, the code, or the payment setup.
5. Fix the confirmed ones one at a time. That way you can tell which change did what.
6. Then put it in front of a person, with one job to do and you staying quiet.
7. If you changed a lot, audit again. Compare the new report with the old one.

To read a report well, see our guide on what a good audit report includes. For the walkthrough in step 6, see our website UX audit guide.

When do you need more than an audit and a few testers?

When the stakes outgrow what a public page can show. That includes taking payments, holding private customer data, working in areas such as health or money, or going in front of press or investors.

Then bring in the right specialist: a security reviewer, an accessibility specialist who works with disabled users, a developer for the code, or a lawyer for legal questions. Our audit does not replace a security review or a full accessibility audit, it is not legal advice, and a score is never a certificate of anything. What it does well is tell you what a visitor meets on day one, and which fix to make first.