How it works · v1.3 · 10 July 2026

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.

Part one
Measurement — what the engines actually say
The promise, deliberately narrow

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.

1. Query set design

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.

2. Three measurement tiers

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.
3. Headline metrics

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.

4. Seven layers, never a single score

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.

5. Reliability perimeter

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.

The cardinal rules

Five rules measurement never breaks

  1. No outcome guarantees. Anyone promising a ranking is selling something this methodology won't.
  2. Per-engine and per-tier, never blended.
  3. Discovery, not vanity — branded queries do not count toward visibility.
  4. Read the cited source before labelling a claim a hallucination. "Needs client confirmation" is a valid status.
  5. Trends beat snapshots. Topics beat prompts. Movement below the confidence interval is noise.
Part two
The fixer — from finding to live, safely
Measurement is only half the job

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.

6. Grounded truth

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.

7. Checked before you see it

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.

8. Human consent, enforced

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.

9. Safe by construction

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.

10. Delivery on your terms

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.

11. Proof, not promises

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.

The cardinal rules

Five rules the fixer never breaks

  1. Every fix traces to a finding. No generic busywork, ever.
  2. Only assert what you've confirmed. Uncertain corrections wait for your call, never auto-strip.
  3. The safety verdict is a lock, not a label. Blocked means blocked.
  4. Merge, never clobber. When in doubt, refuse and say so.
  5. 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.

Get my free snapshot