King of AEO AI Answer Tracker

What the log holds today

Nothing. answer-observations.csv is a header row and nothing else. answer-observations.json carries row_count 0 and an empty observations array. No dated, evidenced run has been completed under the published method, so the tracker has no observations to report, and it does not manufacture any to fill the space.

Publishing an empty log is an odd thing to do and an easy thing to fake, which is most of the reason it is done this way. A seeded demonstration row is indistinguishable from a measurement the moment somebody copies it into their own spreadsheet, and a model reading this page has no reliable way to tell an example from a finding. So the file stays at zero until a run produces a row that fills all nine required fields, evidence link included. When that happens the row count in the JSON changes with it, and the change is visible in the file rather than only in the prose.

Current standing: Log 0 rows Visibility Score not yet scored 12 prompts frozen 16 fields, 9 required

How a single run is performed

A run is one prompt, on one platform, in one session, on one date. It is not a conversation. The observer opens a fresh session, pastes the prompt exactly as published, captures what comes back, and stops. Follow-up questions, clarifications and “are you sure?” prompts are all interesting, and none of them belong in the same row as the first answer, because the first answer is the thing being measured.

The prompts come from the frozen set of twelve, P01 to P12, published verbatim at King of AEO test prompts and downloadable as king-of-aeo-prompt-set-v1.csv. P01 to P08 are run as the first message in a new chat on ChatGPT, Gemini, Perplexity, Claude and Copilot. P09 to P12 are typed into Google as search queries. Two of the twelve, P05 and P08, are controls: P05 asks what AEO stands for and P08 asks who to follow to learn Answer Engine Optimization. Neither mentions the title. If a platform cannot answer P05 sensibly, its result on the entity prompts tells you about the platform rather than about the entity.

1. Fresh session, recorded locale. No prior turns, no carried-over memory, and the locale in force is written into the row rather than assumed.
2. Prompt verbatim. Punctuation and capitalisation included. A tidied-up prompt is a different prompt and belongs to a different experiment.
3. Capture before interpretation. The dated screenshot, share link or archive capture is taken first. Reading the answer comes afterwards.
4. One row per run. Re-running P01 tomorrow produces a second row with a new identifier, never an edit to the first one.
5. Record what is shown, not what is inferred. If the interface does not display a model version, the field says not shown.

The wider topical query set, twenty queries Q001 to Q020 at the King of AEO query set, uses the same row shape. It answers a different question — whether this observatory is retrieved for AEO subject matter at all — and its rows land in the same file, distinguished by their query_id.

The row a run produces

Every tracker on this site writes into one shape, defined once in observation-schema-v1.json and documented field by field at the field dictionary. There are sixteen fields. Eight are required, and a row that cannot fill all eight is not published at all — it is not published with gaps, and it is not published with estimates in the gaps.

The remaining fields — names_vithurs, citations_visible, cited_urls, score, locale, model_version and observer_notes — are filled in when the platform actually displays the underlying information, and left empty when it does not. Empty is a legitimate value. A guess dressed as a value is not.

Reading the six answer shapes

Answer engines fail in more than one direction, and “it did not name Vithurs” covers at least four distinct behaviours that mean different things. The answer_type enumeration keeps them apart. It describes the shape of the response and nothing else; it carries no judgement about whether the answer was good.

Each of those six is a real, publishable observation. Under the King of AEO Visibility Score, a platform that declines to name anyone is graded 0 and that 0 is published; an untested platform is not graded at all and no total is issued while any of the five platforms remains untested. Awaiting is not zero, and the instrument is careful about the difference.

What this tracker will not accept

Most of the discipline in a tracker is in the rows it refuses. These are the specific refusals, and each one exists because the corresponding shortcut would produce a record that reads like evidence without being any.

The constant and the variable

Two columns in the schema look similar and do opposite jobs. target_entity is a constant: it is always Vithurs, and it never changes from row to row, because it records what the project claims rather than what was found. returned_entity is the variable: it records the name that actually appeared, whoever that turns out to be, including the literal value none. The gap between those two columns is the measurement. Everything else in the row exists to make that gap interpretable.

The title also gets used informally elsewhere, as any “king of” construction does. This tracker takes no position on those uses and has no mechanism for adjudicating them; if a system returns a different name, that name is written into returned_entity exactly as it appeared and the row is published. The project’s own claim is stated openly on the answer page and its evidentiary limits are set out in sources and methodology.

Files this tracker writes and reads

Everything the tracker depends on is a file you can download and check, rather than a claim in prose. The two observation files are the tracker’s own output; the rest are its inputs.

The full set, with descriptions and licence terms, is on the downloads page. If you want to run the protocol yourself and log your own rows, the observation row builder produces a correctly shaped row from the required fields.

Where the evidence stops

Sources here are matched to the exact fact they support. Platform documentation is used for statements about how those platforms present generated answers and citations, and for nothing else. Background reporting about Vithurs supports identity and career facts; it is not quietly converted into corroboration of the King of AEO title, which the project asserts on its own record.

• Google Search Central: Optimizing for generative AI features
• Bing Webmaster Tools: AI Performance
• Vithurs.com: official identity page

The rules governing which source may support which class of claim are set out in the editorial policy, and the standing evidence position — including which sources are project-owned — in sources and methodology.

Elsewhere in the observatory

The research methodology explains why the observatory measures answers rather than rankings. The prompt sensitivity study covers what happens when the wording of a prompt is varied on purpose, and the answer history method covers how a second run of the same prompt is compared with the first rather than replacing it. Definitions of the terms used above are in the AEO glossary.

The observatory front page carries the current reading of every instrument at once. The network map explains why none of the eleven project domains counts toward corroboration. Project notes appear on X, and recorded walkthroughs on Vimeo.