The 404 on Page One: How Stale How-Tos Quietly Break a Team's Trust

There is a particular kind of silence that follows a new starter clicking a link in the onboarding wiki and landing on a 404. Nobody shouts. Nobody files a ticket. They just quietly ask in the team chat instead, and the answer disappears into the scroll. That little moment is where link rot starts to cost you.

Most UK teams have an intranet, a shared drive, a Notion space, or a SharePoint site that grew up organically. It is full of how-tos written by people who have since moved teams, left the company, or been through two restructures. The screenshots show an old version of the finance system. The process references a Slack channel that was archived in 2024. The link to the holiday request form points at a page that no longer exists. None of this is dramatic. It is just quietly wrong.

The real cost is not the dead link

A broken link takes four seconds to hit and maybe ten minutes to work around. That is not the expensive part. The expensive part is what people learn from it: that the wiki cannot be trusted. Once that idea takes hold, the whole knowledge base starts to lose its authority. People stop checking it first. They ask a colleague instead. The colleague answers from memory, which may be out of date too. Knowledge drifts back into inboxes and chat threads, and the intranet becomes a museum of old intentions.

There is also a politeness problem specific to British teams. If you find a stale page owned by someone in another team, the instinct is not to fix it. It is to think, "That is probably Dave's area," and move on. Dave left eighteen months ago. Nobody wants to be the person who edits another team's page without asking, so the page stays broken and everyone works around it. Multiply that by forty pages and you have a knowledge base that is technically online but practically abandoned.

Why "someone will fix it" never happens

Link rot is a classic diffusion-of-responsibility problem. Everyone assumes the page owner knows. The page owner assumes the wiki admin checks links. The wiki admin assumes each team maintains its own section. Nobody has been given the job, so nobody does it. Meanwhile, every reorganisation resets the map. The person who wrote the how-to for booking a meeting room is now in a different department, and the process has changed twice since they wrote it.

The result is a slow accumulation of small inaccuracies. A screenshot from 2023. A form that moved. A step that references a tool you no longer pay for. Each one is minor. Together they teach the team that the intranet is a best-guess archive rather than a reliable source. That is a trust problem dressed up as a housekeeping problem.

Make ownership visible, and let pages expire

The fix does not require a new platform. It requires two small pieces of metadata on every page that matters: an owner and a review date. Not a committee. Not a documentation strategy. Just a name and a date.

An owner is the person who would notice if the page went wrong. It does not have to be the original author. It just has to be someone currently employed, currently in the relevant team, and willing to spend fifteen minutes a quarter checking that the page still tells the truth.

A review date is the expiry label. When the date passes, the page gets a gentle banner: "This page is due for review. Last verified [month, year]." That banner is not a failure. It is an honest signal. A wiki that admits what it has not checked recently is far more trustworthy than one that pretends every page is evergreen.

You can do this in whatever tool you already use. Add two fields to the page template. Put the owner's name at the bottom. Set a recurring calendar reminder for the review date. The point is not the software. The point is that the page has a human attached to it.

The ninety-minute afternoon audit

If you want to find the worst offenders before you roll out a routine, block out an afternoon. Not a full project. Ninety minutes, one laptop, and a mug of tea.

Start with the pages a new starter is sent to in their first week. Those are the pages where link rot does the most damage, because the audience has no context to fall back on. Check every link on each page. Not just the ones that look suspicious. Click them. Note which ones fail, which redirect somewhere unexpected, and which point at a document that has not been updated since the last reorg.

Next, look at the screenshots. If the interface in the image no longer matches the interface in the tool, the page needs a review. You do not have to fix it on the spot. Just add it to the list.

Then, for each broken page, write down two things: who currently owns the process, and whether the page should be fixed, rewritten, or retired. A surprising number of stale pages should simply be deleted. They describe a process that no longer exists. Keeping them online is worse than removing them, because they compete with the accurate version for attention.

Finally, pick the five worst pages and fix them this week. Not all forty. Five. That gives the team a visible win and proves the audit was worth doing. Add the owner-and-review-date fields to those five pages and set the first review reminder. You now have a small, working example of the routine.

The wiki that says "I don't know" is the one people trust

Link rot is not a technology problem. It is a maintenance problem, and maintenance needs a name and a date attached to it. The teams that keep their knowledge base useful are not the ones with the fanciest tools. They are the ones where every important page has someone who would notice if it went stale, and where a page is allowed to say, "This might be out of date."

That honesty is what rebuilds trust. A new starter who clicks a link and finds a current page learns that the intranet is worth checking. A new starter who clicks a link and finds a 404 learns to ask a colleague instead. The difference between those two experiences is not a big IT project. It is a ninety-minute audit and a calendar reminder.