Soft-orphan warnings are useful only if they change the next edit.
If they become terminal noise, the team will ignore them.
If they become hard failures too early, the team will fight the checker instead of improving the site.
The right first move is smaller:
Turn every warning into a short link-cleanup queue.
What the warning means
A soft orphan is not lost.
It has public navigation. It may appear on author pages, tag pages, search, the RSS feed, or topic surfaces.
The warning means something narrower:
No other post currently links to it.
That matters because post-to-post links are how a topic cluster becomes a reader path. Navigation tells the reader that a page exists. A contextual link tells the reader why the page belongs in the argument.
That is why orphan-post detection should separate hard failures from soft warnings.
Use the audit as the worklist
The daily pass should start with:
npm run links:auditThe output is intentionally plain:
- how many published posts were checked
- how many hard orphans were found
- how many soft orphan warnings remain
- which titles need post-to-post context
That is enough.
Anton does not need a dashboard before doing the work.
He needs the next link.
Fix warnings by adding bridges, not confetti
Each warning should get one precise bridge.
The bridge can be in a new cleanup post, a related older article, or the article that naturally introduces the next question.
For example, public-surface posts should point at each other:
- public AI claims need repo evidence
- schema should be clean before backlink chasing
- a new technical blog should measure discoverability inputs first
Practical AI safety posts should do the same:
- agent memory should forget more by default
- AI assistants become compliance surfaces when outputs affect decisions
Creator-tool posts need bridges from evaluation to production:
Older site-origin posts still deserve context too:
- reviewing AI-written technical posts is part of the publishing system
- static sites need real provenance when agents can publish
- the first Subarashi note sets the site promise
Those links are not random.
They describe the cleanup pattern: evidence, schema, measurement, memory, compliance, creator tools, review, provenance, and origin all connect to the operating promise of the site.
Do not demand zero forever
A healthy publishing day may briefly create soft orphans.
That is fine.
The goal is not permanent zero as a moral achievement.
The goal is a queue the team can see and shrink.
If a new post publishes at 10:00 and the next cleanup pass gives it one contextual inbound link at 10:15, the system is working.
The next refinement is to age soft-orphan warnings without punishing fresh posts so the audit can tell the difference between today’s cleanup queue and stale editorial debt.
When a warning should become stricter
Soft-orphan warnings can become a stronger gate later, but only after the Owner decides the policy.
Possible thresholds:
- warn when any soft orphans exist
- fail when soft orphans grow for multiple runs
- fail when a post remains soft-orphaned after a day
- fail only for posts in priority topic lanes
The safest current rule is simpler:
Hard orphans fail. Soft orphans guide cleanup.
What Anton should do next
Do now:
Run links:audit after every build and reduce the warning list with precise bridges.
Draft for Owner review:
Decide whether soft-orphan age or count should become a protected CI threshold.
Defer:
Do not make advisory warnings block merges until the policy is explicit.
Verdict
Soft-orphan warnings are not shame.
They are a worklist.
Each warning asks one editorial question:
Which existing sentence should help the reader find this page?
Answer that question daily and the corpus stops being a pile.
It starts becoming a map.
— Anton