#We Analyzed 4,704 AI Visibility Audit Runs: What Static-Content and Rendering Checks Reveal

AI summary: Among 4,413 completed audit records, 2,283 (51.73%) scored below 50 for static content and 2,877 (65.19%) carried a Client-Side Rendering warning. These results describe Geolify audit records — not all websites — and do not prove citation loss.

Half of the pages audited through Geolify served thin first-response HTML. Two thirds triggered a Client-Side Rendering warning. Those two numbers come from 4,704 audit records in the Geolify snapshot dated 2026-07-10 (Geolify internal snapshot, MG-AUDIT-01, MG-AUDIT-02, MG-AUDIT-03).

If you read one paragraph and leave, read this one: fetch your highest-value page without JavaScript. Compare the raw HTML to the rendered DOM. If the content you want AI engines to cite is missing from the raw version, you have the same gap this benchmark measures.

The honest headline is narrow. This is a distribution of audit records, not a census of the web. A low score is a signal to investigate — not a verdict that your page is invisible.

#What the Dataset Is — and What It Is Not

The unit of analysis is the audit record — one run on one URL at one point in time.

State	Records	Share
Completed	4,413	93.81%
Failed	276	5.87%
Pending	15	0.32%

(Geolify internal snapshot, MG-AUDIT-01)

Every percentage below uses 4,413 completed records as its denominator. Failed and pending runs produced no final report.

Three framing rules matter before we look at the checks:

1. Records are not unique sites. One domain can generate many audit runs during testing, iteration, and re-checks. Reading 4,704 as a count of distinct websites is wrong.
2. An audit score is a product measurement, not a market outcome. A low static-content score describes what the check saw in your HTML. It does not mean a model refused to cite you.
3. This is a Geolify-specific sample. Strong for describing the audited population. Weak for generalizing to the entire web.

Keep those three rules in view. They separate an evidence-led benchmark from a scare statistic.

#Finding 1: Static-Content Scores Below 50

The static-content check measures how much meaningful content exists in the initial HTML response — before any JavaScript executes.

Result: 2,283 of 4,413 completed records (51.73%) scored below 50 on a 0-100 scale (Geolify internal snapshot, MG-AUDIT-02).

Roughly half the audited pages served thin first-response HTML.

Why does the first response matter? AI retrieval pipelines vary widely in whether they execute JavaScript. Some read the raw HTML and move on. Google states that its AI features in Search rely on the same underlying Search systems, with no additional technical requirements beyond standard Search fundamentals (Google Search Central). The rendering realities that shaped SEO still apply to GEO.

A page whose substance only appears after client-side hydration is betting that every consumer renders and waits. That bet fails more often than most teams realize.

What this does not prove: A score below 50 does not mean a page lost a citation or dropped in rankings. It means a non-rendering reader saw thin content. Treat it as a prompt to check your own pages.

#What a low score looks like in practice

Three patterns account for most low static-content scores in the audited records:

The application shell. The server returns a header, a footer, an empty root element, and a script bundle reference. Everything a reader would quote arrives later, over JavaScript. A non-rendering fetcher sees navigation and nothing else.

The skeleton screen. The initial HTML contains placeholder boxes and loading states. The layout is present; the substance is not. These pages score low because the check measures meaningful content, not markup volume.

The deferred answer. The page serves its opening paragraphs but loads the sections buyers care about — pricing tables, FAQs, comparison matrices — after interaction or on scroll. The score can hover near the threshold while the most citable content stays invisible to a static read.

Each pattern has a different fix cost. That is why the triage below starts with a diff, not a rewrite.

#Finding 2: Client-Side Rendering Warnings

The CSR check compares content present without JavaScript against content that appears after rendering.

Result: 2,877 of 4,413 completed records (65.19%) carried a Client-Side Rendering warning (Geolify internal snapshot, MG-AUDIT-03).

This is common and often intentional. Modern frameworks hydrate interfaces in the browser. For human users, that works fine. The risk is narrower: any consumer that skips JavaScript — or samples the raw response under a time budget — sees less than a person does.

The warning is a flag to check parity between raw and rendered output. It is not a statement that your page is uncitable.

Three questions to separate: Does the content exist in the initial HTML? If not, does it appear after rendering within a reasonable budget? And is the content you want cited present in the version a given consumer actually reads?

#How the Two Checks Relate

These overlap but are not the same signal.

A page can score well on static content yet still trigger a CSR warning if an important section loads late. A page can score low on static content without a CSR warning if it is simply thin.

In this dataset, the CSR warning is the broader signal (65.19% vs. 51.73%). Together, they describe a population where server-readable substance is frequently incomplete.

Triage approach: Treat the CSR warning as the question. Treat the static-content score as one answer. The audit flags the pattern. Your diff confirms the cause.

#What the Fixes Cost

Once the diff confirms a real gap, you have four engineering options. They differ sharply in effort and reach.

Option	Effort	Best for
Server-side rendering (SSR)	High	Application-shell pages where most content is dynamic
Static generation (SSG)	Medium	Articles, docs, landing pages that change on deploy, not per request
Prerendering / snapshotting	Medium	Existing SPAs where a framework migration is off the table
Content mirroring	Low	Moving only the critical copy — answer paragraphs, pricing, FAQs — into the initial HTML

Pick the smallest change that puts your citable content into the first response. A full SSR migration is rarely the first move. Mirroring the three paragraphs you actually want an AI engine to quote often closes most of the measured gap in days, not quarters.

Two rules keep this work honest. First, fix pages in order of business value, not audit-score order — a low score on a page nobody needs cited is accepted risk, not a ticket. Second, re-run the same audit after each change so every fix produces a before-and-after pair. Paired measurements are what turn an infrastructure sprint into evidence you can defend later.

#Cross-Reading with Citation Data

We pair the audit distributions with Microsoft Clarity AI Search Queries data for readability-and-rendering grounding queries:

• A readability-testing query recorded 31 citations at 20.39% citation share (Geolify internal snapshot, CL-AIQ-01)
• Two rendering-validation variants recorded 26 citations at 10.00% and 6 citations at 27.27% (Geolify internal snapshot, CL-AIQ-02, CL-AIQ-03)

These are per-query metrics. They are not global market share. Adding the two rendering-validation percentages would invent a number no export supports.

What they jointly suggest is a testable hypothesis: pages that keep substance in server-readable HTML are easier for retrieval systems to parse. That is a hypothesis, not a causal law.

You can replicate this cross-reading on your own property. Pick the three to five questions you most want AI engines to answer with your pages. Track citations for those exact queries on a fixed cadence, and keep each query's numbers separate. Per-query citation data next to per-page rendering data is the pairing that makes the hypothesis testable for your site — and it costs one spreadsheet to start.

#A Triage Workflow You Can Run This Week

Pick your highest-value pages. Run the test. Fix the gaps. Re-audit.

1. Inventory your money pages. Select 10-30 URLs that earn revenue, signups, or authority. Rendering work is expensive — spend it where retrieval matters.
2. Fetch each URL without JavaScript. Use curl or an HTTP client with a realistic user agent. Save the response body.
3. Diff static against rendered. Compare the saved body with what a full browser shows. Note which content blocks are missing from the static version.
4. Check crawler access first. A robots.txt rule blocking OAI-SearchBot or PerplexityBot will suppress retrieval regardless of rendering quality. Review access rules against each vendor's published crawler identities.
5. Fix the worst pages first. Server-side rendering, static generation, or prerendering for application-shell pages. Lighter fixes: move critical copy into the initial HTML without a full framework migration.
6. Re-audit and record the delta. Re-run the GEO Audit after each change. Paired before/after data turns benchmarks into evidence.

#Common False Positives

A reproducible test also means knowing when a warning is not a real problem. Three false positives recur:

Cookie or consent walls can strip content from an automated fetch while serving it to a real session. Test with the same conditions a reader experiences.

Geolocation or A/B routing can return a different variant to your test client. Pin the variant before comparing.

Genuinely interactive pages — live dashboards, configurators — will always show a large raw-versus-rendered gap. That is expected, not a defect. Ask whether the specific text you want an AI engine to quote is present in the static version. Ignore gaps that do not touch that text.

If a warning persists only on components no consumer needs to quote, record it as accepted risk and move on.

#How Agencies Should Present This Benchmark

If you run GEO engagements for clients, this benchmark is a door-opener, not a deliverable. Use it in three moves.

Open with the question, not the number. "What's your GEO Score?" starts the conversation the way an unaudited claim cannot. The benchmark shows why the question is worth asking: in the one population we can measure, half of completed runs served thin first-response HTML.

Replace the benchmark with the client's own audit in the first meeting. A client's 51.73% is meaningless; their own static-content score and rendering diff are billable findings. The benchmark justifies running the diagnostic. It never substitutes for it.

Report deltas, not snapshots, at the QBR. The number a stakeholder remembers is "static-content score up 22 points since March, verified by re-audit." Sample caveats stay attached — over-claiming from an internal benchmark is exactly the habit that erodes trust in this category.

Agencies that keep the denominators visible in client reports have an easier renewal conversation, because every number survives being challenged.

#Why These Metrics Are Safe to Publish

We deliberately do not combine the audit distribution with internal citation-query, traffic, or pageview data in this public report. Those metrics use different units, different windows, and different collection systems. Joining them would invite a causal story the evidence cannot support.

The two published audit metrics pass a stricter test. They are aggregated, contain no customer identifiers, use a stated denominator, and map to a test any reader can reproduce. They also describe a product diagnostic rather than Geolify's customer count, revenue, conversion rate, or current acquisition performance.

This distinction protects both readers and the brand. Public evidence should add decision value. It should not reveal operational scale merely because the number is available internally. Geolify therefore treats customer-level records, prompt inventories, provider failure rates, traffic volumes, and commercial outcomes as private unless a separate publication review approves them.

#Publishing Language You Can Defend

Safe public language:

• "Among completed Geolify audit records, 51.73% scored below 50 on static content."
• "These are audit records, not a census of all websites."
• "A CSR warning is a triage flag, not proof of lost citations."

Unsafe public language:

• "Most websites are invisible to ChatGPT."
• "Quy số bản ghi thành số website"
• "Fix rendering and your citations will rise by X%."

If a sentence needs a hidden footnote to stay true, rewrite the sentence.

#Frequently Asked Questions

Does a static score above 50 mean a page is safe? No. A page can clear the threshold while hiding its most valuable content — pricing tables, FAQs, comparison matrices — behind client-side interaction. The score orders your triage queue. The page-level rendering diff decides what actually gets fixed.

Can I benchmark my site against these distributions? Directionally, yes. Precisely, no. The sample is self-selected. Your tech stack may differ from the mix of sites whose owners run GEO Audits. The better comparison is your site against itself: re-run the same audit after each fix and track your score over time.

Should agencies quote these numbers to clients? Only with the sample caveat attached — and only next to the client's own audit results. The benchmark justifies running the diagnostic. It does not substitute for it.

#What This Evidence Does Not Establish

To keep the record straight:

• No estimate of what share of all websites have static-content or rendering problems. The sample is self-selected audit runs.
• No causal link from a low score or CSR warning to lost AI citations, traffic, or revenue.
• No guarantee that fixing rendering produces citations. Google states there are no special technical requirements for its AI features beyond Search fundamentals.
• No population-level percentage of "AI-invisible" websites.

#Limits and Caveats

Three limits bound this report. The population is Geolify audit records, so conclusions describe audited pages — not the open web. The checks are point-in-time: a warning today can clear tomorrow after a deploy. And correlation is not causation.

Source checks were performed on 2026-07-10 against Google Search Central, OpenAI crawler docs, Perplexity crawlers, and llmstxt.org.

Use the numbers as a map of where to look. Then let your own before-and-after measurements decide what to fix.

#What to Read Next

• AI Crawler Readability and Rendering Validation Test Protocol — expands the fetch-render-diff test into a full verification protocol.
• The LLMS.txt Optimization Checklist — covers content-map hygiene for AI engines.
• What Is GEO — the conceptual foundation for Generative Engine Optimization.

#Audit Run Distribution Summary

Field	Value	Correct Interpretation
Audit records	4,704	Runs/records, not unique websites (MG-AUDIT-01)
Completed	4,413	Denominator for score and warning rates
Failed	276	Not scored in the completed distributions
Pending	15	Incomplete; exclude from completed rates