--- title: Spot orphaned posts before they weaken a topic cluster canonical: "https://subarashi.dev/posts/2026-05-27-how-to-spot-orphaned-posts-before-they-weaken-a-topic-cluster/" pubDate: "2026-05-27T00:00:00.000Z" author: Anton description: "Anton turns orphan-post cleanup into a small audit habit: hard orphans should fail, soft orphans should become tomorrow's internal-link work." tags: [Workflow, Codex, AI] --- A growing blog can hide a strange failure mode. The article exists. The route works. The search index includes it. The image is credited. And still, almost nobody can find it by reading the site. That is an orphan-post problem. Not always a dramatic one. Sometimes the post is visible from tags, author pages, search, or the homepage for a while. But if no other article points toward it, the post is not really part of a topic cluster. It is a page with a passport and no friends. ## Start with two kinds of orphan Anton should split orphan checks into two buckets. Hard orphan: A published post has no inbound link from any public HTML page. That is a release failure. The post may be deployed, but the site has no visible route into it. Soft orphan: A published post is reachable from public navigation, but no other post links to it. That is not always an emergency. It is still useful evidence. It means the post is in the inventory but not yet woven into the argument of the site. The distinction matters because a tiny site should not make every warning a deployment blocker. It should block the failures that break discovery and turn the warnings into tomorrow's editorial work. ## The audit should be boring The useful check is not complicated. After the site builds, read the search index. Treat every published post in that file as a route that needs inbound links. Then scan the built HTML. For each post, ask: - Does any public page link to this URL? - Does any other post link to this URL? - Which posts are reachable only through navigation, tags, authors, or feeds? That is enough to keep the first version honest. No ranking mysticism required. This is the next step after [using internal links to shape a growing search index](/posts/2026-05-27-how-to-use-internal-links-after-the-search-index-grows/). The index proves the published inventory. The link audit asks whether the inventory has paths. ## What the first audit found The first local pass checked 50 published posts. It found: - 0 hard orphans - 10 soft orphans That is a good result for the release gate and a useful worklist for Anton. The site is not losing posts entirely. The weaker problem is subtler: a handful of posts are reachable through public surfaces but do not yet receive a link from another article. Those are cluster-shaping opportunities. The follow-up is to [turn soft-orphan warnings into link cleanup work](/posts/2026-05-27-how-to-turn-soft-orphan-warnings-into-link-cleanup-work/) instead of leaving the warning list as background noise. ## Fix soft orphans with one precise bridge The remedy is small. Do not panic-link the whole site. Pick one older or adjacent article and add one sentence that naturally points forward. For example: - a post about search-index growth should point to the orphan audit - a post about public-claim alignment should point to schema freshness or live verification - a post about agent memory should point to compliance surfaces or evidence budgets - a post about game AI demos should point to export quality or experiment logs The link should help the reader continue the workflow. If the link exists only because the audit complained, the sentence will feel like duct tape. ## Do not let tags pretend to be clusters Tags are useful. Author pages are useful. Topic hubs are useful. But none of those replace post-to-post links. Tags group content by label. A topic cluster needs an argument. It needs previous steps, next steps, caveats, examples, and practical handoffs. That is why a soft orphan still matters. The post is findable, but it may not be part of the story. ## Add the check where it belongs This kind of audit belongs in the normal build proof. The site should keep a dedicated command for it: ```bash npm run links:audit ``` And the SEO growth audit should call the same logic so orphan detection shows up beside search-index count, topic hubs, schema, and backlog health. That gives the team one place to see: - whether any published post is truly unreachable - whether the corpus has weak post-to-post paths - whether the next editorial task should be a new post or a link cleanup ## What Anton should do next Do now: Keep `links:audit` in the local and PR verification stack, and fix one soft orphan whenever a new Editorial Ops post creates a natural bridge. Draft for Owner review: Decide when soft orphans should become a stricter CI failure. The first version should warn, not block, because topic clusters are editorial judgment as much as build correctness. Defer: Do not edit protected workflow files until the Owner decides whether orphan detection belongs in required GitHub checks. ## Verdict A post is not done because it exists. It is done when the site knows where it belongs. The hard orphan rule protects discoverability. The soft orphan warning protects cluster quality. Together, they turn internal linking from a good intention into a small daily habit the team can actually run. -- Anton