The MentionAudit Methodology

Every audit runs these passes in order. Some run in parallel, some sequentially, with the dependency graph enforced by the orchestrator.

Pass	Name	What it does
0	Brand Profiler	Brand classification and alias graph construction
0.5	SERP Features	Pre-flight extraction of classical SERP features
1	SERP Extraction	Per-prompt SERP capture
1.5	Multi-Engine Analysis	Run each prompt across every supported AI engine
1.75	Engine Diagnosis	Per-engine result classification
2	Strategy	Recommendations grounded in audit findings
2.5	Verification	Recommendation soundness check
3	Sentiment	Per-engine sentiment of brand mentions
3.5	Competitive	Tracked-competitor deep dive

That is the spine. Below each pass, we explain what we capture, what we abstract, and why.

Before any prompts run, the audit needs an unambiguous representation of the brand. The Brand Profiler builds it.

What it captures verbatim:

• The user-supplied brand name and primary domain.
• Any explicitly user-supplied aliases.
• Public WHOIS-grade domain registration data where available.

What it abstracts:

• The full alias graph: brand name variants, abbreviations, parent companies, subsidiaries, product lines under the brand, historical names, and likely confusions (e.g., "Pipeline" the project tool vs "pipeline" the noun).
• A brand classification: market category, whether the brand is consumer or B2B, rough size class (startup, mid-market, enterprise), and any vertical specialization signals.

The alias graph is the foundation of every subsequent pass. If the brand profiler misses an alias, every later pass will systematically under-count brand presence in engine answers. The brand profiler is conservative: it adds aliases only with high confidence, and it lets the user edit the alias list explicitly before the rest of the audit runs.

Pass 0.5 runs in parallel with Pass 1 and pulls per-prompt SERP feature data: People-Also-Ask blocks, Knowledge Graph entries, Featured Snippets, related searches, and other SERP-feature signals that bear on AI Overview eligibility and classical organic context.

What it captures verbatim:

• Raw SERP feature payloads from the SERP API.
• The full set of competing entities present in SERP features for each prompt.

What it abstracts:

• A normalized "SERP context" record per prompt that downstream passes use to interpret AI engine results in their classical-search context.

This pass is what lets us tell brand teams "your brand is in the People-Also-Ask block on this prompt, but absent from the AI Overview" — the data on both sides is captured at audit time.

Pass 1 captures classical SERP results per prompt: organic positions, the URL set, the title and meta-description for each result, and any rich-result structures present.

What it captures verbatim:

• The first-page organic URL set for each prompt.
• Title and meta-description per URL.
• SERP rich-result structures (rating cards, sitelinks, etc.) where present.

What it abstracts:

• The "competitive set" — the union of distinct domains appearing on the first page across the prompt set, ranked by appearance frequency. This is later used to anchor the competitive-deep-dive pass.

The reason we capture classical SERP at audit time, even in a GEO audit, is that AI engines depend on classical search signals. A prompt where your domain is invisible from the first SERP page is a prompt where Google AI Overviews are unlikely to cite you, regardless of any other GEO work. Classical context is necessary input to GEO interpretation.

This is the heart of the audit. Pass 1.5 runs each prompt across every supported AI engine and captures the rendered answer.

The supported engines in 2026:

• Perplexity
• ChatGPT
• Claude
• Microsoft Copilot
• Google Gemini

In addition, we capture Google's AI surfaces (AI Overviews, AI Mode where the locale is supported) through SERP-API integrations.

What it captures verbatim, per engine, per prompt:

• The full rendered answer text, byte-for-byte.
• The full citation list (URLs and any per-citation metadata the engine surfaces).
• Engine response metadata: model identifier where exposed, response timing, and any short-circuit reasons (rate limits, refusals, locale-unavailable conditions).

What it abstracts:

• Brand presence detection per engine using the alias graph from Pass 0.
• Per-engine citation classification: which cited URLs are on user-owned domains, on tracked-competitor domains, or on third-party domains.
• A "presence + citation" matrix: did the brand appear in the answer body, was the brand cited as a source URL, were both, or neither.

The byte-for-byte capture is the foundation of every customer-facing claim downstream. If the audit later says "ChatGPT cited you on this prompt," the user can read the exact ChatGPT response and verify. There is no opaque scoring step between engine output and what the user sees.

Pass 1.5 produces raw answers. Pass 1.75 classifies them.

For each (engine, prompt) pair, the diagnosis answers:

• Did the engine produce a substantive answer, or did it short-circuit?
• If short-circuited, why? Empty answer, refusal, locale not supported, rate-limit or quota exhaustion, or transient error?
• If substantive, was the brand mentioned, omitted, or contested (mentioned by name in a list of alternatives)?
• Were there citation patterns worth flagging — your competitors heavily cited and your brand absent, or your brand cited only on its own promotional pages, etc.?

What it captures verbatim:

• A per-prompt diagnosis record with the engine's short-circuit reason (where applicable) and the structured classification.

What it abstracts:

• The per-engine "diagnosis context" handed to Pass 2 (Strategy) so recommendations are grounded in what the engines actually did, not in what an off-the-shelf model thinks they should have done.

The diagnosis pass is what prevents recommendations from being generic. If Perplexity short-circuited on a prompt because the user's locale is not yet supported by Google AI Mode, we say so — we do not recommend "improve content for Google AI Mode" as a fix.

Pass 2 generates recommendations. The recommendations are grounded in:

• The diagnosis records from Pass 1.75 (what each engine actually did per prompt).
• The brand alias graph from Pass 0 (so recommendations refer to the right entity).
• The classical SERP context from Pass 1 (so recommendations are realistic given current ranking).
• The verbatim answer text from Pass 1.5 (so recommendations cite specific quotes when relevant).

What it captures verbatim:

• Each recommendation is anchored to specific (engine, prompt) pairs in the audit data.

What it abstracts:

• The recommendation's priority, expected impact category, and implementation guidance.

We deliberately keep the recommendation set tight. Brand teams that read recommendation lists pull from the top — a list of 50 recommendations gets the top 5 implemented and the rest ignored. We aim for fewer, higher-conviction recommendations grounded in specific audit evidence.

Pass 2.5 verifies each recommendation against live data before it is shown to the user. For each proposed action, we re-check that the underlying gap still exists — a recommendation written 30 seconds ago against engine output captured 20 seconds before that should still be valid, but the verification pass exists so that downstream agents (diagnostic intelligence layer, executor agents) running on cached data know which recommendations are still grounded.

What it captures verbatim:

• The verification result: confirmed, partially confirmed (the gap moved but is still actionable), or invalidated.

What it abstracts:

• A confidence label on each recommendation that surfaces in the UI.

Pass 3 reads every brand mention in every captured engine response and classifies its sentiment: positive, neutral, negative, or contested (different engines disagreeing about the same brand).

What it captures verbatim:

• The exact passage (sentence-level) where each brand mention occurs, per engine.

What it abstracts:

• A per-engine, per-prompt sentiment label.
• An aggregate sentiment summary across the audit.

Sentiment is one of the audit signals that brand teams find most surprising. Your brand can be mentioned in 90% of AI engine answers on a category and the mentions can be neutral-tilting-negative, in which case the visibility win is hollow. The verbatim passage capture is what makes the sentiment claim auditable — we show the exact sentence the engine produced.

Pass 3.5 is the tracked-competitor deep dive. For each tracked competitor (configured by the user), we re-walk the captured engine responses and produce a head-to-head matrix:

• Per (engine, prompt), where did the competitor appear, where did our brand appear, who was first-mentioned, who was cited.
• Per competitor, their cited URL set across the audit (which is a direct read of the citation graph the engine has built around them).
• Per competitor, the URLs they appear at that we are absent from — the citation gaps.

What it captures verbatim:

• The full set of cited URLs per competitor across the audit.

What it abstracts:

• A "competitor citation profile" that summarises where each competitor wins and where the gap is closeable.

The deliberate methodology principle: capture verbatim, abstract sparingly, and always link the abstraction back to the verbatim capture.

Specifically:

• Verbatim: Every engine answer, every cited URL, every short-circuit reason, every brand-mention passage, every classical SERP feature snapshot.
• Lightly abstracted (with verbatim links): Brand presence detection, citation classification (own/competitor/third-party), sentiment label, diagnosis classification.
• Heavily abstracted (presented as conclusions): Recommendations, competitor profiles, the audit's overall scoring.

The abstraction layers are what make the audit usable. The verbatim layer is what makes the audit auditable. Brand teams can always drill from any summary metric down to the engine output that produced it.

To set expectations:

• We do not edit, paraphrase, or "clean up" engine output. What the engine said is what we captured; if it contained errors, those errors are visible in the audit.
• We do not estimate inclusion in engines we cannot directly query. If an engine is regional-restricted or behind a closed beta we cannot reach, we mark its data as unavailable for that prompt rather than guess.
• We do not blend inputs from disagreeing engines into a single number without flagging the disagreement. Disagreement is signal; collapsing it is data loss.
• We do not recommend actions outside the audit's evidence base. Every recommendation links to the (engine, prompt) evidence that motivated it.

Every audit is stamped with the methodology version at the time the audit ran. When we change a pass — add a new engine, change how presence is detected, refine the diagnosis classifier — the version increments and a public changelog records the change. Audits run under the previous version are still readable; they are simply versioned to the methodology that captured them.

This is operational hygiene that matters when the same prompt is re-audited months apart. A drop in a brand's score from one audit to the next can be a real visibility loss, or it can be a methodology refinement. Versioning lets users tell the difference.

The most useful single move when reading an audit is to drill from the summary view straight to the verbatim engine output for two or three high-stakes prompts. The summary numbers will tell you whether you're winning or losing the prompt; the verbatim engine output will tell you why. Almost every actionable insight surfaces from reading the actual engine responses with brand and competitor names highlighted.

The pipeline behind that is what this post described. The byte-for-byte capture, the per-engine diagnosis, the verbatim-grounded recommendations — all of it exists so the data you read in the audit UI is data you can defend to a CMO, a CEO, or a board.

That is the methodology. It is intentionally boring at the spine and intentionally rich in the data layer. That is what GEO measurement should be.