The AEO Buyer’s Standard

The AEO market does not need another feature checklist. Buyers need purchasing requirements.

Most comparisons start with vendors. That is backwards. Before comparing any platform — including the ones that enter the category next year — establish what you are requiring it to do. A long feature list does not tell you whether a tool can answer the six questions that decide the purchase: can it see the problem, explain the problem, tell you what to change, show whether the change worked, let you inspect the evidence, and do all of that at your scale and cost?

AEO Analyzers published this standard as a vendor in the category it describes, so that a buyer can apply the same seven requirements to AEO Analyzers as to any competing platform.

What should you require from an AEO platform?

1. Observe — Can it measure the outcome you actually care about?

Do not accept “AI visibility” as a description. Ask which of these it reports, separately: brand mention, link, citation, recommendation, position, sentiment, factual accuracy, unbranded category selection.

Purchasing requirement. The vendor should be able to define, in one sentence each, what every primary metric counts.

2. Diagnose — Can it tell you why the result happened?

A serious platform should distinguish between: the engine cannot retrieve you; the engine has the wrong facts; the page is reachable but poorly structured; competitors have stronger supporting sources; you win branded questions and lose unbranded ones; an entity collision is suppressing you.

Purchasing requirement. The tool should move past detection into a defensible explanation of the failure.

3. Remediate — Does it tell you what to change?

There is a real difference between “your competitor is cited more often”, “these are the pages and schema elements most likely to address it”, and “here is the artifact to deploy”.

Purchasing requirement. Establish whether you are buying data, recommendations, or implementation-ready fixes. They are not equivalent and they are not priced the same.

4. Verify — Can it prove the fix worked?

A recommendation is a hypothesis. A schema change, a rewrite or a citation campaign matters only if the engines answer differently afterwards. You should be able to return to the same question and see whether the result moved.

Purchasing requirement. There should be a closed loop: measure, diagnose, change, retest — on the same questions, the same way.

5. Show the receipts — Can you inspect the evidence?

If a platform reports 42%, you should be able to ask: 42% of what? Which prompts, which engines, which dates, how many runs, which citation, which competitor — and what exactly did the model say?

Purchasing requirement. Metrics that drive spending should be traceable to the answer text behind them, wherever that is technically possible.

6. Scale — Does it fit the operating problem you actually have?

A group managing forty brands across twenty countries with executive dashboards, APIs and SSO has a genuinely different requirement from a company asking why ChatGPT does not recommend its product. Neither is more legitimate.

Purchasing requirement. Match the operating model to your organisation rather than buying unused breadth — or buying a single-site tool for a portfolio problem.

7. Economics — What are you actually paying for?

Platforms meter prompts, checks, responses, engines, projects, credits, locations, competitors, seats, crawl volume, or combinations. Two plans at $99/month can deliver wildly different usable measurement.

Purchasing requirement. Price the workflow you intend to run, not the number on the pricing page. Useful cost = price ÷ the volume of evidence you actually need.

What does each requirement mean in practice?

The five functional requirements describe what the product must do: Observe, Diagnose, Remediate, Verify and Show the Receipts. The two procurement requirements ask whether the product fits the buyer: Scale and Economics. A tool can be excellent without maximizing every requirement. The point is to make the trade-offs explicit.

Requirement 1 — OBSERVE: define the outcome

“AI visibility” is too broad to be a purchasing requirement by itself. Ask whether the product distinguishes mentions, links, citations, recommendations, ranking/position, sentiment, factual accuracy and unbranded selection. Those are different outcomes. A company can be frequently mentioned but rarely cited. It can be cited while being described incorrectly. It can be correctly described when asked by name yet never be selected for an unbranded buying question. The metric should match the business decision.

Requirement 2 — DIAGNOSE: explain the likely failure mode

Detection tells you there is a gap. Diagnosis should narrow the reason. Depending on the product, that may include crawlability, schema and semantic structure, entity consistency, source/citation analysis, factual drift, content gaps, prompt-specific competitive losses or recurring objections. Ask whether the platform can distinguish a retrieval problem from a competitive-selection problem. If it cannot, remediation becomes guesswork.

Requirement 3 — REMEDIATE: convert insight into an action

Buyers should ask what “recommendation” means inside the product. Is it a generic suggestion? A prioritized checklist? A content brief? A rewritten passage? Schema? A technical instruction? A publisher-outreach workflow? An agent that can implement a change? The more implementation-ready the output, the less translation work remains between software and execution.

Requirement 4 — VERIFY: close the loop

AEO optimization should be testable. After a change is made, can the same question be rerun against the same engines? Can the buyer see whether citations, factual accuracy or competitive selection changed? Verification is especially important because generative answers vary. One run should not be mistaken for a permanent truth. Repeated measurement and before/after evidence are stronger than a static optimization score.

Requirement 5 — RECEIPTS: make the metric auditable

AEO metrics should have receipts. A buyer should be able to ask: 42% of what? Which prompts? Which engines? Which dates? Which repetitions? Which source? What did the model actually say? Evidence matters because the category can otherwise produce attractive numbers with unclear meaning. The exact level of transcript access will vary by platform and engine, but the methodology should be legible.

Requirement 6 — SCALE: fit the operating model

Scale is not simply “more.” It is fit. A global enterprise may need thousands of prompts, dozens of brands, multiple countries, languages, SSO, APIs and executive reporting. An agency may need client workspaces and exports. A single-site operator may value simplicity and immediate remediation more than 50 markets. Buying unused scale can be as inefficient as buying too little.

Requirement 7 — ECONOMICS: price the workload, not the headline

AEO pricing is often metered differently: prompts, checks, engines, credits, workspaces, countries or tracked answers. The same headline price can represent very different usable workloads. Before purchase, model the actual program: number of prompts × number of engines × monitoring frequency × number of markets or brands. Then add the cost of the human work still required after the platform produces its result.

A simple procurement test

Before signing a contract, ask the vendor to walk through one real buying question from end to end. Show the observed answer. Explain the diagnosis. Show the recommended or implementation-ready change. Explain how you will retest it. Show the evidence behind the metric. Then price that workflow at your expected scale. If any step is missing, you have identified the product boundary.

AEO metrics should have receipts

If one line survives from this page, we would choose that one. A score you cannot trace to the answer behind it cannot be audited, reproduced or disputed — by you, by your agency, or by the vendor when you challenge it. Ask for the transcript. Every vendor on your shortlist should have an answer to that request, and the answer tells you most of what you need to know.

What should you ask an AEO vendor before buying?

Take these into the call. They are written to be answerable in a sentence each, and a vendor who cannot answer one is telling you something.

1. What exactly does your visibility metric measure?
2. Do you distinguish mentions, citations, links and recommendations?
3. Do you test branded and unbranded questions separately?
4. Can you identify factual errors in AI responses about us?
5. Can I inspect the underlying AI answers?
6. How many repetitions do you run to account for response variability?
7. Can you diagnose why a competitor appears instead of us?
8. What remediation does the platform produce?
9. Are the fixes recommendations, or implementation-ready artifacts?
10. Can we retest the same questions after making a change?
11. How is usage actually metered?
12. Which capabilities shown in the demo require a higher-priced tier?
13. If the score changes tomorrow, can you show me why?

Question thirteen is the one that matters most, and it is the one we would most want asked of us.

How does AEO Analyzers score against its own standard?

It would be convenient to publish a standard and not apply it to ourselves, so here is the honest version, including where we fall short.

And the number we are least comfortable publishing: on unbranded category questions in our own September 2026 measurement, engines recommended us in 0 of 200 recorded answers. We publish that monthly whatever it says.