Can AI Read Your Crypto Site? We Scanned 100

In September 2026 we scanned 100 crypto websites, and they show dates to people more than any industry we have measured while hiding them from machines more than any industry we have measured.

The sample covers exchanges, custody, wallets, stablecoin issuers, layer ones and layer twos, node and API infrastructure, DeFi protocols, NFT marketplaces, and the analytics firms that watch all of it. We picked the names by hand, so this is a convenience sample rather than a random one, and no project here is named as failing anything.

Each domain went through three passes. Our free scanner ran 22 checks on whether a machine can fetch and parse the site. A second pass read each sitemap. A third pulled one real article out of the sitemap and looked for a date on it.

One domain scored 100, the only perfect score anywhere in this series. The median was 66.

The widest date gap we have measured

We found and fetched a real article on 36 of the 100 sites. Of those, 89% printed a date a reader could see, the highest share in the series. Only 47% carried one a parser could read. Forty-four percent showed the human a date and handed the machine nothing at all.

This is an industry where a post from 2021 describes a different world, and where readers check the date before they read the first line. The date is nearly always on the page for exactly that reason. It is written as ordinary text, which a parser cannot distinguish from any other sentence, so a model reading a protocol explainer often cannot tell whether it describes the current version or one three forks ago.

Wrap the date you already print in <time datetime="2026-09-07"> and make the datePublished and dateModified in your structured data match what the page says. It is one change to one template.

A third of these sites are blank until the browser fills them in

Thirty-four of the 98 sites we could measure returned a homepage with nothing on it. Open the same URL in a browser and it looks fine, because the content arrives a moment later once your browser runs the site's code. Most AI crawlers never run that code, so the empty version is what they keep.

That rate is second only to online retail, and the cause is the same: a heavy single-page app that assembles itself in the visitor's browser. It is a common way to build a protocol front end and a bad way to be read. The pages worth fixing first are docs, the explainers, and anything answering "what is this and how does it work", because those are the pages a model reaches for.

Almost none of them can tell an engine who they are

Ninety-eight of the 98 measurable sites are missing pieces of the structured block that states an organization's contact details, address, and links to its verified profiles. That is the worst rate in the series, and it is not close.

Some of that is deliberate. A decentralized protocol with no company behind it has no address to publish, and pretending otherwise would be worse than the omission. But most of this sample is not that. Exchanges, custodians, and analytics firms are ordinary registered businesses with offices and support lines, and they are leaving out the one machine-readable statement of who they are. For an industry that spends heavily on being seen as legitimate, it is a strange thing to skip, and it costs nothing to add.

Seventy-one percent are also missing at least one of an about, contact, or privacy page at a predictable URL. Those are among the first things an engine checks when deciding whether a site belongs to a real organization.

Seventeen refuse the AI crawlers

Seventeen of the 98 turned away a request carrying an AI crawler's name, and the reasons split three ways.

The eight in the middle row are mostly large exchanges, and their bot protection is doing what an exchange needs it to do. A plain request with an ordinary Chrome user-agent was challenged the same way, and we confirmed that by hand from a second network. They may still allow verified crawlers by IP range in ways nobody outside can test.

The eight in the top row are the ones worth acting on: a browser gets the page, an AI crawler gets a 403, and nothing in robots.txt documents the decision. That is the signature of a rule set in a security console rather than a choice anyone weighed.

Where our checks are opinions rather than standards

Two of our results look catastrophic and are not. Ninety-six percent do not link an llms.txt file and 84% do not serve markdown to clients that ask for it. Both are Growthr bets on where agent tooling is going, and we have written before that no major AI engine has published a ranking benefit for llms.txt. Reading those as an industry failure would be dishonest.

The checks that matter are the ones with evidence behind them: whether the crawler gets a page, whether that page has anything on it, whether it carries structure and a date, and whether other sites say the same things about you.

What we would fix first

1. Mark up the dates you already show. The biggest gap in this industry and the cheapest to close. A time element and matching structured data, on the template.
2. Send finished pages for docs and explainers. If your app has to be a single-page app, your documentation does not.
3. Say who you are. If there is a company, publish its contact details, address, and verified profiles in structured data. If there genuinely is not one, that is a fair reason to leave it out.
4. Ask your CDN what it is turning away. Filter your edge logs for the GPTBot, ClaudeBot, PerplexityBot, and Google-Extended user-agents and look at the status codes you returned.
5. Publish sitemap dates. Thirty-nine percent do. Your build already knows when each page changed.

None of this decides whether a model recommends you, which is governed mostly by what other sites say about you. It decides whether you are eligible to be read at all.

Method and limits

We scanned in September 2026. The 100 domains were chosen by hand, so the sample is not random and the numbers describe these projects rather than the industry. Each domain got a 22-check scan, a sitemap read, and one article pulled from that sitemap. The scanner ran 22 checks at the time of this scan; a 23rd, covering sitemap dates, was added afterwards, so a score you run today will not match one quoted here. An article was found for 36 of the 100, so every date percentage is out of 36 rather than 100. Two domains rate-limited the scan and are excluded from the scores, leaving 98. Every block was re-tested by hand from a second network before we described it. Seven of these domains also appear in our fintech sample, because they are both, so the two studies are not independent samples.

The sample is named below; the results are not attributed to it. Every domain we scanned is listed, so anyone can reproduce this, but no project is identified as passing or failing any individual check. The point of the exercise is the pattern, and a per-company scoreboard would be a pile-on rather than research.

Frequently asked questions

© 2026 Growthr. All rights reserved. · llms.txt · About · Privacy · Terms