Internal linking is a decision problem before it is a writing problem: which related page would genuinely help this reader next?
Internal-link recommendations look simple until a site has hundreds of product, category, service and editorial pages. A useful system has to tell a genuinely helpful link from two pages that merely share vocabulary. That is why CiteLadder treats internal linking as retrieval followed by a bounded judgment, rather than asking a generative model to invent links across the site.
Why internal linking is a decision problem
Google recommends linking important pages from other relevant pages, with concise, descriptive anchor text that helps people and search engines understand the destination. [1]
Producing an HTML anchor is the easy part. The hard part is deciding which page pairs are related enough to deserve one. A naive system can create thousands of technically valid but editorially useless links: product variants linking to each other, utility pages receiving links, or pages connected only because they repeat the same brand words.
The design rule
Code handles what the application can know exactly. Jev answers only the semantic question that remains. A person still decides what gets implemented.
Step 1: shortlist related pages without AI
An analysis starts from a completed Site Health crawl. For each captured page, CiteLadder builds a lightweight representation from its title, main heading, URL path and meta description, and ranks related destinations by text similarity. Words that appear across a large share of the site, such as the brand name or template text, carry no weight.
Before Jev sees a pair, CiteLadder removes obvious bad candidates
If the crawl already found a main-content link from the source to the destination, the pair is not proposed again. A navigation-only link does not count.
A page never suggests itself, and policy, about and contact pages neither give nor receive suggestions.
A destination must be an indexable captured page.
Products whose titles differ only by a colour or size word never suggest each other, so the shortlist is not flooded with near-identical items.
Click-tracking parameters are removed from page identity, so one destination is never treated as several pages.
This stage is deterministic: cheap, repeatable and explainable. It stops Jev from spending judgments on pairs the application can reject on its own.
Step 2: let Jev judge each page pair
For each shortlisted pair, CiteLadder sends Jev a bounded description of both pages: title, main heading, path, page type, description and a short excerpt, plus how many contextual links the destination already receives. Jev answers one question: should the source contain a contextual link to the destination?
Jev returns a typed answer with a probability instead of prose the application must parse. [2] CiteLadder treats that probability as a review signal, not proof that a link will improve rankings.
The rubric is deliberately narrow: would a reader of the source genuinely benefit from the destination, and does the link fit a hub-and-spoke structure, with supporting pages linking up to their hub and hubs linking down, rather than a forced association?
Step 3: keep anchor text grounded in the destination
CiteLadder never asks a model to invent anchor text. Options come from the destination page itself: its main heading, its title without the site suffix, and a readable URL slug. When there is more than one option, Jev chooses among them.
That boundary matters. The model picks from controlled options; the application owns the text and can show where each option came from. An anchor cannot drift from the page a reader will actually reach.
Step 4: review the suggestion, not a black-box score
The Internal links tab in Website keeps the source, destination and suggested anchor together, with copyable HTML. Suggestions can be filtered, reviewed and exported as CSV, and appear as they are checked rather than only at the end. You remain the editor: CiteLadder finds opportunities; it does not publish links into your CMS.
A probability threshold is an operating policy, not a universal SEO rule. The right value depends on the crawl, the kind of site, the model version and the cost of a false positive, which is why every suggestion stays reviewable.
Step 5: verify the change on a later crawl
Suggestions join the source page’s Action. When you mark the links you added as implemented, a later crawl checks whether a main-content link to each destination is actually present, even if you reworded the anchor. That check needs no model call.
The internal-link workflow
System ModelRetrieve
Shortlist related, currently unlinked destinations from the crawl.
Judge
Ask Jev whether the source should link to the destination.
Review
Inspect the destination and anchor taken from its own page.
Implement
Add the links you choose to your site.
Verify
A later crawl confirms the link exists in main content.
What CiteLadder deliberately does not do
- Claim that an internal link guarantees a ranking or AI-citation improvement.
- Generate links from raw similarity alone.
- Invent anchor text or publish links automatically.
- Treat a Jev probability as an SEO authority score.
- Replace editorial judgment about navigation, merchandising or content strategy.
Internal links are one part of a broader evidence workflow. Use the content audit to find structural issues, the AEO action playbook to plan improvements, and the verification protocol to check what changed. CiteLadder solutions shows how the pieces fit together.
Sources
- Link best practices for Google — Google Search Central
- System One models — TypeSafe documentation