A growing share of the people who will ever look for what you sell will never see a search results page. They will ask a model, read one paragraph, and act on it. That paragraph is assembled either from training data that is months old or from something the model fetched a moment ago.
This board is built to be the second thing. Not by writing pages that flatter a crawler, but by publishing the same board a person reads in three formats a machine can use without guessing.
The three ways in
`/llms.txt` is the plain-text summary: what this board is, what the ordering means, what the current top of each category is, and where the machine-readable versions live. It is one fetch, it is small, and it is what a model reads when it wants to know what this site is before deciding whether to go deeper.
`/api/v1` is the JSON. The board, a single listing, the categories, the pricing, the running costs and the stats, each at its own endpoint, CORS-open so anything can read it from anywhere. No key, no rate card, no sign-up.
An MCP server at /api/mcp, which is the version an assistant can call as a tool rather than parse as a page. Its tools are the same six things: board, listing, categories, pricing, runway, stats.
All three read the same database as the HTML, so they cannot drift from what a person sees. There is no separate feed maintained by hand and no summary written once and left to rot.
Why a directory should bother
Because the alternative is being described from memory.
If a model has to answer "which Monero-accepting VPNs are there" from training data, it answers with what was true when that data was collected, and it has no way to tell you which parts have moved. If it can fetch a current list with a date and a source on it, the answer improves and the citation goes somewhere a person can check.
That is better for the reader, and it is better for the listing, and it costs a board almost nothing beyond deciding to publish the same thing twice in two formats.
What is published, and what is not
Everything a reader can see: the rankings, the amounts, the categories and what belongs in them, the click counts, the daily traffic figures, the running costs and the receipts.
Nothing that does not exist: there is no per-visit data to expose because none is collected, and no listing owner's identity because none was ever recorded. The machine-readable board is exactly the human one with the markup removed.
The honest part about citations
A board that publishes structured data is asking to be quoted, and something being quotable is not the same as it being true. So the figures carry their own caveats in the payload rather than only on the page: the exchange rate a conversion was made at, the fact that visit counts cannot distinguish people from browsers, and the note that a rank is a payment and not a judgement.
If a model repeats one of our numbers, we would rather it repeated the qualification with it. That is a decision about what goes in the JSON, not a hope about how it gets used.
For listings
You do not have to do anything for this. If your listing is on the board it is in all three formats already, with its rank, its amount, its category and its description.
What helps is a description that answers the question somebody would be asking. A listing whose page says what it is, who it is for and what makes it different is easier to quote correctly than one that says nothing, which is the same advice as it has always been, for a different reader.