Thought Leadership — GEO & AI Search
Scoring Content for AI Citability: What 35 Pages and 20 Posts Told Me
TL;DR: I spent a week wiring a judgment model called Jev into my GEO work instead of asking a chatbot for opinions. It scores content the way an answer engine might: typed answers, calibrated probabilities, one narrow question at a time. Running it across 35 pages and 20 social posts for a Fortune 500 industrial manufacturer turned up the same diagnosis everywhere. The content is clean, well structured and easy for a model to lift. It answers almost nothing anyone asks, cites almost nothing, and says almost nothing only that company could say. The scoring cost fractions of a cent per page. The part I did not expect was that the model's answer changed depending on how much context I gave it, which has consequences for anyone building this kind of thing.
Why I stopped asking a chatbot what it thought of a page
If you work in GEO, you have probably done what I did for most of last year. Paste a page into ChatGPT, ask whether it reads as citable, get back four paragraphs of sensible-sounding advice, and move on.
That works fine for one page. It falls apart at 400. The answers are not consistent between runs, they are not comparable between pages, and there is nothing to aggregate. You cannot put "ChatGPT said the meta description was a bit vague" into a board deck, and you certainly cannot track it quarter over quarter.
What I wanted was boring and numeric. Score every element on every page against the same rubric, get the same answer for the same input, and let me add the numbers up.
That is a different kind of model. Not a writer, a judge.
What Jev is, and what it refuses to do
Jev is TypeSafe's first System One model. You hand it state, which is any JSON you like, plus a set of typed questions. It returns typed answers with probabilities. It does not generate prose and it will not explain its reasoning.
Three question types, and that is the whole surface area:
- A yes/no question comes back as a probability between 0 and 1. A 0.5 means genuinely torn, not "medium".
- A choice question comes back with the selected option, a probability distribution across all options, and a confidence figure.
- A score question comes back as a position on a scale you define with written levels, and it can land between two levels.
Here is the split that made it click for me:
| What it is good at | What it will not do | |
|---|---|---|
| Jev | Thousands of consistent, calibrated, typed judgments, cheaply, in parallel | Write anything, reason in chains, retrieve data |
| A text model like Claude | Generation, extraction from mess, reasoning over aggregates, writing the rubric itself | Give you the same answer twice at scale |
| Your own code | Retrieval, policy, thresholds, economics, the arithmetic | Anything that needs semantic understanding |
The loop falls out of that. Code or a text model produces candidates, Jev judges all of them, code applies your policy, and the text model only touches the few things that need rewriting. Nothing novel about the shape. What makes it work is keeping each piece in its lane.
The other property that matters commercially: the judgments are reusable. Score a page once and the raw answers sit there. Change your mind about how much structured data matters relative to author credentials, and you re-weight locally. Nothing re-runs, nothing gets re-billed.
The rubric is the asset, not the software
I started with five dimensions because five felt sensible. Answer directness, fact density, source authority, structured data, freshness. It produced a tidy dashboard and it was close to useless, because five dimensions cannot tell two bad pages apart. Two pages scored 37 percent for completely different reasons and the dashboard showed them as equivalent.
So I rebuilt it as 14 dimensions in 5 weighted families for pages, and separately 18 dimensions in 6 families for social posts. Weights sum to one. Every dimension has four written levels describing a concrete, recognisable situation.
The three additions that earned their place:
- Chunk integrity. If one passage is lifted out with no surrounding context, does it still make sense and stay true? That is the actual retrieval mechanic and my first rubric did not touch it.
- Originality. Could a model get this same content anywhere else? If yes, there is no reason to cite you specifically.
- Promotional load, scored in reverse. More selling means a worse score. This is what finally punished the brand boilerplate that the element-level checks kept flagging without ever pricing.
I also added two gates that flag rather than score. One asks whether the visible text is truncated or templated. The other asks whether a passage, quoted accurately but out of context, would misrepresent the company. Gates stay out of the weighted score deliberately. Average a hard defect into a soft number and it disappears: a broken page still reads as 60 percent.
If you take one operational point from this piece, take that one. Writing the level descriptions is the work. The weights are a rounding error by comparison, and I will come back to why they are also the weakest part of what I built.
The finding I did not expect
I added a well-formedness check specifically to catch a title I had spotted by hand. A live page on an enterprise site carried a title that began "Be supplier of" and then went straight into the site name. Visibly broken. Words missing.
The quality rubric scored it 2.17 out of 3 and passed it as Keep, which is defensible: none of the four quality levels describes text that is simply cut off. So I wrote a separate yes/no question asking whether the title was a complete, correctly formed piece of text.
It scored 0.89. It said the title was fine.
Rather than guess at the wording, I ran the same question against different amounts of state.
| State given to the model | Same question, same model |
|---|---|
| Whole page evidence: title, meta, headings, opening body text | 0.90, reads it as fine |
| The title string on its own | 0.22, flags it as broken |
Question count made no difference. One question and two questions returned the same answer. What changed the result was how much context sat alongside it.
With a page of surrounding content, the model reads a clipped phrase charitably, because everything else tells it what the page means. Strip that away and it sees the broken phrase for what it is.
So the architecture changed. Every page now gets two requests in parallel. One carries the full evidence and asks the 23 questions that need context. The other carries nothing but the three element strings and asks three well-formedness questions. Same round trip, about 445 extra tokens. The flag now fires correctly at 0.34.
The general rule, which I have not seen written down anywhere: match the state to the question's scope. Bundling everything into one request is token-efficient and it silently changes your answers for narrow judgments. If you are building anything like this, that is the trap.
What the audits actually showed
Pages first. Fifteen pages sampled from a manufacturer's regional sitemap, 26 questions each, 11 seconds, about 3,700 input tokens per page.
The scores separated properly once the rubric had 14 dimensions. One page scored 52 percent with excellent machine signals and structure but almost no credibility and heavy promotional language. Another scored 37 percent for the opposite reasons. Five dimensions could not express that difference. Five families can.
Then social. Ten LinkedIn posts and ten Instagram posts from the same company, scored on the 18-dimension rubric.
| Family | ||
|---|---|---|
| Substance | 68% | 62% |
| Extractability | 87% | 76% |
| Attribution | 73% | 67% |
| Question fit | 61% | 55% |
| Durability | 72% | 58% |
| Restraint | 72% | 70% |
| Mean score | 7.8 / 10 | 6.8 / 10 |
LinkedIn wins, which surprised nobody. What is more useful is where it wins. Instagram loses on durability and depth, not on writing quality, where it is actually marginally clearer. Nine of the ten Instagram posts were one image plus one video, and the top recommended fix for seven of them was to move the substance out of the video and into the text.
The finding that matters is the one that is identical on both platforms. Ranked by weight multiplied by shortfall, the three biggest losses across all twenty posts were question fit, originality and evidence. In that order.
That company's content is well written, self-contained and highly extractable. Extractability at 87 percent on LinkedIn is genuinely strong. What it does not do is answer questions people ask, say anything only that company could say, or attribute a single claim to a checkable source.
Worth noting the shape of it: claim specificity scored 85 percent while evidence scored 56. The posts do make specific claims, naming real projects and real awards, then leave them unsupported. That is a narrower and more fixable problem than "write better content".
Four gates tripped. One Instagram post had a zero-character caption and scored 2 out of 10. Three posts scored 8, 8 and 6 and tripped the quotation risk gate, meaning they would score well and misrepresent the company if an answer engine lifted them. That is exactly why gates do not enter the score.
What a real browser sees that a crawler does not
I also built a version that drives an actual Chromium, scrolls each page in visible steps, and scores each section as it comes into view. Mostly for fun. It taught me two things I would not have found otherwise.
The first: a client's FAQ page came back with every section scoring 2 out of 10 and zero words of body text. The page was not empty. It was an accordion. In a real viewport the answers are hidden until someone clicks, so the browser correctly saw nothing, while the raw HTML fetcher had happily read all of it.
That is a genuine GEO distinction and not a bug. A crawler reads collapsed content. A visitor has to click. Whether an answer engine treats hidden text as page content is worth having an opinion about. Until I have one, I flag it rather than score it.
The second: the same manufacturer's site returns 403 to a datacenter IP and loads perfectly in a real browser from a normal connection. Every cloud-hosted audit tool you have ever run against an enterprise site behind a WAF has been getting a partial picture.
The plumbing got cheap enough to stop thinking about
Two things made this practical rather than a toy. The judgment model bills in fractions of a cent, and the data layer now does too.
| What | How | Cost |
|---|---|---|
| Score one page, 26 questions | Jev, one request, parallel | about 3,700 input tokens |
| 39 LinkedIn company posts, structured | One API call through a tool proxy | $0.004 |
| 10 Instagram posts with captions and media counts | One call | $0.002 |
| Ten days of web, news, X and Reddit mentions | Four calls | $0.0155 |
The mentions sweep is worth dwelling on. It ran in about a minute and surfaced a live 1.2 billion euro acquisition bid across Reuters, Bloomberg and the Wall Street Journal, all inside the window, plus the same story on Reddit. One and a half cents.
One distinction I would build into any monitoring you set up: of the fifteen news results, seven were the company's own newsroom and eight were third party. Owned and earned are not the same signal. A model citing your own press release tells you much less than Reuters citing you.
Eight things an enterprise can actually do with this
The pattern generalises past auditing. These are the plays I would put in front of a CMO, roughly in order of payback.
| Use case | What Jev does | Scale |
|---|---|---|
| Answer monitoring | Per AI answer: are we mentioned, is it accurate, how are we positioned, is a competitor preferred | Thousands of answers per week across models and markets |
| Pre-publish gate | Every draft clears a citability threshold and a claim check before it ships | Every piece of content, forever |
| Question coverage matrix | For each buyer question by each page: does this page contain a quotable answer | Question space multiplied by page count |
| Citation trait autopsy | Score the competitor pages AI engines actually cite, and find the trait that predicts it | Hundreds of pages per category |
| Claim-level quotation risk | Per sentence: would quoting this out of context misrepresent us | Every claim on the site |
| Cross-market parity | Does the Arabic page answer the same question as the English one, and as directly | Every page in every locale |
| Entity consistency | Across your site, directories and third-party profiles, is this described as the same company | Every mention anywhere |
| Winnability triage | Per question: would an answer come from a vendor page, a review site, a forum, or an encyclopedia | Your whole question space |
That last one reframes more content budget than anything else on the list. Sometimes the right move is not another page. It is getting discussed on Reddit, or getting into a comparison roundup, because that is the source type an answer engine is going to reach for.
The pre-publish gate is the unglamorous one that compounds. Nobody will thank you for it and it quietly stops the next "Be supplier of" from ever going live.
What this does not do, including the part that bothers me
I would rather say this plainly than have you find out on your own data.
The weights are not fitted, and that is the real limitation. Fourteen dimensions is a more complete theory of citation than five, and it is still a theory. Mine. Until those weights are regressed against pages that AI answers demonstrably cite, the rankings are a hypothesis with decimal places on it. The dashboards look authoritative and that authority is not earned yet.
The fix exists and I have not run it. Take a few hundred pages you know get cited, a matched set that does not, score both on the same rubric, and fit the weights to the outcome. That also tells you which of the fourteen dimensions carry no signal, which is how a rubric gets shorter instead of longer. If you are doing this seriously, run that study before you show anyone a number.
A few smaller things worth knowing before you start:
- Jev returns judgments, never text, so every proposed fix has to come from a template or a text model. Design for that at the start rather than discovering it three weeks in.
- Ten posts is a sample. Enough to see a pattern, not enough to call a trend or compare quarters.
- LLM answers vary between runs, so monitoring needs repeated sampling and distributions. A single run is an anecdote in a spreadsheet.
- Rubric quality dominates model quality. That broken title passed because no level described broken text. My error, not the model's, and it is the error you will make too.
Where I would start
If you have a large content estate and you are being asked what AI search is doing to it, do these in order.
- Pull the pages AI engines already cite in your category. That data is buyable now and it is the foundation for everything else.
- Write the rubric before you write any code. Argue about the level descriptions with someone who disagrees with you.
- Fit the weights against the cited and uncited sets. Now your numbers mean something.
- Then automate, and put a gate in the publishing workflow so the estate stops degrading while you fix it.
Most teams do these in reverse: buy a tool, get a dashboard, and inherit somebody else's unexamined weights. That is how you end up with a confident number nobody can defend.
I am running this against a live Fortune 500 GEO pilot across the US and Canada. Everything audited here was public content, and the company stays unnamed. If you want to compare notes on the calibration study, that is the part I most want to talk about, because it is what stands between a plausible score and a defensible one.
Want to compare notes on the calibration study?
Based in Dubai, UAE.