Businesses stop. Not usually with an announcement, and rarely with a final post explaining why. More often a domain quietly stops resolving one week and never starts again, and everyone who linked to it is left holding a reference to something that is no longer there.
For the broader context behind this business guide, read Our Entry Bar, In Full: And Everything We Turn Down.
Most listing sites handle this by doing nothing, because doing nothing is free and checking is expensive. The second most common approach is to delete the record, which tidies the index and destroys the history. This site does neither, and this post is the sequence that runs instead.
Before it starts, the scope: this article specifies the tombstone process; it is not an incident report. No business event is implied by the examples below.
What this is, and who it is for
Two readers. The person who followed something from here and found nothing at the other end, who wants to know whether anyone is maintaining this. And the operator who has just discovered that a register somewhere is describing their business in the past tense.
The second reader is the one this whole procedure is designed around. Marking a trading business as closed is the most damaging error this site can make, and the sequence below is slow specifically because of that.
The three states between trading and gone
An entry is not either alive or dead. There are three intermediate states, and an entry can sit in any of them without anything appearing publicly.
Changed. The business is reachable and something material about it is different — it does a different thing, or the way you reach it has gone. This is not a closure and it is not treated as one. The entry goes back to a person for re-review against the entry bar, and it is either rewritten or removed. A removal on these grounds is not an accusation and the note says only that the entry no longer meets the bar.
Unreachable. A check found nothing, or found something that is not the business. This is a result, not a conclusion. Nothing is published, nothing is flagged publicly, and no inference is drawn. The entry waits.
Awaiting confirmation. A second check has also failed, and a person has been asked to confirm independently. This is the only state in which closure is being actively considered, and it is still not published. If confirmation does not come, nothing changes.
Only after all three is there a fourth state, and it is the only one visible from outside.
Why one failed check is never enough
Sites go down. Certificates expire on a Friday afternoon and nobody notices until Monday. Hosting invoices bounce because a card expired. An owner takes two weeks off and pauses the shop. A domain transfers between registrars and resolves inconsistently for a day. A site moves and the old address stops answering before anyone updates the link.
Every one of those produces exactly the same signal as a business that has closed permanently: nothing answers.
So a single failure means nothing, and treating it as meaningful would be treating an outage as a death. The asymmetry here is what drives the design. If we are slow to record a closure, a reader might follow a link to a business that has shut, which is mildly annoying and self-correcting. If we are fast and wrong, we have published that somebody's living concern has ended. Those two errors are not comparable and the procedure does not pretend they are.
The waiting period, and why it is that long
The threshold is two failed checks separated by at least fourteen days, and only then the confirmation step.
Fourteen days is not arbitrary. It is long enough to survive the ordinary causes of a temporary absence — a holiday, a billing problem, a hosting migration, a seasonal pause, an illness. Anything shorter starts catching outages. It is also short enough that the register does not carry an obviously dead entry for months.
What the interval deliberately does not do is optimise for the index looking accurate. A shorter window would make the tombstone index more current and would also make it wrong more often, and given the asymmetry above, that is not a trade we are willing to make.
The first failure and the second are both produced by the ordinary re-check procedure described in the check that catches it. Nothing special happens on the first failure except that a clock starts.
The human confirmation step
Two automated-and-reviewed failures still are not enough on their own. A person confirms independently before anything is published.
What that person is doing is looking for a positive indication that the business has ended, rather than a continued absence of a response. Absence of evidence is where the previous two steps already got to; the confirmation step is trying to find evidence.
What counts varies by the kind of business, and for a physical business it is stricter and slower again — how we confirm a shop specifically has closed covers that lane, including what we will not do to establish it.
What does not count, in any lane: a rumour, a third-party report on its own, a marketplace profile going quiet, or an inference from a domain being listed for sale. A report from a member of the public starts a check; it never substitutes for one.
If confirmation cannot be obtained, the entry does not become a tombstone. It may be removed for no longer meeting the bar, which is a different and much weaker statement, or it may simply continue to wait.
What a tombstone contains, and what it deliberately omits
A tombstone is a record that an entry existed and no longer does. It replaces the entry in place rather than deleting it, so that a link from elsewhere lands on something honest instead of on nothing.
What it contains: the business's name as we recorded it, our own one-sentence description of what it was, the date of the final check, the method version that produced that date, and the fact that the check sequence completed.
What it deliberately omits: any reason. Any assessment. Any adjective. Any final word about the business, its owner, its quality or its prospects. No "sadly closed", no "one of our favourites", no expression of regret, and above all no explanation.
It also omits everything the entry never carried in the first place. A residential address is never published on this site, and it is not published on a tombstone either. Nor is any contact detail that exists only so somebody can be pursued after their business has ended.
Why we never state a reason unless the owner published one
This is the rule with the least room in it, so it is worth explaining properly rather than asserting.
When a business ends, the owner is in the middle of something difficult, and the account of why it happened is theirs to give or withhold. A register that publishes an explanation has taken that decision away from them, permanently, in a place they cannot edit. Whatever we wrote would follow the business name around, would be read by people who knew them, and would be wrong often enough to be indefensible even when it was well meant.
We are also, straightforwardly, not in a position to know. From outside, a business that closed because the owner retired comfortably and a business that closed under pressure look exactly the same: nothing answers.
So the rule is: if the owner published a reason, we can link to what they published. If they did not, there is no reason on the page. Not a hedge, not an implication, not a carefully neutral phrase that gestures at one. Nothing.
That extends to what a tombstone must never be allowed to become. It is not a judgement, not an obituary, and not a lesson. A tombstone is a record with a date on it.
Businesses that moved, rebranded or paused
Three cases that look like closure at the first check and are not, each handled differently.
Moved. A business at a new address, online or physical. This is a changed result, not a closure. The entry is re-reviewed and updated, and the check date advances on the basis of the new check rather than the old one. If the old address is still linked from elsewhere, that is a link problem, not a closure.
Rebranded. The same operation under a different name. Also a changed result. The entry is rewritten. It becomes a closure only if the underlying operation genuinely ended, which is a question about the business rather than about the name.
Paused. Seasonal closures, sabbaticals, waiting lists closed, a shop shut for a refit. These are the cases the fourteen-day interval exists to survive. Where a pause is stated anywhere, the entry is flagged rather than removed, and the flag says what it is. Where it is not stated, the procedure is genuinely weak, and that weakness is named in the method rather than papered over.
The general principle across all three: a tombstone means one specific thing, which is that the check sequence completed and a person confirmed the business had ended. Anything else gets a different treatment.
The route back: reinstatement after a mistake
If a tombstone is wrong, it comes down, and this route is as important as anything above it.
How to start it. Tell us at our correction log, or by any route you can reach us. If you would rather the entry be gone entirely rather than reinstated, request a removal or a correction is faster and requires no reason at all.
What we ask for. Effectively nothing. Reinstatement does not require an operator to prove anything beyond being there. There is no evidence threshold, no form, no waiting list and no charge, and there is no version of this where a business has to argue its way back into existence.
What happens. The tombstone is removed, the entry is restored, and a fresh check is run so that the date on it is real rather than recovered. The error goes into the public correction log with what was wrong, how it was caught, what changed, and how long it took. The log records whether we caught it ourselves or somebody else did, and that column is not rounded in our favour.
What also happens. The sequence that produced the error is reviewed, because a false closure means the procedure failed rather than that someone was unlucky. If the review changes the method, that is a versioned change with its own changelog entry.
There is no queue for this and no charge for it, for the same structural reason there is no paid queue anywhere on this site: money has no route to a listing decision here, in either direction.
What we do if the business asks us to remove the tombstone instead
Some operators do not want a reinstated entry and do not want a tombstone either. They want the record gone.
That is honoured, and it is honoured without asking why. Request a removal is the route, removal is the fastest thing we do because it requires no judgement, and the record leaves the site and the machine-readable exports together. A consumer holding a cached copy is asked to honour the removal on their next fetch.
What remains internally is the minimum needed to make a "never list again" request stick and to keep the correction log coherent — essentially a note that a removal happened and when. We do not keep the removed entry for future use.
Two clarifications operators ask about. Removal is not conditional on the business being reinstated first; you can go straight to it. And a removal is never announced, which means that some absences on this site are legitimately unexplained, and we would rather that than announce something somebody asked us to take down.
If you arrived here because something you followed from this site led nowhere, what to do if you hit a dead one covers that from your side. If you want to see the sequence in the round, it sits inside our method alongside everything else that produces a date.
In Plain English
When a listed business seems to have vanished:
- One failed check means nothing. Sites go down for a hundred ordinary reasons that look identical to closure from outside.
- The threshold is two failed checks at least fourteen days apart, then a person confirming independently. Nothing is published before all three.
- A closed business becomes a tombstone, not a deletion. Name, our description, final check date, method version. No reason, no adjective, no judgement.
- We never state why a business closed unless the owner published it themselves. From outside, every closure looks the same, and the account belongs to them.
- Moved, rebranded or paused are not closures and are handled as changes.
- Getting it wrong is the worst error this site can make. Reinstatement is free, needs no proof beyond being there, and the mistake goes in the public log.
- Or we take the record down entirely if that is what the operator wants, with no reason required.
Gone is the complete tombstone schema and procedure. It does not represent a live row unless the required checks, dates, and confirmation are present.
Read the tombstone procedure → /gone/