Skip to content
Back to Blog
Denver SEOlocal SEOSEO auditsmall business websiteDeepAudit AIJavaScript SEOweb accessibilitytechnical SEO

We Audited 56 Denver Business Websites. Here Is What the Scan Found.

Joshua R. Gutierrez6 min read

We scanned 56 Denver business websites with DeepAudit, the browser-based auditor we built and use on client work.

Where they came from: we queried the OpenStreetMap Overpass API for businesses within an 18-kilometer radius of the Denver city center that publish a website, dropped national chains and aggregators, deduplicated the domains, and scanned the surviving homepages. Sixty candidates, 56 complete audits. This is a purposive sample, not a census of Denver and not a random one. Every percentage counts hard failures only.

The median was 70 out of 100. The mean was 65.2. Nine sites scored below 40, which is DeepAudit's critical tier and not an industry definition of anything. Twenty-six of the 56 came in under 70.

The findings landed across several unrelated layers: accessibility, structured data, content length, security headers, headings, and external prominence. That matters, and we will come back to it, because our first instinct was to explain all of them with one story and the story was not supported by the data.

Every audited page triggered an accessibility failure

All 56 of them. Forty-one triggered the visible-focus rule.

A visible focus indicator is what tells someone tabbing through a page which link, button, or field will respond next. Remove it, or make it invisible against the design, and using the page without a mouse gets much harder.

This is a focus-indicator check, not a full accessibility audit and not a keyboard test. It tells you where manual keyboard and screen-reader testing should start.

It also does not tell you what caused the failure. React, WordPress, a hosted builder, and hand-written HTML can each be built accessibly or badly. Removing a focus outline is a styling decision, not a consequence of choosing a framework.

llms.txt was absent on 41, and that is not an AI-visibility score

Forty-one of the 56 sites had no llms.txt file.

That is file presence and nothing more. It does not mean these businesses are illegible to ChatGPT. AI systems draw on crawlable page content, search indexes, maps, reviews, directories, and press coverage, none of which require this file. llms.txt is a proposed convention, not an established protocol, and our later research found most of these files are emitted automatically by a platform or plugin rather than written deliberately.

There is no evidence that adding one file "puts a business in AI answers." We did not ask a single assistant to recommend a Denver business, so this post cannot tell you who gets named.

The findings we cannot pin on JavaScript

An earlier version of this post gathered the rest of the results under a heading called "the JavaScript tax," and argued that Denver's React-heavy, app-style sites were the cause. It is a tidy story. We did not measure it.

Here is what we actually collected:

  • Low Open PageRank: 34 of 56. A third-party proxy built from an open web-link graph, not Google's PageRank. Nothing about it is caused by a frontend framework.
  • No HSTS header: 31 of 56. An HTTP security header. It has nothing to do with whether the frontend uses React.
  • Primary heading failed: 31 of 56. Our rule fails a page for having no H1 or more than one, and multiple H1s are not automatically a defect, so this count is stricter than it should be. We are fixing the rule.
  • No JSON-LD structured data: 29 of 56. Google can process structured data generated by JavaScript, so this is not a rendering verdict either.
  • Under 300 words: 29 of 56. And this is the one that gave the old story away. The earlier post called this "thin or client-rendered content." It is not. It is the word-count check, full stop. This scan never compared raw HTML against the rendered DOM, so it produced no client-rendering measurement at all.

Missing backlinks, a missing security header, an unclear heading, and a short page can occur on any platform, in any framework. Grouping them under one fashionable explanation made the report easier to summarize and less useful to act on.

We also never detected which sites used React, which were single-page applications, or which client-rendered their important content. Without that, the JavaScript claim was a stereotype about Denver wearing the clothes of an analysis.

The study we should run instead

The JavaScript hypothesis is worth testing. It is just not tested here.

Doing it properly means detecting the platform and rendering architecture for every site, then comparing the initial HTML against the rendered DOM, and reporting accessibility findings and content loss by architecture: static HTML, server-rendered React or Next.js, client-rendered SPA, WordPress, hosted builders, custom. With counts and intervals, not city stereotypes.

We have run that raw-versus-rendered comparison before, on 368 small-business sites nationally, where one in four lost an answer-critical element in the initial HTML. We have not run it per city, and until we do, "Denver has a JavaScript problem" is a guess.

What this sample tells us, and what it does not

Across these 56 Denver sites, accessibility, structured-data, content, security, heading, and prominence rules fired repeatedly. Fixing the real ones produces clearer, safer, more accessible websites.

The scan does not establish that Denver's small-business web fails to live up to the city's tech reputation. It does not predict rankings, AI citations, leads, or revenue. And it does not identify a single common cause, which is exactly why we stopped claiming one.

The audit gives us a list of places to investigate. The explanation still has to be earned.

Check your own site

Run the free audit on your own site. No signup, no credit card, and the report is yours to keep.

Then verify it. When it flags focus visibility, tab through your own site with the keyboard. When it finds no schema, check your visible business details against your Google Business Profile first. And if you want to know whether your content survives without JavaScript, view the page source and look for it there, because the score will not tell you.

The tool can show you what happened. It cannot invent the cause.

If you would rather we read it with you, book a free 15-minute teardown and we will walk through what it found, live, no pitch.

Related services

Joshua R. Gutierrez, SEO Engineer, Axion Deep Digital

Written by

Joshua R. Gutierrez

SEO Engineer, Axion Deep Digital

SEO strategist and full-stack engineer who builds the audit tooling, then does the work. Technical SEO, Core Web Vitals, and content systems for SaaS and B2B.

View full profile & credentials →

Ready to build a website that performs?

Let us audit your current site, identify the biggest opportunities, and build a plan to grow your traffic and leads.