Scan Then Fix: Pairing a Crawler With an AI Assistant

Reading a website and changing a website are different problems. Reading is one narrow question asked over and over: does this page have a description, does its title repeat the title on another page. The answer is one of a short list, and nothing gets written. Changing a page is a fresh problem every time. A description for a page about emergency water extraction has to say what that page actually offers in words the owner would recognize, without repeating the sentence that's already sitting on four other pages. That's judgment, and it needs a model that can read the whole file and write something in the business's own voice that a person is willing to publish. The same division of labor sits behind our Indianapolis SEO and AEO work: a machine produces the list, a person decides what the site should say.

The classifier in this workflow is a System One model, which TypeSafe describes as “a class of AI models built to make fast, structured decisions that software can use directly.” Its model card lists jev-1.13.0, with jev-latest and jev-preview pointing at the same version. The shape of it matters more than the name. A request carries “64k tokens per request; 32k tokens for state plus the longest question,” which is plenty for one page of text and a question about it, and the service runs at “250,000 tokens per second / 1,200 requests per minute.”

Answers come back typed, which is the part that makes a site wide scan tractable. A Choice question “accepts up to 255 options” and its answer “includes the selected option, a probability for each option, and confidence,” so findings sort and count without anyone parsing prose.

Price is the other reason the reading half runs on a small model. TypeSafe lists input at $42 per billion tokens and says “output tokens are free.” Say a site has thirty pages and each page's text plus the question comes to roughly 3,000 tokens. One question asked of every page is 90,000 input tokens, which works out to about four tenths of a cent. Ask ten questions per page and the whole pass still lands under four cents. That's why a scan can afford to check things a person would skip, and how a scan reads a site in seconds goes further into the mechanics. If the model itself is new to you, the plain explanation of Jev covers what it returns.

TypeSafe publishes the weak spots next to the strengths, and the workflow only works if you design around them. The model card page calls Jev “fast, calibrated” and good at everyday judgment calls, then says plainly that “Jev is not a calculator. We strongly recommend implementing any mathematical logic in code.” Counting sits in the same bucket, covering characters in a word, how often a term appears in a passage, and items in a long list. So page weight in kilobytes, title length in characters and the count of h2 tags belong in your own code, with the model handling the judgment calls: is this description about this page, does this heading describe the section under it.

Two more limits shape the design. The docs say jev-1.13 “reads dates as text” and warn that ordering them or checking whether one falls inside a window is unreliable, so a question about stale content gets answered by comparing dates in code. And accuracy depends on what you send: “Accuracy falls as the state grows with content unrelated to the decision. Unrelated detail acts as a distractor.” Sending one page and one question beats sending the whole site and asking for a summary, which is convenient, because that's exactly the shape of a page by page audit.

Once the findings are sorted, the work changes character. Somebody has to open the template, find the field, write a sentence that fits the business, and leave the rest of the file alone. That's a general assistant's job: it reads the file, drafts the change, and shows you what it did. Using Jev with Claude to fix your website walks through the setup end to end.

The important part of that setup is the approval. Claude Code's permission documentation describes a “tiered permission system to balance power and safety,” and its table lists file modification, meaning edits and writes, as an action that requires approval, with that approval lasting until the session ends. So the default already matches what a live website needs, because a change lands only after somebody has looked at it. One file at a time keeps each decision small enough to actually judge.

Here's the shape of a single pass, with the person's role spelled out at each step. The list of findings comes from a crawl you already have, or from the free site audit if you want the categories handed to you sorted.

Nothing in that table is exotic. The value is in keeping the loop closed, because a finding that gets fixed and never rechecked is a finding you'll meet again in six months. The categories themselves stay stable across sites, which the recurring findings on a small business site covers in detail.

A model editing files without review ships confident mistakes, and they're the kind that read well. A description gets written for a service the business retired two years ago. Five pages end up with five arrangements of one sentence, which trades an empty field for a duplicate one. A phone number gets tidied into a format the Business Profile doesn't use, or an edit meant for one page lands in a shared template and changes forty. Each of those looks reasonable in the diff if you're skimming, and none of them announces itself in analytics for weeks.

The review step is the part people skip, and the tooling makes skipping easy. Claude Code has a mode that “skips permission prompts,” and the documentation attaches a warning to it: “Only use this mode in isolated environments like containers or VMs where Claude Code can't cause damage.” A live website with your phone number on it fails that test. There's a second failure mode worth naming: once a model is writing page text unattended, the temptation is to have it write new pages too. Google's spam policies put “using generative AI tools or other similar tools to generate many pages without adding value for users” under scaled content abuse, which it defines as generating many pages for the primary purpose of manipulating rankings. The useful version of this workflow changes pages you already meant to have, in ways you can check.

The routine matters more than the tooling, because attention is what fails first on a busy week. What holds up in practice looks like this.

• Work on a branch or a staging copy, so a bad batch can be thrown away without a restore.
• Run one finding type per session. Descriptions this week, titles the next. Mixed batches are where skimming starts.
• Cap the batch at something a person finishes in one sitting. Ten files is a real review; forty is a rubber stamp.
• Read the diff itself, since a summary can describe a change the file didn't get.
• Rescan after every batch and confirm the count for that finding actually dropped.
• Keep a short record of what changed and when, so a traffic shift six weeks later has something to point at.

If you're the one approving, give yourself the same standard you'd give a new hire's work: you're checking whether the sentence is true about this business and whether the file it landed in is the file you meant.

This workflow needs a list before it needs any models, and the list is the cheap part. Run the free audit on your own domain, group what comes back by type, and pick the category with the most pages behind it. Descriptions and titles are usually the place to begin, since the work is contained and you can see the change in the search result itself once Google recrawls the page. If you'd rather have the scan, the edits and the review handled as one piece of work, that's what our Indianapolis SEO and AEO team does for local service businesses, and the finding list makes a fine scope either way.