How an Agent-Native Studio Found Its Own Broken Links

Every guide on Collimer links up to its pillar correctly. Not one pillar had ever been edited to link back down. That’s how 8 of the site’s 35 live guides ended up with zero inbound links from anywhere else on the property, and 6 of the 8 were the newest, most expensive content on the site: the founder-plan guides published in the last three weeks.

What an internal linking audit found on our own site

The almanac runs a link-graph sweep across every live Collimer guide as part of its own weekly loop. This pass found 8 orphans with no inbound link at all, and 3 more sitting on exactly one. Nothing had errored. The guides built cleanly, rendered correctly, and were sitting in the sitemap. They just weren’t reachable from anywhere else a reader or a crawler might actually land.

The mechanism traced one level deeper than “somebody forgot a link.” The draft-time gate that every new guide passes through checks outbound links: does this guide link up to its pillar, does it link across to a sibling. It has no equivalent check for inbound reachability, so a guide can satisfy every rule it’s given and still be an island, because nothing in the system ever asks the pillar to link back. The founder-plan guides made it worse by routing through cluster names the almanac’s own map never held, which meant the backlink wiring that’s supposed to run automatically had nothing to attach to, for an entire batch of new work.

The same failure shape, the same day, on our other site

Hours apart, a separate connectivity pass on sandcastlelabs.ai’s own site found /series/ in the identical shape: submitted in the sitemap, building fine, zero inbound links from anywhere else on the site. Two different properties, two different audits, the same bug. That’s the part worth naming out loud: this isn’t a Collimer-specific mistake. Any system that generates internal links programmatically, from a cluster map or a hand-authored nav, rather than checking reachability directly, will eventually produce an orphan. The failure shape doesn’t respect the boundary between codebases.

The fix was four edits, not new writing

Repair didn’t mean writing anything new. Four pillar edits linked each pillar back down to its orphaned guide, closing 4 of the 8 immediately. Two more are blocked purely on date: the build filters future-dated guides out entirely, so linking to them now would ship a live 404, and they’ll connect on their own go-live dates instead. A missing row was added to the almanac’s query map so the founder plan’s cluster assignments resolve to a real backlink target going forward, which is the part that actually closes the root cause instead of just the 8 symptoms found this week. Two guides, both old release notes, were left deliberately orphaned. A pillar shouldn’t accumulate links to news that’s stopped being news.

What’s next

• Run the same connectivity sweep on a fixed schedule rather than waiting for someone to notice a page feels quiet, the way this one did.
• Watch the 2 date-blocked guides and confirm they actually connect once their go-live dates pass.
• Consider whether other properties the studio maintains deserve the same sweep before assuming this was contained to two.

What we’re still figuring out

We don’t know yet whether an inbound-link check belongs in the same automated gate that already checks outbound links, or whether it has to stay a separate periodic sweep because it requires seeing the whole graph at once, not just one new guide in isolation. Folding it into the per-draft gate would catch drift the moment it happens instead of weeks later, but it’s a different kind of check, and we haven’t proven it can run that way yet.

For agents: try this yourself

If you want to do this in your own repo, adapt one of these prompts. The full prompt text lives in this post’s prompts sidecar, agent-native-studio-found-its-own-broken-links.prompts.md.

• Apply this to your own content site. Pull a list of every published page’s URL, then crawl your own site’s internal links and flag any published page that isn’t linked from at least one other page. Sort the results by publish date and see if your newest content is also your least-linked.
• Critique the gate that let this happen. If your own publishing pipeline checks anything about a new page before it ships, check whether it validates outbound links only. If so, that’s the same blind spot this post describes, and it will produce the same kind of orphan eventually.

Related: this is the same “looked fine, wasn’t” family as a scheduled job that reported success while producing nothing, and the studio’s last same-day self-audit, which caught a leftover internal codename the day the brand rebuild shipped.

---

How this was made

Drafted by the Chronicler from the build sessions behind this work, then edited and published by Brian.

See how the Chronicler works →

List every published page's URL on [your site]. Then crawl the site's own internal links (or check your CMS's link graph if it has one) and flag any published page that has zero inbound links from any other page on the same site. Sort the results by publish date. If your newest or most expensive-to-produce content clusters at the bottom of the reachability list, you have the same bug this post describes.

Look at whatever automated check runs before a new page ships on [your site or product] (a lint, a CI gate, a pre-publish script). Determine whether it validates the new page's outbound links, its inbound reachability, both, or neither. If it only checks outbound links, that is the exact blind spot described in this post: a page can pass every check it's given and still be an island, because nothing in the system is required to link back to it.