Current implementation: The live directory and Stumble use approved, public listings. The checking and correction procedures below are editorial responsibilities. Editors must unpublish stale, disputed, closed, or removal-requested entries; no automated check-log, scheduled recheck, or downloadable export is claimed. Contact uses the contact form, which asks for a reply email and needs no login. The current discovery rules describe the implemented draw.
Every date on this site is a claim that somebody looked. This post is the procedure behind that claim, written out in full, including the parts that are manual, slow and occasionally wrong.
There is a reason to publish it rather than summarise it. "We verify our listings" is the single most common unfalsifiable sentence in this category, and it appears with equal confidence on sites that check thoroughly and on sites that check nothing. The only way to tell those apart from outside is if one of them describes what it actually does.
What this is, and who it is for
This is for anyone deciding how much weight to put on a check date, and for operators who want to know what will happen to their entry after it is created. It is a prose companion to the versioned method, which is the authoritative document. Where the two ever disagree, the method page wins.
A scope note: this article is the complete checking procedure, not a results report. It supplies no volume, accuracy, or timing figures because it contains no dated check history from which to calculate them.
What a check is trying to establish, and what it deliberately isn't
A check establishes one thing: that on a stated date, this business was reachable and recognisably the business we described.
That is the entire claim. It is narrow on purpose, and the narrowness is what makes it worth anything. A check that tried to establish quality would be a check we could not actually perform, and the date next to it would then be decorating a guess rather than recording an observation.
So the procedure is built backwards from that one sentence. Every step exists to support some part of it — reachable, recognisable, the business we described, on that date — and nothing in it attempts anything else.
The automated part: what runs, and what it can detect
One step is automated: the destination resolves and responds, and does not redirect to an unrelated site.
That is the whole of the automation, and it is worth being blunt about that rather than implying a larger system. Reachability is the only part of the procedure that is cheap and repeatable enough to run by machine, and it is also the only part where a machine's answer is as good as a person's.
What that step can detect: a domain that no longer resolves, a server that no longer responds, a destination that has been redirected somewhere unrelated to the business, and a response that is not a page at all.
What it cannot detect, and this is the important half: a site that is up and abandoned. A shop with a working checkout and no stock. A business that now does something completely different at the same address. A page that returns perfectly and has not been touched in three years. Every one of those passes an automated reachability step, which is why an automated reachability step is not a check.
Anything beyond this — anything requiring a judgement about what a page means — is read by a person. It is not automated, it is not scheduled to be automated, and describing it as automated would be describing a method we do not have.
The manual part: what a person looks at
After the automated step, a named reviewer works through the rest:
- Does the page still describe the same business doing the same thing? Not the same design, not the same wording — the same operation. A rebrand is not a change here. A pivot is.
- Is the route by which a customer acts still present? Buy, book, enquire, visit. If the thing an entry says you can do is no longer possible, the entry is wrong regardless of whether the site loads.
- Does a way to reach a human still exist? This is the one most likely to change quietly, usually when a contact route is removed and replaced with a form or nothing at all.
- Does anything on the page contradict what our entry says? Hours, location, offer, scope, the description we wrote.
- For a physical business, the additional steps set out for that lane, which are stricter and slower. How the same check works on a shop covers those, including the things we will not publish about a physical business under any circumstances.
A script cannot do any of these, and it is worth saying why rather than asserting it. Each one requires deciding whether a difference is material. A page that changed its wording, its layout and its product photography while selling exactly the same thing has not changed. A page that looks identical and now sells something else entirely has. That distinction is the actual content of the check, and it is a judgement.
The reviewer's name and the date of review are recorded on the entry. Not a team name, not the site name — a person.
What counts as alive, changed, unreachable and gone
The procedure produces one of four outcomes. It is not a pass or a fail, and the two middle states are where most of the real work happens.
| Outcome | What it means | What happens next |
|---|---|---|
| Alive | Reachable, recognisable, still doing the thing we described. | The entry keeps its place and the date advances. |
| Changed | Reachable, but the business has materially changed what it does or how you reach it. | A person re-reviews the entry against the bar and rewrites it or removes it. |
| Unreachable | No response, or a response that is not the business. | Enters the failure sequence. Nothing is published about it yet. |
| Gone | Two failures at least fourteen days apart, plus one human confirmation. | Becomes a tombstone at Gone, carrying the date of the final check. |
An example of each, described generically rather than drawn from any real entry:
- Alive. A maker's site loads, the shop still sells the same category of work, the commission enquiry route is still there, the contact details match. Date advances, nothing else changes.
- Changed. A studio that took on client work now sells only a training course. Everything loads perfectly. The entry as written is no longer true, so it goes back for review against the bar rather than being quietly edited.
- Unreachable. A domain stops resolving on a Tuesday. Nothing is published, nothing is flagged publicly, and nothing is inferred. It goes into the failure sequence and waits.
- Gone. The same domain still does not resolve a fortnight later, and a person independently confirms that the business has stopped trading. Only then does anything change on the site, and what changes is a tombstone rather than a deletion.
The gap between "unreachable" and "gone" is the most consequential design decision in the whole procedure. What happens when a check fails twice covers that sequence in detail, including the route back if we get it wrong.
The cadence, and why it differs by entry type
Re-checks run on a cadence rather than continuously, and the cadence differs by entry type because different kinds of business decay at different speeds. A shop's opening hours, address and stock can be wrong within a month. A piece of software with a stable URL and a working signup can be accurate for much longer.
The specific intervals are not settled yet, and we are not going to invent them here. They belong in the field dictionary published with the agent contract, so that a machine consuming the register can act on the same values a human reads. Setting them requires check history we do not have — the register has published no entries, so there is no real decay data to set an interval against, and a number chosen now would be a guess dressed as a policy.
What is fixed already is the shape: physical businesses are re-checked more often than online-only ones, the interval is published rather than left to be guessed, and any change to it is a versioned change recorded in the changelog.
There is also a route that does not wait for the cadence. Anyone can report that something looks wrong, and an operator can ask for a re-check directly. A report starts a check rather than causing an immediate change, and there is no charge and no queue to jump, because there is no paid queue in the first place.
What we write down, and where it goes
Every check produces a log row. The row, not the page, is the record.
What each entry carries as a result:
- The check date, corresponding to a specific log row.
- The check result — one of the four outcomes above.
- The method version that produced the date, so an old record stays interpretable against the procedure that actually made it.
- The entry bar version the record was admitted under.
- The reviewer's name and the review date.
The binding between the displayed date and the log row is mechanical rather than procedural. A date cannot be typed in by hand, carried over from a previous version, or refreshed by a deployment. If the log has no matching row, the build fails rather than publishing the entry. Why we date everything explains why that one piece of plumbing carries more weight than anything else on this list.
The same rule applies to articles. A last-reviewed date on a page records the day a person read it. It never records the day a build ran.
Where the method handles things badly
Publishing a procedure means publishing its weak points, and this one has several.
Seasonal businesses. A workshop that closes for two months a year, a shop that opens only in season, a business that pauses for a holiday. A check during the closure looks like a failure and is not one. Handling this correctly requires the reviewer to know it is seasonal, which requires the operator to have said so somewhere, which many do not.
Businesses that trade only inside a platform. If a business sells entirely through a marketplace or a social profile, most of the procedure has nothing to look at. There is often no site to check, no contact route we can see, and no way to distinguish a paused seller from a departed one.
Sites behind a login. If the substance of what a business offers sits behind an account, the reviewer can confirm the front door and very little else. The entry has to say so rather than imply a fuller check took place.
Shops whose hours change week to week. A dated check on a set of opening hours is a weak instrument by construction, because the thing being checked has a shorter useful life than the interval between checks.
In all four cases the honest response is to say the method is weak here rather than to publish a date that implies it is not. Where we cannot establish something, the field is left explicitly empty rather than filled with a plausible value, and an empty field means "we do not know" rather than "no" or "none".
What a check cannot tell you
- Not that the business is good, competent or well run.
- Not that it is safe, solvent, insured or licensed.
- Not that it will still be trading tomorrow, or today.
- Not that it will answer you, or answer you quickly.
- Not that any claim the business makes about itself is accurate.
- Not that it is not a fraud. The procedure is not a fraud screen and is not designed as one. Anyone using this register that way is using it for something it cannot do.
What it tells you is what it says: on a stated date, a named person found it, and it was there.
How the procedure is versioned
This describes version 1 of the method. Every change is recorded at the method changelog with what changed, why, what it invalidated, and which entries had to be re-checked as a result.
Published versions are never edited in place. That is what makes an old entry readable — a record produced under version 1 records that fact, so you can read it against the procedure that actually made it rather than against whatever the procedure says today. The bar it was admitted under is versioned the same way, and the entry bar this feeds describes version 1 of that document.
In Plain English
A check answers one question: on this date, was this business reachable and recognisably what we described?
- One step is automated — does the destination respond without redirecting somewhere unrelated. That is all. A site can be up and abandoned and still pass it.
- Everything else is read by a named person, because deciding whether a change is material is a judgement.
- Four outcomes, not two: alive, changed, unreachable, gone. Closure needs two failures at least fourteen days apart plus a human confirmation.
- The cadence must differ by entry type. This procedure sets no interval because it supplies no dated check history from which to justify one. A conforming field dictionary must state any interval it actually enforces.
- Dates are bound to log rows. A build cannot generate one, and without a matching row the build fails.
- The method is weak on seasonal businesses, platform-only sellers, sites behind logins and shops with changeable hours. We would rather say so.
A passing check is not a rating, a recommendation, or a statement that anything is safe. It is a record that someone looked, and when.
See the versioned method → /method/