Anyone who has clicked through a listing site has met the same thing: an entry that looks fine, describes a business plainly, and turns out to lead somewhere that closed. The usual explanation is carelessness. The better explanation is a cost structure that makes carelessness the default outcome of running the site correctly according to its own incentives.
For the broader context behind this business guide, read What We Lost When The Blogroll Died.
The symptom this explains has been covered separately. This piece is about the layer underneath it.
What this is, and who it is for
For anyone who wants to know why lists rot, and for anyone considering building one who has not yet worked out what they are signing up for.
The argument does not require anybody to be lazy or dishonest. It works with everyone acting reasonably. That is what makes it worth writing down.
Intake as a one-off cost
Adding an entry to a collection is a bounded task. Somebody finds or receives a candidate, looks at it, writes a description, files it under a category, and publishes. It is done. Whatever it cost, it cost once.
Intake also has properties that make it attractive to fund:
- It produces something visible. The collection is larger than it was. You can see the difference, screenshot it, and describe it in an update.
- It is easy to measure. Entries added is a number anybody can count, and counting it requires no judgement.
- It can be parallelised. More hands means more entries, more or less linearly.
- It can be outsourced or accepted from outside. A submission form makes candidate supply somebody else's problem entirely.
Every one of those properties describes a cost that an organisation is comfortable paying, because it converts money into an observable result.
Accuracy as a recurring cost
Keeping an entry true is a different kind of task, and the differences run in exactly the wrong direction.
The recurring work, per entry, per cycle, looks like this:
- Check the destination still responds and resolves to the same place rather than a parking page, a holding page, or somebody else's site.
- Check the thing is still what the description says. A shop that became a blog, a service that became a waitlist, a maker who stopped selling and now only posts photographs — each of these leaves the listing technically working and factually wrong.
- Check the business still appears to be trading, which is a judgement rather than a status code and is the part no tool answers.
- Decide. Keep, amend, or remove. Removal usually needs a second look, because a site being down for a day is not a business closing.
- Record what happened, with a date, so a reader can see when the claim was last true.
Then repeat, forever, for every entry, on a cadence.
Now the properties, and they are the mirror image of intake:
- It produces nothing visible when it succeeds. An entry that was checked and is fine looks exactly like an entry nobody looked at.
- It is hard to measure meaningfully. Checks run is a number; checks run properly is not, because the value is in the judgement calls.
- It does not parallelise well where judgement is involved, and judgement is involved in the expensive part.
- It cannot be outsourced to the listed party. Asking a business to confirm it still trades gets a reply from the ones that do and silence from the ones that do not, which is the opposite of the sampling you need.
Who pays for intake, and who pays for accuracy
Follow the money in the ordinary listing business and the pattern is immediate.
| Intake | Accuracy | |
|---|---|---|
| Produces a visible result | Yes | No |
| Countable | Yes | Only superficially |
| Someone else can supply the work | Yes, via submissions | No |
| Generates a page that can attract traffic | Yes | No, the page already exists |
| Someone will pay for it | Frequently | Rarely |
| Cost shape | One-off per entry | Recurring per entry, forever |
The last row is the whole argument. A one-off cost that produces a permanent asset is an investment. A recurring cost that produces no visible change is an expense. Organisations fund investments enthusiastically and cut expenses under pressure, and no organisation has ever been praised for the entries it did not add.
There is also a second asymmetry. Intake grows the thing that generates revenue: more entries mean more pages, more coverage claims, more surface. Accuracy does not grow anything. At best it prevents a slow loss of trust that is invisible until it has already happened. How the various listing business models actually work is covered at how directories work.
Why nobody's business model funds the second one
Take the ways a collection can be funded and check each against the recurring cost.
Advertising against listing pages. Revenue scales with pages and traffic, so the incentive is toward more entries. A removed entry is a removed page and a small revenue loss, which means the model charges you for accuracy in both directions.
Paid inclusion or paid placement. The listed party pays. Removing a paying party is a direct revenue loss, so the collection acquires a financial reason not to prune exactly the entries with the strongest commercial motive to stay.
Lead generation. Revenue comes from passing enquiries onward. A dead entry generates no leads and no revenue, so it costs nothing to leave, and removing it costs the labour of checking. The rational move is to leave everything and let dead entries go quiet.
Subscriptions from readers. This one could in principle fund accuracy, since readers are the party who suffers from decay. In practice readers are choosing between a paid accurate collection and free inaccurate ones, and the inaccuracy is not visible at the point of choosing.
Volunteer effort. Funds it until the volunteer's circumstances change, and then stops immediately with no handover.
Grants and donations. Fund a project rather than an ongoing obligation, and obligations outlive projects.
The common shape across all six: revenue attaches to the existence of entries, and the cost of truth attaches to the maintenance of entries. Nothing in the ordinary structure connects the two.
That is a statement about these six models and the incentives inside them. It is not a claim that no collection anywhere pays for re-checking. Some plainly do, and where one does, the money is arriving from somewhere outside the list above — an institution with a reason to hold accurate records, a parent business for which the collection is a cost of doing something else, or somebody choosing to absorb it. The useful question to put to any collection, including this one, is therefore a specific one rather than a suspicious one: which of these models is it running on, what does it say pays for the re-checking, and does it publish a date you can use to see whether the re-checking is actually happening. If a collection's own pages cannot answer that, the first row of the table is usually the answer.
What automation can and cannot absorb
Being precise about this matters, because "we automate it" is the standard answer and it is half true.
What software can do, reliably. Fetch a URL and record the response. Detect a domain that no longer resolves or has lapsed. Detect a redirect to somewhere unrelated. Detect a page whose content has changed substantially since the last capture. Detect a certificate that expired. Flag anything in those categories for a human. All of that is cheap, runs on a schedule, and genuinely lowers the cost of noticing.
What software cannot do, at any price we can see. Decide that a site which still loads perfectly represents a business that has quietly stopped taking orders. Decide that a working shop is now a dropship front. Decide whether a change in what a business sells means the entry should be amended or removed. Decide whether a business that has gone silent for two months has closed or has gone on parental leave.
The distinction is between detecting change and judging meaning. Automation is good at the first and does not do the second at all. So it lowers the fixed part of the recurring cost and leaves the judgement part untouched, which is the expensive part per entry.
That is also why an entry count is a poor measure of a collection's value. A count tells you how many things were once added. It says nothing about when any of them was last true, and the two numbers can diverge for years without anything visible happening. Why curation can't scale puts the same arithmetic from the other direction.
What a register that prunes has to give up
If you decide to pay the recurring cost, four things go.
Size. Every entry is a permanent obligation, so the collection can only be as large as the sustainable checking capacity. It will be small compared with anything that skipped this step, and comparisons on size will always be lost.
Growth as a story. A collection that removes as well as adds will sometimes shrink. That is a healthy signal and it reads as failure to anyone measuring the obvious way.
Coverage claims. You cannot say a category is covered when you are only carrying what you can maintain. Every hub has to be honest that it is partial.
Some revenue models entirely. Paid inclusion becomes impossible, because you have created a financial reason not to remove someone. So does advertising against the count.
There is a fifth thing that does not go and that we should not pretend otherwise about: we will get this wrong at some scale. Every collection that has tried this has eventually found the checking cadence slipping behind the entry count, and the honest defence is not confidence, it is publishing the dates so the slippage is visible to a reader before it is visible to us. Entries confirmed gone stay published as tombstones at Gone, rather than being deleted, so the decay is on the record.
Our own numbers, such as they are
We do not have any, and it would be easy and wrong to produce some.
This piece publishes no figure for site-specific effort, cadence cost, or capacity because it presents no dated operational log from which to calculate one. The framework separates fixed and variable work without implying an unperformed measurement.
The check date on an entry is the evidence available to a reader: drifting dates show a slipping cadence without requiring a house cost claim. What checking costs describes the procedure, and the sourcing rules are at our source ledger.
In Plain English
Adding an entry to a list costs you once. Keeping it true costs you every cycle, forever.
Intake is visible, countable, easy to parallelise, and something people will pay for. Accuracy is invisible when it works, hard to measure, difficult to delegate, and almost nothing funds it. So collections add, and mostly do not prune, and eventually describe a web that no longer exists.
Nobody has to be careless for that to happen. Every funding model available attaches revenue to entries existing rather than to entries being true, so the rot is the outcome of doing the ordinary thing.
Software helps with the cheap half: it can tell you something changed. It cannot tell you what the change means, and that judgement is where the cost sits.
A collection that pays the recurring cost gives up size, growth as a story, and any claim to coverage. This article publishes no house cost figure because it contains no dated work log from which to calculate one. The reusable conclusion is the accounting method above: record time per check, checks per cycle, and the number of entries actually maintained.
See how we check: the procedure, the cadence, and what makes a check fail.