How we measure AI visibility — and fix it
Most tools hand you a dashboard and wish you luck. We do the whole loop: measure where AI engines get you right or wrong, write the actual fix, let you approve it, ship it to your site, and confirm it went live. This is the canonical methodology — the report, the code, and this page all derive from one document. If the code and the document disagree, the document wins.
What we measure, and what we don't
We show where AI answer engines include, recommend, cite, misunderstand, or ignore a brand, and what to fix first. We do not promise a ranking in any engine. No one credibly can.
100 verified queries, frozen for meaningful deltas
Each audit runs a fixed set of 100 queries per client, frozen on first generation. Re-runs use the identical set so month-over-month deltas mean something. Buckets:
- Category (40%) — "best expense tracker for freelancers"
- Problem (25%) — "I'm overpaying at the supermarket"
- Comparison (15%) — "Notion vs Airtable for small teams"
- Brand (10%) — sanity-check tier, never headline
- Longtail (10%) — narrow, specific, high-intent
An independent pass verifies every query for brand leakage, bucket fit, language match, and persona presence before it touches any engine.
API, Google AI Overviews, and the real ChatGPT
- Tier 1 · Developer APIs. Claude, ChatGPT, Gemini, and Perplexity. Each called with the country, region, and language of your audience, plus a system prompt that mimics a real user, not a developer.
- Tier 2 · Google AI Overviews. The AI answer at the top of Google search, Netherlands geo and language by default. Trigger rate reported separately from mentions. "No overview shown" is not "not mentioned".
- Tier 3 · Consumer ChatGPT. A logged-in ChatGPT session from a Netherlands IP, paced like a person typing. Screenshots ship as evidence. This is the differentiator. The developer API is a floor, not the truth.
Discovery rate, unbranded only
Discovery rate is the share of unbranded answers in which your brand appears. This is the AEO headline.
Brand recall is the share of branded answers where the engine recognises you. It sits close to 100% for known brands. Sanity check only. Never the headline.
Supporting metrics: citation rate (your own domain vs earned sources), share of voice on unbranded queries only, average position within listed results, five-way framing (recommended / listed / neutral / negative / hedged), and a hallucination ledger keyed against facts you supply.
Per-layer scoring beats a blended index
Eligibility · Presence · Preference · Citation · Accuracy · Consensus · Business impact. Per-layer only. A single blended index hides the diagnostic signal and multiplies noise. If Layer 1 (Eligibility) is broken, fixing Layer 3 (Preference) first wastes money.
What we know we don't know
Identical prompts vary 40–60% run to run. We report confidence intervals on every headline rate. Movement below 5 percentage points reads as noise, not signal. Developer-API answers and consumer-app answers diverge on 76% of brand mentions and 96% of cited sources. Every number in the report carries the tier that produced it.
Engines change without notice. Our monitoring exists because of that, not in spite of it.
Five rules measurement never breaks
- No outcome guarantees. Anyone promising a ranking is selling something this methodology won't.
- Per-engine and per-tier, never blended.
- Discovery, not vanity — branded queries do not count toward visibility.
- Read the cited source before labelling a claim a hallucination. "Needs client confirmation" is a valid status.
- Trends beat snapshots. Topics beat prompts. Movement below the confidence interval is noise.
We write the fix, you approve it, we ship it
A finding is worthless if nothing changes. So for every issue the audit surfaces — an engine inventing a price, a missing piece of structured data, a page you're invisible on — the platform drafts the exact change, shows it to you, and, once you approve, ships it to your site and checks that it went live.
Editing a live customer's website is a serious thing to automate. The entire fix engine is built to fail safe: it only acts on what you've confirmed, it checks every change before you ever see it, and it refuses rather than guesses. Here is exactly how.
Every fix is built from facts you confirmed — never invented
The fixer works from a short, plain-language record of what's true about you: your pricing, your real numbers, what you are and what you are not. You confirm this once. When an engine asserts something that contradicts it, we draft the correction.
The critical safeguard is what happens when a claim mightbe true. If the audit flags a number we can't find in your confirmed facts, we do not strip it — we hold it for your review and ask. A tool that deletes true content because its record was incomplete is worse than no tool at all.
Every fix passes a deterministic gauntlet first
Before a proposed fix reaches your queue it runs a set of byte-exact checks that don't depend on a model's mood:
- It will not republish a number the audit flagged as invented — anywhere in the fix.
- It will not paste marketing prose into a machine-read data field.
- Structured data is validated against Schema.org — correct types, required fields, no duplicate entities.
- Titles and descriptions stay within the limits search and answer engines actually read.
- A canonical URL must point at your own domain. An hreflang set must be complete.
A second, independent AI verifier reads each fix for tone and factual accuracy. A fix that fails any check is marked blocked — it is never quietly presented as ready to ship.
Nothing reaches your site without your recorded approval
You see the exact before-and-after and choose: approve, edit, or reject. The safety verdict is a hard lock, not a coloured label — a flagged fix cannot be approved without a deliberate override that is logged with your name and reason. Editing a fix re-runs the checks on your new wording. There is no silent path from our platform to your live site.
It merges, it never clobbers — and it refuses when unsure
The fixer adds to what you already have. It weaves a facts block into your existing AI-policy file instead of overwriting it. It rewrites the one wrong tag instead of stacking a duplicate beside it. It builds a real, readable page for an FAQ rather than hiding invisible markup.
And when it cannot place a change safely — an unfamiliar site framework, a file it can't confidently edit, exact text it can no longer find — it refuses and tells you why, rather than guessing. Fail-closed is the default, on every path.
A pull request on your repo, or a draft in your CMS
Connect your code and each approved fix arrives as a pull request you review and merge — the change lands through your own workflow, with your own reviews and checks in place. On a content platform, fixes arrive as drafts you publish. We never mutate a live site behind your back, and we never hold the keys to publishing — you do.
We check your real site and tell you the truth about it
After a fix ships we look at your actual live page — not a proxy, not our own copy — and confirm the change is really there. The status is honest: "pull request opened, awaiting your merge" is not "live," and we will never dress one up as the other. Every approved fix stays reversible; one click rolls it back, logged like everything else.
Five rules the fixer never breaks
- Every fix traces to a finding. No generic busywork, ever.
- Only assert what you've confirmed. Uncertain corrections wait for your call, never auto-strip.
- The safety verdict is a lock, not a label. Blocked means blocked.
- Merge, never clobber. When in doubt, refuse and say so.
- Ship through your workflow, verify on your real site, and keep every change reversible.
The full canonical document — with research citations, atomic claim decomposition, faithfulness scoring, knowledge-based trust, interval grounding, and the complete fix-safety specification — lives in the internal methodology playbook. Drop us a line at hello@farandwide.io if you want the long form before signup.