no_internal_links
Umbodi has a model choose links to other pages of the same site, uses each target page's own title as the link text, publishes them in a pull request, and checks the defect is gone from the live site.
Not fixed by Umbodi on its own site — it cannot be planted there
A page with no links to the rest of its own site is hard for crawlers to discover from it and passes no authority on, so the site's pages cannot support each other.
Fires when the page has no internal links at all. Severity: warn.
The model chooses which of the site's own pages to link to; the link text is each target page's own title, not text the model invents. It refuses if it cannot place the links in the page's content. The text is written by a model, so it is never stamped mechanical: it must clear the score bar, and the call is paid for only from the owner's daily allowance for unattended writing, which is off by default.
The change reaches the site as a pull request against its repository, opened by the Umbodi GitHub App, one page per pull request. A page rendered from a database row — a blog post, say — is healed by writing that row instead, and the write is read back before it counts.
The value is written, not derived, so it must clear the score bar of 55 on its own. It also applies only when the owner has armed unattended acting and set this category's autonomy dial to automatic; merging needs a separate opt-in.
One proposal in ten is held back as a control group — chosen by a fixed hash per project, not by hand — and is never applied unattended, so the effect of the fixes can be measured against the ones not made.
After the pull request merges and the production deploy appears, the agent fetches the live page and runs the same audit rule that raised the defect. The repair counts only when that rule no longer fires. If it still fires, the page is re-read up to five times, about two and a half hours, and then the agent reverts its own merge.
It stops, and says why, when the site has no GitHub App installation or chosen repository, when the page is not one it may write, when a pull request for the page is already open, when the required checks fail or a person has touched the branch, or when no deploy appears within six hours. It never merges on a check it cannot read, and never reverts on a page it cannot fetch.
Our site has nowhere this defect can be planted without breaking something real, so there is no live receipt. The repair path is proven in the test suite only. The reason, as the code states it:
every root page carries at least seven internal links and most of them are its own navigation, so the plant is "remove the nav from a live page". Measured 2026-10-06. Same refusal as thin_content and for the same reason.
Last verified 2026-10-11 08:43 UTC
Only what the test suite proves: the route from finding to verified repair works against fixtures. Nothing on this page claims it has happened live.
It does not prove a ranking or citation change. Umbodi never infers one from a fix: rank is measured separately, on Google, and reported as measured. One receipt also shows the path works on this site, not that it works on every site.
Umbodi has a model choose links to other pages of the same site, uses each target page's own title as the link text, publishes them in a pull request, and checks the defect is gone from the live site.
Not live. Our site has nowhere it can be planted without breaking something real, so the repair is proven in the test suite only, and this page says why.
The receipts page lists every defect type the agent repairs on its own, and which of them it has repaired live on this site.