What 58 Full Website Audit Runs Found, and What the Scores Cannot Tell You

The audit repository contains 715 generated artifacts. That does not mean 715 websites were audited. A separate prospect file contains 951 rapid-scan records. That does not mean 951 full audits were completed. Counting output files as engagements would make the number larger and the evidence worse.

The defensible inventory: 58 directories contain saved full-audit JSON, 46 sites appear in the completed ranked output, and 70 PDFs were generated because some sites received both full and summary editions. A separate 951-site local prospect pool received a lighter automated triage.

This article reports the 58 saved runs, including incomplete sections. Seven are this consultancy’s own or client-associated builds; they are part of the working corpus, not independent buyers. The set is a convenience sample assembled for operating and outreach work in August 2026. It is not a random sample of all small-business websites and should not be presented as one.

The aggregate result

Section	Completed results	Median	Range
Overall weighted score	58	68	48–99
Mobile Lighthouse performance	55	54	10–100
Desktop Lighthouse performance	55	87	34–100
Accessibility	55	88	53–100
Security posture	58	53	12–100
AI-visibility foundations	47	66	14–94
Conversion-path presence	45	50	0–100

Source: saved audit.json files under the audit corpus, generated August 2026. Medians were recalculated across non-null section results on September 2, 2026.

The central pattern is unevenness. The median desktop performance score was 87 while mobile was 54. Accessibility was comparatively strong at 88 while security posture was 53. These sites were not universally “bad.” They had specific control gaps that a blended adjective would hide.

Why the denominator changes

Three Lighthouse runs did not produce a usable performance or accessibility result. Eleven runs did not produce a scored AI-visibility section. Thirteen did not produce a conversion-path score.

The pipeline records a failed or skipped section as null/error. It does not convert a tool failure into a zero for the website. The overall score renormalizes the fixed weights across sections that actually returned a score.

That choice makes cross-site comparisons less neat but prevents a timeout from becoming a claim about a business.

Mobile was the clearest performance gap

Among the 55 completed Lighthouse pairs:

• Median mobile performance: 54.
• Median desktop performance: 87.
• Lowest mobile result: 10.
• Highest mobile result: 100.

The gap matters because a desktop score can make a site appear technically healthy while customers experience the mobile path differently. The audit does not infer the percentage of mobile customers or revenue consequence. Analytics and actual conversion data must supply that bridge.

A performance score also does not identify the business priority by itself. A slow page with no qualified traffic may deserve less immediate attention than a fast page whose contact form routes to the wrong inbox.

Security posture was usually incomplete, not catastrophic

The security section checked:

• HTTP-to-HTTPS behavior.
• TLS certificate validity.
• Six browser security headers.
• Mixed-content references.
• Version-disclosure signals.
• A limited set of exposed-path probes.
• Safe Browsing status where available.

The median was 53 across all 58 runs. That is a posture score for the checks above, not a penetration test and not a declaration that a site was breached.

Missing headers are common and usually straightforward to verify. An expired or mismatched certificate has a different customer consequence. The report keeps findings separate so the grade does not flatten unlike risks into one vague warning.

The most common content and machine-readability failures

Fifty-one runs completed the underlying foundational checks. The most frequent failures were:

Check	Failed	Share of completed checks
Heading structure	39 of 51	76%
Valid llms.txt	39 of 51	76%
Meta-description coverage	32 of 51	63%
Identifiable schema types	31 of 51	61%
Open Graph basics	30 of 51	59%
Image-alt coverage	29 of 51	57%
Structured data present	28 of 51	55%
RSS or Atom feed	27 of 51	53%
Single-H1 check	25 of 51	49%
Canonical URL	20 of 51	39%

These percentages are arithmetic from the saved results, rounded to the nearest whole percent.

They do not establish that adding llms.txt, schema, or metadata will produce rankings or AI citations. They establish only that the observed page did or did not expose the checked element.

What “AI visibility” means in this audit

The section combines deterministic foundations with labeled heuristics:

• Clear title and meta description.
• Canonical URL.
• One H1 and coherent heading structure.
• Structured data and identifiable types.
• Internal links and readable content depth.
• Image-alt coverage.
• Indexability switches.
• AI crawler access in robots.txt.
• RSS and llms.txt presence.

It does not query a model hundreds of times, calculate citation share, or claim that a crawler’s access equals inclusion. The recorded score is a readiness signal, not an outcome metric.

Actual search inclusion requires Search Console. Actual AI citation presence requires a defined prompt set, repeated observation, and a method that acknowledges model variation.

Conversion-path presence was half complete

Across 45 completed homepage presence checks, the median was 50. The individual failures were:

• Meta Pixel absent: 37 of 45.
• Google Business Profile or Maps link absent: 33 of 45.
• Homepage lead form absent: 23 of 45.
• GA4 or GTM absent: 21 of 45.
• Click-to-call absent: 15 of 45.
• Clear CTA wording absent: 7 of 45.

This section is intentionally called presence, not conversion quality. A page can have a form that never reaches the owner. It can have GA4 installed without a useful conversion event. It can have a phone link nobody answers.

The correct next step is to test the whole path: click, submit, receive, respond, attribute, and close.

The finding that changed the outreach policy

Automated checks initially flagged some ordinary http:// hyperlinks as mixed content. On inspection, they were outbound links, not insecure page resources producing a browser warning. The claim was removed from outreach drafts and the checker was corrected.

That episode is more useful proof than pretending the pipeline never failed. Automated findings are candidates for human verification. A finding that a recipient can disprove in one minute can damage the credibility of every accurate finding beside it.

What the corpus proves

It proves that:

• The audit pipeline ran across dozens of real sites.
• The system produces reproducible section evidence and reports.
• Missing measurements are preserved as missing.
• Aggregate patterns can be calculated from the saved data.
• Human review caught and corrected an overbroad automated claim.

What the corpus does not prove

It does not prove that:

• 600 full client audits were delivered.
• The sample represents all small-business websites.
• A higher score causes more revenue.
• A missing metadata element causes lower rankings.
• Every generated PDF was sent or purchased.
• The outbound system converted the corpus into customers.

As of September 2, 2026, the formal send log contained no data rows. At that point, the production gap was distribution, not another audit.

How to use an audit commercially without abusing it

1. Verify the highest-consequence finding manually.
2. State exactly what was observed and when.
3. Separate a technical condition from its possible business consequence.
4. Ask for analytics or operating evidence before assigning revenue.
5. Recommend the smallest correction that resolves the condition.
6. Re-test the same path after the change.

An honest audit may conclude that the website is not the most valuable problem. That conclusion protects the owner from buying the wrong fix.

The audit-method proof page publishes the section definitions and quality rails in a shorter buyer-facing format. The fixed-price website health and repair offers remain separate from the operating diagnostic because a website finding and a business-model finding are not the same engagement.