How to Prioritize SEO Issues With TypeSafe AI's Jev

To prioritize SEO issues, send one finding to TypeSafe AI's Jev and let your own code rank the list. Jev does not crawl the site. It also does not invent a single red label that means "fix this first."

I split the judgment. A Score answers SEO impact against levels I wrote. A Choice answers issue type. Crawl data stays in the request: the URL, the status code, the impressions. When confidence is low, the row waits for a person. That wait is the review. The backlog is the sort I compute after the answers come back.

A /pricing URL that returns 404 is not the same job as a blog URL with a thin title and a handful of impressions. SEO issue prioritization fails when both rows share one severity badge. TypeSafe AI's Jev can separate those findings if you ask one question per dimension. You still prioritize SEO issues in your own code, with weights you can change on Tuesday without another model call.

SEO issue prioritization needs crawl data beside the label

Severity fields from a crawler are useful and incomplete. "High" does not say whether anyone requested the URL. SEO issue prioritization gets honest when the finding and the crawl data travel together.

Normalize the row before the call. One URL, one status, one short extract of the title or the broken tag, and the demand you already stored (impressions, or an internal hit count). Drop duplicate rows that are the same URL and the same issue type. TypeSafe AI's Jev should not be asked to dedupe your export.

If the extract is empty, do not expect a sharp Score. The model can only read the state you pass.

Score SEO impact separately from issue type

Ask two questions in one request. They run together and neither sees the other's answer, which is what you want. SEO impact and issue type are different decisions.

SEO impact levels have to describe a situation, not a mood. I use four, from none to blocking on a URL that already converts:

1. No change to crawl, index, or clicks. The URL can stay as it is.
2. The finding hurts a URL with little demand, or a workaround already exists.
3. The finding blocks crawl, index, or clicks on a URL people already request.
4. The finding blocks crawl, index, or clicks on a URL that already converts.

The Score answer is a number on that scale, a probability for each level, and a confidence value from 0 to 1. Score documents that shape. Confidence is how concentrated those probabilities are. It is not a second opinion about revenue. Confidence is computed from the spread, and you can threshold it yourself.

Do not fold issue type into the same Score. A blocked /pricing page and a soft 404 on a tag archive can both look "severe" and still deserve different work.

Choice picks the issue type

A Choice returns one option from a set you define, plus a probability per option. I keep the set small:

• indexation: the URL should be in the index and is not, or it is blocked.
• snippet: the URL can rank and the title or description is the weak part.
• crawl_waste: Google is fetching a URL that should not be fetched again.
• not_seo: the row is a content preference, an analytics question, or noise.

Include not_seo. Without an exit, TypeSafe AI's Jev has to force every row into an SEO bucket. The Choice criteria should say what each option looks like in a sentence. "High" and "low" are not issue types.

I do not ask the Choice to name an engineer. Ownership is a roster problem. The Choice names the kind of fix.

Build the prioritized backlog in code

Read the Score and the Choice. Drop not_seo. Normalize the Score by the top level index so impact sits between 0 and 1. Then apply crawl data.

impact = answers["impact"].score / 3
confident = answers["impact"].confidence >= 0.5
issue = answers["issue_type"].choice

if issue == "not_seo":
    return None
if not confident:
    return {"queue": "review", "url": url}

return {"queue": "ranked", "url": url, "priority": impact * (1 + impressions)}

That formula is an example, not a law. Impressions, or whatever demand column you trust, keep a converting URL ahead of an orphan tag page with the same SEO impact. This is still how you prioritize SEO issues: composite scoring keeps the weights in your code. Change the weights when the prioritized backlog promotes the wrong template. You do not rerun TypeSafe AI's Jev just to retune a coefficient.

A second request is worth it only when the first answer tells you to fetch new evidence. Extra questions on the same state can go in the first call.

Calibrated review when confidence is spread out

High confidence means the Score sat on one level. It does not guarantee SEO impact. If the state omitted the status code, a confident answer can still be confidently under-informed.

I use three paths. Confidence under 0.5 goes to a person. A clear crawl_waste or indexation Choice with a high Score can open a ticket. A snippet issue on a URL with no demand can wait. The thresholds are mine. Test them on a labeled sample of your own findings before you let them file work.

The ticket text is also yours. TypeSafe AI's Jev will not write acceptance criteria. Copy the URL, the issue type, the level the Score leaned on, and the crawl data you used. A reviewer should be able to see why the row outranked the one under it.

Sort a real backlog

Keep the questions narrow and the weights in code. If you also want visits beside those URLs, start free on EventDash. Pricing is the plan split.

Sources:

• TypeSafe Score
• TypeSafe Choice
• TypeSafe confidence
• Composite scoring

Related:

• Meta description relevance with TypeSafe Jev