There is a comfortable place in GEO work where you have a beautiful dashboard showing which prompts you are not winning. It feels like progress. It is not progress. The dashboard is a diagnosis, and a diagnosis that never becomes a treatment is just an expensive way to feel informed.
Most teams stall at exactly this point. They can see that a competitor is cited instead of them on forty buyer questions. What they cannot do is turn that observation into a specific list of edits across hundreds of pages without a person opening every one.
This workflow closes that gap. It takes the citation gap you already measured and converts it into a prioritized, page-level fix list, using Jev as the decision layer and a generative model only for the writing.
What you will finish with
A fix worklist where every affected URL carries:
- A citation probability score
- A diagnosis of why it lost (thin content, wrong angle, missing data, wrong format)
- A keep-or-change decision for title, meta description, H1, FAQ, and schema
- A prioritized rewrite checklist
- A confidence score for each decision, routed to auto-apply or human review
Who this is for: a GEO or SEO lead who already tracks AI citations and now needs to act on the findings across a real site.
Prerequisites:
- A citation gap analysis from your prompt set (see the scoring workflow below if you do not have one)
- A page inventory with current title, meta, H1, FAQ, and schema per URL
- A generative model for the actual rewriting
- A Jev API key, or an agent with the TypeSafe skill installed
Time estimate: a few hours to build the pipeline, then a repeatable cycle you can run weekly instead of quarterly.
Definition of done: every losing page has a specific, prioritized fix list, low-risk edits are applied, and anything that changes positioning or structure has a human owner.
Start from the gap, not from the page
The instinct is to open pages and look for problems. That is how audits become endless.
Start from the citation gap instead. You already know which prompts you are losing and who is winning them. That gives you a ranked list of pages with a measurable problem, which is a far better starting point than "review everything."
If you do not have that list yet, build it first. The AI visibility scoring workflow covers how to capture AI answers and score mention, competitor, citation, and framing. This article assumes you have that output and picks up from there.
The handoff is simple: the scoring workflow tells you which pages are losing. This workflow tells you what to change on each one.
Diagnose why the page lost
A page that is not cited is not cited for a reason, and the fix depends entirely on which reason. Adding a comparison table to a page that is actually too thin wastes the effort.
Ask Jev to classify the loss into a small, fixed set of causes.
{
"model": "jev-latest",
"state": {
"url": "/blog/project-management-for-small-teams",
"prompt": "best project management software for small teams",
"our_page_summary": "A 900-word overview of project management concepts with a short section on tools",
"winning_source_summary": "A 2,400-word comparison with a pricing table, feature matrix, and named recommendations",
"our_citations": 0,
"winner": "competitor_a"
},
"questions": {
"loss_reason": {
"type": "choice",
"instructions": "Why is this page losing the citation to the winning source?",
"criteria": {
"thin_content": "The page covers the topic but with far less depth than the winner",
"wrong_angle": "The page targets a different intent than the prompt implies",
"missing_data": "The winner has data, pricing, or specifics the page lacks",
"wrong_format": "The prompt expects a comparison or list and the page is prose",
"no_clear_answer": "The page does not state a direct answer that can be extracted",
"no_real_gap": "The page is competitive and the loss is not explained by content"
}
},
"fix_confidence": {
"type": "score",
"instructions": "How confident are you that this diagnosis is correct from the available evidence?",
"criteria": ["Weak evidence", "Some evidence", "Strong evidence", "Very strong evidence"]
}
}
}Two things matter here. First, include a no_real_gap option. Some losses are not content problems, and forcing a content diagnosis onto them produces wasted work. Second, ask for a confidence score on the diagnosis itself, because a diagnosis built from thin evidence should not drive a rewrite.
The fix depends entirely on the reason. Diagnose before you rewrite.
Decide keep or change, element by element
Now the page-level work. For each affected URL, Jev reviews the five elements that most often determine whether a page can be cited, and returns a keep-or-change decision for each.
{
"model": "jev-latest",
"state": {
"url": "/blog/project-management-for-small-teams",
"target_prompt": "best project management software for small teams",
"current": {
"title": "Project Management for Small Teams",
"meta": "An introduction to project management for small teams.",
"h1": "Project Management for Small Teams",
"faq_present": false,
"schema_types": ["Article"]
},
"loss_reason": "wrong_format"
},
"questions": {
"title": {
"type": "choice",
"instructions": "Should the title change to improve citation likelihood for this prompt?",
"criteria": {
"keep": "The title already matches the prompt intent and needs no change",
"change": "The title should be rewritten to match the comparison intent"
}
},
"meta": {
"type": "choice",
"instructions": "Should the meta description change?",
"criteria": {
"keep": "The meta is adequate",
"change": "The meta should state the comparison and the recommendation directly"
}
},
"h1": {
"type": "choice",
"instructions": "Should the H1 change?",
"criteria": {
"keep": "The H1 is accurate and specific",
"change": "The H1 should reflect the comparison framing"
}
},
"faq": {
"type": "choice",
"instructions": "Should an FAQ section be added?",
"criteria": {
"keep": "No FAQ is needed for this page type",
"add": "An FAQ should be added to answer the specific sub-questions in this prompt cluster"
}
},
"schema": {
"type": "choice",
"instructions": "Should the structured data change?",
"criteria": {
"keep": "The current schema matches the page",
"add_faq": "FAQPage markup should be added alongside the new FAQ",
"add_itemlist": "ItemList markup should be added to the comparison"
}
}
}
}Five questions, one request, all evaluated against the same page state. This is where the parallel evaluation pays off: you get five decisions for roughly the latency of one.
The output is a per-page change sheet. Multiply it across your losing pages and you have a site-wide fix list, sorted by whatever priority signal you attach.
Generate the rewrite checklist
The keep-or-change decisions tell you what to touch. The rewrite checklist tells you how, and in what order.
For each page that needs changes, ask Jev to prioritize the fixes by expected impact.
{
"model": "jev-latest",
"state": {
"url": "/blog/project-management-for-small-teams",
"changes_needed": ["title", "meta", "h1", "faq", "schema"],
"loss_reason": "wrong_format",
"winning_source_features": ["pricing table", "feature matrix", "named recommendations", "comparison structure"]
},
"questions": {
"first_fix": {
"type": "choice",
"instructions": "Which single change is most likely to close the citation gap?",
"criteria": {
"add_comparison": "Restructure the page into a comparison with a feature matrix",
"add_pricing": "Add a pricing table, which the winner has and we lack",
"rewrite_title": "Change the title and H1 to match comparison intent",
"add_faq": "Add an FAQ answering the sub-questions",
"add_schema": "Add structured data"
}
},
"effort": {
"type": "score",
"instructions": "How much effort does the first fix require?",
"criteria": ["Minutes", "Under an hour", "Half a day", "Multi-day project"]
},
"priority": {
"type": "score",
"instructions": "How urgent is this fix given the prompt's commercial value?",
"criteria": ["Backlog", "Low", "Medium", "High"]
}
}
}The first_fix question is the one that makes this actionable. A page with five needed changes is intimidating. A page with one clear first move is a task someone can actually pick up.
Reported workflows using this pattern have run across roughly 1,450 buyer questions and three AI engines, scoring why pages lost and generating ordered rewrite checklists from the result. Treat the scale as reported. The structure is what matters.
Let the LLM write, let Jev judge
This is the division of labor that keeps quality up and cost down.
The generative model writes the new title, the new meta, the comparison section, the FAQ answers. Jev does not write any of it. Jev scores the drafts.
{
"model": "jev-latest",
"state": {
"original_title": "Project Management for Small Teams",
"proposed_title": "Best Project Management Software for Small Teams: 2026 Comparison",
"target_prompt": "best project management software for small teams",
"brand": "Acme PM"
},
"questions": {
"hook_strength": {
"type": "score",
"instructions": "How well does this title match the search intent and earn a click?",
"criteria": ["Weak", "Adequate", "Strong", "Very strong"]
},
"brand_fit": {
"type": "noul",
"instructions": "Does this title accurately represent the brand's positioning?",
"criteria": {
"true": "The title fits how the brand describes itself",
"false": "The title overpromises or misrepresents the brand"
}
},
"survives_review": {
"type": "noul",
"instructions": "Would this title survive an editorial review without changes?",
"criteria": {
"true": "The title is publishable as written",
"false": "The title needs revision before publishing"
}
}
}
}The brand_fit question is doing quiet but important work. A generative model optimizing for the prompt will happily write a title that overpromises. Jev catches the mismatch before it ships.
A reported pattern from AI-generated page validation is worth noting: drafts pass through a battery of yes/no checks, and only the ones that clear every check reach human review. That gate is what makes volume safe.
Route by confidence and keep the risky edits human
Not every change carries the same risk. A meta description rewrite is low stakes. Changing the H1 and restructuring the page affects how the page is understood by both readers and search systems.
Set your thresholds by risk, not by convenience:
Change | Auto-apply threshold | Below threshold |
|---|---|---|
Meta description | 0.85 | Human review |
Title tag | 0.90 | Human review |
FAQ addition | 0.85 | Human review |
H1 change | 0.92 | Always human review |
Page restructuring | Never auto | Always human review |
Schema addition | 0.90 | Human review |
The reasoning is straightforward. Meta descriptions are easy to revert and rarely break anything. H1 changes and restructuring alter the page's core meaning, and a wrong call there can cost more than the citation it was meant to win.
Match the gate to the risk, not to the convenience.
Two more rules that hold up:
Never let the fix pipeline touch a URL's canonical or redirect behavior. That is a technical decision with consequences beyond the citation gap, and it belongs to a human.
Keep the diagnosis and the fix separate in your log. If a fix does not work, you need to know whether the diagnosis was wrong or the execution was. Collapsing them into one row makes that impossible to untangle.
Verify the fix worked
A change is a hypothesis. Verify it.
- Re-capture the same prompts after the change. Wait long enough for the AI surfaces to reflect updated content. This is not instant.
- Compare citation status before and after. Did the page start getting cited, or did the competitor hold?
- Check for collateral damage. Did the restructured page lose rankings for queries it previously won? Fixes can trade one problem for another.
- Sample the auto-applied changes by hand. Read twenty of them. If the quality is not what you would have shipped, raise the threshold.
- Log the outcome against the diagnosis. Over a few cycles, this tells you which loss reasons your fixes actually resolve.
The honest caveat: not every citation gap is closable with content. Some are authority problems, some are entity problems, and some are simply that the winning source is genuinely better. The workflow tells you which pages have a content-shaped problem. It does not promise that fixing the content wins the citation.
Maintain the loop
This is designed to run more often than a quarterly audit, because it is cheap enough to.
- Weekly: re-run the fix pass on pages where citations dropped.
- Monthly: re-capture prompts and re-score the full set.
- Quarterly: review which loss reasons your fixes resolved and which recurred, then adjust the diagnosis criteria.
- Continuously: keep the outcome log. It is the only thing that tells you whether the pipeline is actually improving visibility or just producing activity.
Reported cost for this kind of decision layer runs around $0.0004 per decision at list price, which is why a 500-page audit can cost cents rather than dollars. That is what makes a weekly cadence realistic where a monthly one used to be the limit.
FAQ
Do I need the scoring workflow first? Yes. This workflow starts from a citation gap. Without the gap analysis, you have no ranked list of pages to fix and no way to measure whether the fix worked.
Can Jev write the new content? No. It does not generate text. A generative model writes the title, meta, comparison, and FAQ. Jev decides what to change and scores the drafts.
How is this different from a normal content audit? A normal audit looks at pages in isolation. This workflow starts from a measured citation gap, diagnoses the specific reason the page lost, and produces a prioritized fix list tied to that diagnosis.
What if the diagnosis says there is no real content gap? Then do not force a content fix. Some losses are authority or entity problems, and rewriting the page will not solve them. Route those to a different workstream.
Should I auto-apply the changes? Only the low-risk ones, and only above your threshold. Meta descriptions and FAQ additions are reasonable candidates. H1 changes and restructuring should always have a human owner.
How long until I see results? It varies by surface and by how often the AI systems refresh their sources. Re-capture on a schedule and compare, rather than expecting an immediate change.
Does this work for large sites? That is the point. The decision layer is cheap enough to run across thousands of pages, and the confidence gate keeps the volume from becoming a quality problem. The bottleneck is human review capacity for the high-risk edits, not the model cost.
What to do next
Take your citation gap list and run the diagnosis question on the top twenty losing pages. Then run the keep-or-change pass on those same pages. You will have a concrete fix list in an afternoon.
Apply the low-risk changes, route the rest to a human, and re-capture the prompts in a few weeks. Then read the outcome log and let it tell you which diagnoses your fixes actually resolve.
Read the rest of the series
This article is part of a seven-part series on using Jev for SEO and GEO work.
- Start here: what Jev is and how to install it
- How to build a Jev internal-linking and cannibalization workflow
- How to use Jev to audit and route your content library
- How to run AI-visibility checks with Jev as the scoring layer
- Where Jev breaks in SEO work
- How one team built a Jev internal-link analyzer for 78 yen
Author: Ethan Marlowe, GEO Measurement Lead Across 500+ Prompts at Auspia. Ethan writes about prompt tracking, citation reporting, visibility dashboards, and AI answer quality checks.
