Internal Link Dealer: the internal links an editor would keep

The module never writes a sentence. It takes the pages of your latest reading, finds the paragraphs that could hold a link, retrieves a handful of candidate destinations for each, and asks a decision model ten typed questions about every pair: would a reader gain from opening the destination next, how relevant is it, is there already a phrase in the paragraph that names it honestly, would the link look editorial rather than optimized, are the two pages competing for the same search.

Code, not the model, decides what happens. Every threshold lives in configuration, every anchor must be a phrase that already exists in the paragraph, and a pair that fails any hard gate is refused whatever the rest of its scores say. The model answers; the engine rules.

The rules are the ones internal linking has always had; the module simply refuses to break them.

• Only body links count. Navigation, footer, sidebar and related-posts widgets are read so they can be ignored.
• Money pages first: supporting articles point toward pricing, product and service pages, and toward topical hubs. Money pages do not feed each other.
• A working target of four contextual inlinks for every money page, filled from honest candidates and never forced.
• Anchors vary. The same phrase cannot carry more than three links to one page across the site in one run.
• Three new outbound links per source page per run, more only for hubs you name.
• Thin pages, noindex pages, pages canonicalised elsewhere and near duplicates are never destinations.
• Refusal is a feature. A page where nothing honest fits is listed with its closest misses and the reason.

The module proposes; you are the editor in chief. Nothing is written to your site.

1. Read the site, so there is an inventory to work from. Mark money pages and excludes in the settings, or let the engine detect them.
2. Start a run. The counters show pages read, pairs judged, links placed, pages refused, elapsed time and estimated cost as it goes.
3. Review the inventory: orphans, thin pages, hubs, money pages. Override an archetype that is wrong before you trust the proposals.
4. Read the proposals by strategic value, each with its sentence, its anchor, its scores and a one-line reason. Reject what an editor would not keep.
5. Read the refusals and the money pages still under target. Those pages need supporting content that mentions them, not links forced into unrelated text.
6. Export the approved patches as JSON or CSV, apply them on staging, spot-check ten at random, then go to production.
7. Measure after two to four weeks: impressions on the destinations, the orphan count, the average inlinks to money pages. Link count alone proves nothing.

The questions are typed primitives: a yes or no with a probability, a score with a confidence, a choice among options. That is what lets the model be swapped. The default backend is Jev, TypeSafe’s System One decision model, which answers structured questions without generating text and costs a fraction of a cent per page. Without a Jev key the module asks a language model for the same JSON, and offline it uses a deterministic backend built on term overlap, which refuses more than a model would and never less.

Every run records which backend answered, how many calls it made and what they cost. Two runs of the same site with two backends are a bake-off you can read.

It does not write new paragraphs to host a link, does not rewrite sentences, does not touch templates, does not link every page to every other page, and does not use exact-match commercial anchors unless the phrase already sits in the sentence. It does not change a live site: the export is the hand-off, and a rollback manifest travels with every applied patch.