Every listing site says it is independent at the start. The sentence costs nothing to write, nobody can check it, and the sites that later stopped being independent all had it on their about page the whole time.
For the broader context behind this business guide, read How The Stumble Picks What You See.
So this post does not argue that we are unusually principled. It describes where in the build a paid placement would have to be inserted, what currently sits in each of those places, and what somebody would have to change to get one through. Then you can decide how much that is worth.
What this is, and who it is for
For the reader who has been burned by a bought list and would like something more solid than an assurance. For the operator wondering whether there is a rate card they have not been shown. For anyone building something similar who wants the structural version rather than the values statement.
A scope note first: this is the binding design rule, not a track-record claim. The register publishes the schema and policy, while this article explains why paid-placement fields are prohibited in any conforming implementation.
Why a promise is worth nothing here
Paid placement is legal. It is a normal way to fund a publication, it is very often disclosed properly, and a good deal of genuinely useful writing exists because somebody paid for a slot in it. This is not a post about paid placement being shameful. Several of the models in the five models we could have used can be run cleanly and are.
The problem is narrower. A promise not to sell placement is a sentence, and a sentence has no defenders. It survives exactly as long as the person who wrote it is still around, still solvent, and still in charge. Sites do not usually break that promise dramatically. They get sold, or they get quiet, or the person who wrote the sentence leaves and the person who replaces them has a revenue target and no memory of why the sentence was there.
What is worth something is when the thing being promised has nowhere to live in the software. Then breaking the promise is not a decision somebody makes in a meeting. It is a change somebody has to build, and a change that has to be built is a change that leaves marks.
The schema: there is no field to sell
A register entry is a record with a fixed set of fields. What a business is, where it is, who reviewed it, when it was last checked, which method version produced that check, and what state the entry is in.
There is no field for a rating. No field for a rank, a score, a tier, a position, a weight, a boost, a sponsorship, a partner status or a placement. This is not a field left empty. There is no field.
That matters because a paid placement has to be represented somewhere. Money buys an ordering, and an ordering has to be stored. To sell placement in this register, somebody would first have to invent somewhere to put it.
The build check that rejects one
The schema alone would not be enough, because a schema is a file and files get edited. So the build refuses a set of field names outright. Adding a rating, a rank, a tier, a featured flag or a sponsored flag does not produce a slightly worse site. It produces a site that does not publish.
The practical effect is on the quiet version of this going wrong, which is by far the most likely version. Nobody announces a rate card. Somebody adds a small flag, uses it on a handful of entries, sees that nothing breaks, and by the time anyone looks the flag is load-bearing. The build check is aimed squarely at that afternoon.
It is not aimed at a determined person with commit access, and it would be dishonest to imply otherwise. Anyone who can edit the schema can edit the check that guards it. What the check does is remove the possibility of this happening by accident or by drift, and turn the deliberate version into a specific commit somebody has to write on purpose.
The separation between revenue surfaces and the register
The site currently earns nothing. If that changes, the constraint is not that the money must be disclosed. The constraint is that money and the register may not touch.
- A sponsor may never be an entry in the register.
- An entry in the register may never become a sponsor.
- Nothing sold to operators has any effect on register consideration, and that rule sits inside our entry bar rather than only in a revenue policy, so it is applied at review rather than remembered.
- No affiliate link appears in any record, category page, tombstone or on the stumble, permanently.
- Publisher-owned properties must be clearly disclosed by published rule, with no exception available.
The separation is written as a pair rather than a single rule for a reason. "Sponsors are not listed" on its own leaves the more attractive route open, which is listing somebody first and selling to them second. Both directions have to be closed or neither is.
The full accounting, including every model the category runs on and which of them are in use, is at who pays for this site.
What we do when a listed business offers us money
We decline.
Not disclose, not decline-with-thanks-and-a-note-in-the-footer. Decline. There is no arrangement available to a business in the register, including sponsorship of anything, including a newsletter, including a thing that seems obviously harmless.
The reason is that the separation stops being a rule the moment there is one example to point at. An exception is not a small hole in the policy. It is the policy, restated as "we decide case by case", and case-by-case is what everybody says on the way to a rate card.
The same answer applies to the softer versions, which are the ones that actually turn up: an offer to sponsor a newsletter, an offer to pay for a faster review, an offer to swap a link, an offer of free product for a reviewer. All of these get declined, and the review of the entry proceeds exactly as it would have anyway, in either direction.
What would have to change for this to stop being true
Naming the failure modes in advance is the only part of this a reader can actually use. What we'd have to do to go bad does this for the whole site. For the rotation specifically:
| The change | Where you would see it |
|---|---|
| A commercial field enters the schema | A "featured", "sponsored", "promoted" or "partner" label appearing on any record or in the surface |
| A rating or tier is introduced | Stars, scores or badges anywhere, which also ends the in-or-out rule the register is built on |
| The draw stops being uniform | One entry turning up far more often than chance would explain |
| The publisher exclusion is dropped | Properties owned by this publisher appearing in the register or the rotation |
| The outbound link becomes a tracked redirect | An interstitial, a countdown, or a link that does not go where it says |
| The rules page and the software diverge | Any of the above happening while the rotation rules still describe the old behaviour |
The last row is the one that matters most. The rules page changing is legitimate. The rules page not changing while the behaviour does is the failure this whole arrangement exists to make visible.
How to check
None of this needs technical skill.
- Look at any record for a label that implies position, priority or partnership. There should be none.
- Look for a number, a star or a tier attached to a business. There should be none anywhere on the site.
- Hover an outbound link and read the address in the status bar. It should be the operator's own address, not ours.
- Read the rotation rules and check that what you are looking at matches it.
- Read what we refuse to publish, which is the permanent list rather than the current one.
If any of those checks fails, corrections is the place to say so, and a mismatch between a published rule and the site's behaviour is a factual error like any other.
In Plain English
What it means. There is no field in the record structure where a paid position could be stored, and the build refuses to publish if one is added. Selling placement would require building the capacity to sell placement first.
Who it helps. Readers deciding how much weight to put on a link, and operators who want to know there is no rate card they are being kept away from.
When to use it. When any listing site tells you it is independent, ask where the paid placement would be stored. It is a better question than asking whether they take money.
What to do next. Apply the same question to us, using the five checks above, and read who pays for this site for the commercial side of the same answer.
Common questions
Is this really impossible to circumvent?
No, and claiming so would be the kind of overstatement this post exists to avoid. Someone with access to the code can change the schema and the check that guards it. What the design does is make the change deliberate, visible in the output, and impossible to do by drift.
What if the site is sold to someone else?
Then the new owner can change all of it. Nothing here binds a future owner, and no publication can honestly claim otherwise. The tells in the table are what you would have to rely on, which is why they are published rather than kept internally.
Would you take money to remove a listing?
No. Removal through the removal route is free, immediate, requires no reason, and involves no attempt to keep you. Charging for removal turns a register into something a business has to buy its way out of.
Does refusing all of this just mean there is no business model?
Partly, yes. The register is small and slow because nothing is subsidising it, and pretending that tension is solved would be worse than admitting it.
Read who pays for this site
The mechanism above is only half the answer. The other half is where money would arrive from in the first place, and who pays for this site lists every route the category uses, what is in use here, and what would change on that page first if it ever stopped being none of them.