Internal links are decisions, not writing

Internal linking has a reputation as a writing task: open the page, find a place, write a sentence around a link. That is why it never gets done on a site of a thousand pages, and why the tools that promise to do it for you tend to produce sentences nobody wrote and anchors nobody would choose.

Strip the writing away and what remains is thousands of small, bounded decisions. Does this paragraph give a reader a real reason to open that page next? Is there already a phrase in the copy that names it honestly? If either answer is no, the right move is to do nothing. A decision like that does not need a writer. It needs a judge that is cheap enough to ask ten thousand times.

The Internal Link Dealer reads your latest reading, finds the paragraphs that could hold a link, retrieves a handful of candidate destinations for each, and hands every pair to a decision model as typed questions. The model answers yes or no with a probability, or a score on a short scale, or a choice from a list. It never writes a word, and it is never asked to.

• Would a reader of this paragraph benefit from opening the destination next?
• How relevant is the destination to what the paragraph is saying, on a four-level scale?
• Does the destination match the intent of the paragraph, or is it a bait-and-switch?
• Which of these phrases, all cut from the paragraph by code, is an honest anchor, or none of them?
• Would an editor keep the link, or does it read as an insertion?
• Are the two pages competing for the same search?

Every threshold lives in configuration, not in the model. A pair that fails any hard gate is refused whatever its other scores say, and an anchor that is not a verbatim substring of the paragraph is not an anchor. A source page gets at most three new links per run, a destination at most eight, and the same phrase cannot carry more than three links to one page across the site. Navigation, footers and related-posts widgets are read so they can be ignored.

The result is a list you can read in one sitting, and a second list that matters just as much: every page the module left alone, with the reason. A page nothing honest fits is not a failure of the tool. It is a page that needs content before it needs links, and the refusal list is where that content brief comes from.

A construction-supplies shop of 1,296 pages, mostly category and product pages: ten thousand paragraph and destination pairs judged in a little over three minutes, 26 links proposed, 1,271 pages refused. The anchors were product and category names already in the copy: a barrier model, a fence type, a mesh with an edge wire. The most common reasons for refusal were relevance and an anchor an editor would not keep. A directory of five thousand pages, whose pages are lists rather than articles: twelve thousand pairs in four minutes, 166 links, most of them from one category page to a narrower one it already described.

Both runs cost well under a dollar in model calls, because a decision model is billed on what it reads and returns no prose, and because a page’s pairs travel in one request rather than one at a time. A frontier language model asked the same questions in the same way would have cost tens of dollars and taken most of an hour.

Mark your money pages first, the ones that earn, or let the module detect them from the address and the title. Read the inventory and correct any archetype that is wrong. Start a run, then read the proposals by strategic value and reject what an editor would not keep. Export the approved patches, apply them on staging, spot-check ten at random, then go to production. Nothing is written to your site by the module itself.

Then wait two to four weeks and look at the destinations: impressions in Search Console, the orphan count, the average number of contextual inlinks to money pages. A count of links placed proves nothing on its own, and the module will not pretend otherwise.