By the iSuggest.ai Team · Updated for 2026
When you publish a page to an AI directory on iSuggest.ai, you get a URL like /ai-directory/claude/{id}. Most people look at the HTML version, because that's what a browser shows. But that same snapshot is also served at /ai-directory/{provider}/{id}.json and /ai-directory/{provider}/{id}.md, and those two formats exist for a specific audience: agents and crawlers that don't want to parse a rendered page to find out what's on it. If you've never opened the JSON version of your own snapshot, it's worth five minutes, because it shows you exactly what a bot sees instead of guessing.
Three formats, one canonical snapshot
A published snapshot isn't three separate things kept in sync — it's one immutable record rendered three ways from the same underlying data. The HTML is for people and for crawlers that render pages the way a browser would. The Markdown, with YAML front matter up top (source URL, capture time, snapshot hash, immutable: true, author and dates), is for models that read a page as a document rather than a DOM. The JSON is for anything that wants the structure without reading prose at all: provenance, the frozen page content, and the audit measurements, kept as three separate fields rather than mashed together.
What's actually inside the JSON
The payload has three top-level keys: snapshot, knowledge, and audit.
snapshot is provenance — which provider directory this was published to, when it was published, and a hash of the frozen content. Every submission has a deterministic id derived from the provider and the source report, so re-submitting the same page to the same directory returns the existing snapshot rather than creating a duplicate. The write itself is create-only: once a snapshot exists, it is never edited or overwritten, only ever re-served. If you republish, you get a new audit on a new report, not a mutated old one.
knowledge is the frozen page capture: a heading outline, per-section text, the page's structured data entities, links with their anchor text, images with alt text, and tables represented as rows rather than raw markup. This is the part that makes the Markdown and JSON formats genuinely useful to a model — it's already broken into the pieces an agent would otherwise have to extract itself.
audit is the SEO/GEO measurement taken at the same moment the capture ran, so the numbers and the content never drift apart the way they could if one were fetched now and the other fetched earlier.
Why publishing triggers a deeper fetch than an ordinary audit
An ordinary audit and a publish don't call the same thing behind the scenes. Running a regular audit only needs SEO signals, so it stays lightweight. Publishing to a directory triggers a second, deeper fetch of the page — the same audit, plus the full-text capture, heading outline, structured data, and link/image inventory that ends up in knowledge. Because both the measurements and the content capture come from that one deeper fetch, a snapshot never mixes an audit taken at one moment with content captured at a different one. That capture is also never written back into your ordinary report; it lives only inside the snapshot, so pages you never publish don't pay for work nobody asked for.
If that deeper fetch fails for some reason, publishing doesn't block — the audit already on file goes out as-is, and both the JSON and Markdown formats say plainly that no capture is present rather than silently omitting it or faking one.
Why this is worth checking on your own snapshot
Two practical reasons to actually open your own .json URL instead of assuming it looks a certain way. First, it's the fastest way to confirm a publish actually captured what you expected — if a page's important content sits behind client-side rendering or an interaction, the knowledge section will tell you honestly whether that content made it into the frozen copy. Second, it's a sanity check on your own structured data: the entities listed there are what a machine consuming your snapshot will actually work with, which is a different (and more concrete) question than whether your score mentions structured data at all.
Because a snapshot is immutable, this isn't something you can quietly go back and patch. If an early capture is thin, the fix is a fresh audit on an improved page, published again as its own new snapshot — not an edit to the old one.
Where this fits with everything else on the page
None of this replaces the actual directory listing or the reasoning behind why publishing to an AI directory matters in the first place — it's the layer underneath it. If you're already comfortable with what structured data does for AI visibility generally, our piece on structured data for AI search engines covers that ground. This post is narrower on purpose: it's about what your own published snapshot contains, in the format an agent would actually consume, so you're not guessing.
If you haven't published anything yet, see how the audit-to-publish flow works before you start — the JSON only gets interesting once there's a real snapshot behind it.