Five failure tests for an AI-assisted website audit

Procora — Sat, 31 Oct 2026 18:56:08 +0000

Disclosure: This article was generated with AI assistance for Procora. The tests below are design examples, not a claim that a particular production system has passed them.

An AI-assisted website audit has two jobs: collect evidence and explain useful next steps. Testing only the happy path makes it easy for missing data to become a confident claim. These five tests focus on that boundary.

1. A failed fetch must not become a missing-title finding

Arrange an HTTP timeout for one URL. The collector should record a collection failure, with the URL and attempt time. The report should say that the page could not be checked. It must not say the title or heading is absent, because no usable HTML was observed.

A separate fixture with a successful HTML response and no title should produce a missing-title finding. These outcomes need different identifiers and display states.

2. An unconnected private source must not show zero traffic

Run a public crawl with no authorised Search Console property. The search-data component should show “Not connected,” not zero clicks or impressions. Then test a connected property whose API request fails: that state should be “Unavailable,” not a successful measurement.

For a successful request, retain the source, property, date range and retrieval time. If a successful response contains no rows, describe the requested period and the provider's response; do not expand it into “this business has no demand.”

3. Unknown evidence references must fail validation

Give the analysis step an evidence set containing E1 and E2. Return a recommendation citing E99. The renderer should reject that reference or mark the recommendation as unsupported. A fluent explanation must not create its own evidence.

Illustrative validation logic:

Build the set of known IDs from collected evidence.
Require each recommendation to cite at least one evidence ID.
Reject any cited ID outside that set.

This check validates the reference, not the truth of the explanation. Also compare quoted observations with the original record and flag assumptions for review.

4. Public sharing must not expose private measurements

Create a public website report and a separate, authorised private workspace. Request the public report while private metrics exist. The public response must exclude those metrics, account identifiers and tokens. Test access control on the server; hiding a card in the browser is insufficient.

5. Screen and PDF must preserve the same limits

Use an audit fixture covering ten sampled pages of a larger website. Confirm that both views identify the sample, collection time and unmeasured areas. If a provider is unavailable, both outputs should retain that status. Exporting should not convert partial coverage into a whole-site claim.

What to assert

For each test, assert both the stored result and the user-facing wording. Keep “observed,” “recommended” and “not measured” separate. Add idempotent retry tests for transient failures so a retry does not duplicate findings or overwrite a successful observation with an unexplained empty state.

A report is useful when a reader can locate the affected page, understand the evidence, assign a fix and verify the outcome. A decorative score cannot substitute for those steps.

Procora offers an AI-assisted website audit for small businesses. Explore the public website audit. This article presents a general testing approach; it is not an independent audit of Procora.