We Rebuilt a 566-Page Internal Link Map with Jev. Only 287 Links Survived Review.

You have probably already seen the number that made Jev famous in SEO circles: a 586-page internal link map, rebuilt in about 45 seconds, for roughly 21 cents.

It is a good number. It is also, on its own, close to useless.

Speed and cost tell you whether you can run a judgment across every page on your site. They tell you nothing about whether the judgments were right. And internal linking is exactly the kind of task where being fast and wrong is worse than being slow, because you ship the wrong links and then have to find them again.

So this article does something different from the rest of the series. It does not teach the workflow, because that is already covered. It does not tear down a tool, because that is also covered. It reports what happened when a team ran the benchmark and then counted how many of the model's decisions a human actually kept.

The answer is the interesting part.

What you will finish with

A repeatable benchmark you can run on your own site, and the four numbers that matter when you report it:

Proposed: how many links the model wanted to create
Kept: how many survived an editorial pass
Recall: how many of a human's links the model found
Agreement: how often the model and the human chose the same anchor

Plus the rubric-rewrite loop that moved two of those numbers, and a clear statement of what the benchmark does not prove.

Who this is for: anyone who has already read the internal linking workflow and wants to know whether the output is trustworthy at scale.

Prerequisites:

A crawl of your site with page titles, headings, and body text
A candidate-narrowing step before Jev sees anything (similarity search, embeddings, or the TF-IDF approach from the tool teardown)
A Jev API key, or an agent with the TypeSafe skill installed
One person willing to review a sample of the output by hand

Definition of done: you have proposed, kept, recall, and agreement numbers for your own site, and you know whether your rubric is the bottleneck or the model is.

The run, in full

Two independent runs are worth looking at, because they used different page counts and reported different things.

Run A, the widely cited one. 586 pages. 45.1 seconds. $0.21 total. 584 links placed. 139 pages received no link at all because the model judged that nothing honestly fit.

Run B, the one with the review step. 566 pages. 8,460 yes/no link decisions. 5.9 seconds. 679 links placed. $0.27 total. Every proposed link used words that already existed on the page, so no new anchor text had to be invented.

Run B is the more useful one, because the team behind it did two things most people skip.

First, they ran the same queue through a frontier model on the same clock. When Jev finished, the frontier model had completed zero pages. By second 16 it had finished eight. The projected full pass was about $67, roughly 240x more per page.

Second, and this is the part that matters, they put a human editor in front of the output.

Bar comparison showing Jev completing 566 pages in 5.9 seconds for $0.27 against a frontier model's projected $67 for the same queue.

The cost gap is real. It is also not the point of this article.

The number nobody reports: 287 of 679

Of the 679 links Jev proposed, an editorial pass kept 287.

That is a 42% keep rate. Put differently, roughly six out of every ten proposed links did not survive contact with a human editor.

This is the number you should carry into your planning, and it is the number that is almost always missing from the posts celebrating the cost. A 27-cent run that produces 679 candidates is not a 27-cent internal linking solution. It is a 27-cent candidate generator that hands a human 679 things to look at.

Whether that is a good deal depends entirely on your alternative. If your alternative is a person manually reading 566 pages looking for link opportunities, then generating 679 candidates, even if most are wrong, is a massive head start. If your alternative is a careful manual audit of your twenty most important pages, then a 42% keep rate across your whole site is not obviously better.

The honest framing: Jev did not fail here. It did what a cheap classifier does. It produced a high-recall candidate set, and a human did the precision work. The mistake would be to ship the 679 without the editor.

Where the rubric went wrong, and how they fixed it

The most valuable part of Run B is not the speed. It is the disclosure that the first rubric was not good enough.

The team put a frontier model behind Jev as a second-stage referee. The referee read 24 pages, compared its own link choices against Jev's, and looked specifically at where the two disagreed. Then it rewrote Jev's rubric. They did this twice.

Two rewrites produced:

Recall (how many of the referee's links Jev also found) moved from 45% to 65%
Anchor agreement (how often Jev picked the same anchor the referee would have) moved from 71% to 88%

The one-time cost of that rubric work was about $15.

Read that against the run cost. The link decisions cost 27 cents. The work that made those decisions good cost $15, roughly 55 times more than the run itself.

That ratio is the real lesson of this benchmark. If you take one thing from this article, take this: the rubric is the product. Jev is literal. It answers the question you wrote, not the question you meant. A cheap model with a bad question produces cheap wrong answers at scale, and scale is exactly what makes wrong answers expensive.

Before-and-after panel showing recall moving from 45% to 65% and anchor agreement from 71% to 88% after two rubric rewrites.

Two rubric rewrites. One-time cost: about $15. This is where the quality came from.

How to run this benchmark on your own site

You cannot trust someone else's keep rate. It depends on your site, your rubric, and your reviewer. Here is the procedure.

Step 1: Build the candidate set without Jev

Do the cheap narrowing first. Embed your passages, retrieve roughly fifteen candidate target pages per passage, and drop pairs that already link. If you skip this and hand Jev every page pair, your cost stops being trivial and your results stop being interpretable.

Step 2: Write the link question, then write it again

Your first rubric will be worse than you think. Write it anyway, run it, and expect to rewrite it. The question should be a yes/no judgment about whether a real reason exists to link these two pages. It should not be a similarity score, and it should not ask the model to generate anchor text.

Step 3: Run the full set and record every decision

Log the proposed links, the confidence for each, and the anchor chosen. Do not filter by confidence yet. You need the unfiltered set to measure recall.

Step 4: Have a human review a sample

Pick a sample you can actually read. Twenty to 30 pages is enough to start. For each page, note which links a human would place. This is your reference set, and it is the only way to get a recall number.

Step 5: Compute the four numbers

Proposed: total links the model wanted
Kept: how many survived review
Recall: how many of the human's links the model found
Agreement: how often the anchors matched

If you only report proposed and cost, you have reported a marketing number, not a benchmark.

Step 6: Rewrite the rubric and re-run

Take the pages where the model and the human disagreed. Look at the pattern in those disagreements. Rewrite the criteria to address it. Re-run and compare. Two rounds is usually enough to see whether the rubric is converging or whether the task is a bad fit.

Step 7: Decide what to ship

Ship the kept links. Do not ship the proposed links. If your keep rate is very low, the problem is probably the rubric, not the model. It might also be that your site genuinely does not have many honest internal link opportunities, which is a legitimate finding.

What this benchmark does not prove

Three limits worth stating plainly.

Both runs are self-reported by the teams that built them. The page counts, timings, and costs are their numbers, not independently audited. Treat them as credible order-of-magnitude evidence, not as guarantees.

The 190x and 240x figures are not comparable to each other. They come from different runs, with different page counts, against different baselines. Do not average them. The defensible claim is that it is two to three orders of magnitude cheaper per page than a frontier model on this task, and even that is specific to a task the frontier model was not optimized for.

The 88% anchor agreement is one reviewer's judgment on 24 pages. That is a small sample. It is suggestive, not conclusive. Your own agreement number will depend on who reviews and what they consider a good anchor.

The four failure modes to watch for

Based on both runs, these are the ways this workflow goes wrong.

A high keep rate with low recall. The model is conservative and agrees with you on the obvious links while missing the non-obvious ones. This looks like success and is actually underperformance. Watch recall, not just keep rate.

A low keep rate with high recall. The model proposes everything. You spend your review budget rejecting candidates. This is where a rubric rewrite pays for itself fastest.

Anchors that read like SEO. If the anchor text does not sound like something a person would write, the rubric is optimizing for the wrong thing. Run B's constraint, that every anchor must use words already on the page, is a good guardrail against this.

Confidence that does not track correctness. If your low-confidence links are not meaningfully worse than your high-confidence ones, your confidence threshold is not doing any work. Check this before you automate the routing.

What to do next

Pick 30 pages from your site. Run the candidate narrowing, write a first rubric, and have Jev propose links. Then read those 30 pages yourself and count how many proposals you would keep.

That single number, your own keep rate, tells you more about whether this belongs in your workflow than any benchmark in this article. If it is above roughly half, you have a usable candidate generator. If it is far below that, rewrite the rubric before you rewrite the tooling.

And budget for the rubric work. The run is cheap. The thinking is not.

Read the rest of the series

This article is part of a ten-part series on using Jev for SEO and GEO work.

Author: Julian Mercer, 14-Year Technical SEO Practitioner at Auspia. Julian writes about crawlability, site architecture, internal linking, and the technical foundations that make content readable to both search engines and AI systems.