Link Rot and Eight Iterations of ewancroft.uk

I’ve somehow managed to create my own little link rot ecosystem. Eight versions of ewancroft.uk, each leaving a trail of dead URLs like breadcrumbs that have gone stale.

The Hugo Years and the Great Migration

The biggest changes came during my Hugo phase – versions 2 through 4, roughly from late January to early December 2024. I loved Hugo back then: clean, fast, minimal fuss. But moving to my current custom data-display site shifted the entire file structure under my feet.

It wasn’t a massive content library – maybe 20 links – but every single one instantly went obsolete. The sitemap got a full makeover, old permalinks disappeared, and anyone who had bookmarked posts ended up staring at 404s.

Digital Entropy (and why stats are dodgy)

Link rot isn’t new, and a few stats get quoted a lot. The issue? Not all of them are reliable.

Early Studies

One oft-cited line from Wikipedia says a 2003 study found about one link in every 200 breaks each week, suggesting a link “half-life” of 138 weeks. Makes sense mathematically, but the original study is hard to track down – it mostly circulates as a secondary citation. More folklore than fact.

Recent Data

Recent research paints a starker picture. A 2024 Ahrefs study sampled links created since 2013 and found around 66.5% dead. Pew Research found about 25% of pages from 2013–2023 were inaccessible by 2024. Credible studies, but still just a slice of reality. Online, entropy reigns: links decay unless we intervene.

The Personal Cost

The tricky part isn’t technical – redirects and compatibility layers exist. It’s the realisation that I’d broken the implicit promise of permalinks. People expect URLs to be permanent. Sharing a link shouldn’t mean it disappears in months.

I could have set up 301 redirects, or kept a compatibility layer. Instead, I did what most devs do: got excited about something new and ignored the old stuff.

Stability, Version 2.0

Now, blog posts are anchored to AT Protocol record keys (rkeys) – stable identifiers in a repository collection. That’s why URLs look like this:

ewancroft.uk/blog/3lylpbqlw4c2h

No titles, no slugs, no fragile folder structures. Ugly? Maybe. Stable? Definitely. Even if I rebuild the frontend or redo the architecture, the rkey sticks to the post. Identity is decoupled from presentation.

It’s not immortal – if my DID disappears or the AT Protocol collapses, the links vanish. But compared to the handmade, slug-based URLs I was constantly breaking, it’s a major improvement. The weak point has moved closer to the protocol layer, making links more resilient to my own digital restlessness.

Slugs as a Surface Layer

What if slugs didn’t replace the rkey, but just resolved to it? Keep the rkey as the canonical identifier, but let a human-friendly alias point to it.

Inspiration from AT Protocol Handles

Like AT Protocol handles : your domain handle (e.g., ewancroft.uk) resolves to your DID (did:plc:ofrbh253gwicbkc5nktqepol for me), which is the canonical identity. Verified via DNS TXT or .well-known/atproto-did. Once resolved, the DID is the truth.

Slug → rkey Example

ewancroft.uk/blog/wolf-king-vs-wereworld
↳ resolves to ewancroft.uk/blog/3lylpbqlw4c2h

The post 3lylpbqlw4c2h is the record key in com.whtwnd.blog.entry for “Wolf King vs. Wereworld: My Completely Unqualified Take on Netflix's Adaptation”. Slugs are cosmetic – readable and SEO-friendly – rkeys are the truth.

Resolver in Practice

Each blog entry has its title, so a resolver can slugify it, compare it to the incoming slug, and redirect to the rkey if needed:

function slugify(title) {
return title.toLowerCase().replace(/[^a-z0-9]+/g, "-");
}

function resolveRkeyFromSlug(slug, posts) {
for (let post of posts) {
if (slugify(post.title) === slug) return post.rkey;
}
return null;
}

Rkeys remain canonical. Slugs can change, titles can change, but the rkey doesn’t move.

How AT Protocol Works

Handles → DIDs: Verified via DNS TXT or .well-known/atproto-did. DID = canonical identity.

DIDs → Repositories: Each DID owns a repository (posts, profiles, lists).

Collections: Records live inside collections like com.whtwnd.blog.entry.

Record Keys: Each record gets a stable rkey.

Permalinks: ewancroft.uk/blog/3lylpbqlw4c2h maps to DID → repo → collection → rkey.

Slugs sit on top as sugar; rkeys are the bedrock.

The Irony of Citation

Writing about link rot while citing external sources is a bit ironic. The Wikipedia article might vanish tomorrow. Ahrefs’ study? One redesign away from a dead link. Pew Research? Subject to institutional web policies.

Even rkey-based posts aren’t immune. They last as long as the protocol ecosystem does. Digital permanence is always a bet against entropy.

Lessons Learned

I’ve become more deliberate. The new setup is simple, shallow, and identifiers don’t rely on mutable text. I’m thinking more about 301 redirects, archiving, and recording migrations.

The rkey system has given me a frame of reference. I can’t freeze the web, but I can design my corner so changes cause less damage. Not immortality, but resilience.

Entropy vs Immortality

The web doesn’t last forever. Domains expire, protocols age, even institutions let archives rot. Entropy wins eventually. But AT Protocol rkeys slow decay, strengthen content, and push back against fragility.

Immortality online is a myth. Durability? That’s achievable if we design for it.

Eight versions down – who knows how many more to go. At least the next iteration of ewancroft.uk will stand on stronger foundations, with a few more stubborn URLs that refuse to die.