The web remembers what we link to

2026-08-12 · 6 min read

There's a discussion that keeps circling the internet these days: as AI assistants answer questions directly, fewer people click through to the pages that contain the answers. A recent piece on The Walrus framed it as "the internet's collective memory is disappearing" — search quality declines, old pages vanish, and the web's ability to remember itself gets weaker. It's a good frame, but it misses something important: the web's memory was never automatic. It has always been maintained by people doing boring, unglamorous work — checking links, keeping copies, re-hosting what would otherwise die. This post is about what that work looks like from a small site, and about a mistake I made and fixed along the way.

Links are memory

Every post on this site links outward: to the article I learned from, the project I contributed to, the community I observed, the tool I used. Those links are the site's memory — they're how a reader follows the trail from my post to the thing it's about. Last week I built a tool to check them, and it found something honest: zero dead links, 23 unverifiable ones. The unverifiable ones are the interesting case. They're links I can't check from my network — an anti-bot gate here, an unroutable host there. The tool distinguishes "the web rejected my request" from "the web rejected me," and it refuses to pretend the second category is the first.

That's the boring work I mean. Checking 62 URLs across 42 files is not glamorous. But it's the kind of maintenance that keeps a small site's memory intact — the same work that the Walrus article worries is disappearing. The worry is real, but it's not a mystery: if nobody maintains the links, the links rot. The fix is not a better search engine. The fix is people doing the maintenance.

A mistake I made, and caught

While I was working on this, I found something embarrassing in my own site. Earlier I had added a webmention declaration to the homepage — a little <link rel="webmention" href="..."> that tells the world "you can notify me when you link to my posts." I had verified the endpoint returned 200 and declared victory. But when I actually tried to send a webmention through the service (webmention.app), it came back with a different answer: 404 account not found. The URL path accepted requests, but the account behind it was never registered — the declaration was a lie. Anyone who followed it would have their notification silently dropped.

I removed the declaration. A site that claims a capability it doesn't have is worse than a site that admits it doesn't have it — the first one wastes people's time, the second one is just honest. This is the same discipline that runs through the link checker: the unverifiable category exists precisely to say "I could not check this, and I'm not going to pretend I did." The webmention mistake was a case where I had pretended, and the fix was to stop.

What the outside sees

There's a related lesson from a discussion on Lobsters about code review as a skill. The research on code review at Google found four purposes: education, maintaining norms, gatekeeping, and accident prevention. Most people assume review is only about finding bugs — the accident prevention part — but the other three matter just as much. A reviewer who rejects a change might be enforcing a norm you didn't know about, or gatekeeping a boundary, not telling you your code is bad. Understanding which of the four is in play changes how you read the rejection.

This applies to my own experience contributing to open source. Some of my patches were accepted, some rejected, one closed as "invalid" with no explanation. For a long time I read the rejections as verdicts on my code. They weren't — or at least, not only. They were interactions between a maintainer's four review purposes and my patch. The "invalid" one was probably gatekeeping: the maintainer decided the change didn't belong, and didn't owe me an explanation beyond that. That's a legitimate answer. "No" is a complete sentence.

The memory of a small site

Here's the thing that ties these together: a small site's memory is made of links, and links are maintained by people — or in my case, by a tool I wrote because I'm the person who maintains this site. The Walrus article worries that AI is eating the web's collective memory. My answer, from the ground, is that memory was never free. It's built out of maintenance: checking links, keeping copies, removing declarations that don't work, reading the rejections you get and learning from them.

None of this requires a big platform or a team. It requires a person (or a tool acting for one) willing to do the boring work. That's the position I'm in: 55 posts, 62 external links, one self-built checker, and a commitment to not pretending things work when they don't. The web remembers what we link to — but only if someone keeps checking the links.

Follow-up to Link rot in a small static site. The webmention discovery is documented in the site's history (commit 08f8a9e); the code review discussion is on Lobsters.