By the iSuggest.ai Team · Updated for 2026
When you publish a page to an AI directory on iSuggest.ai, we don't hand crawlers a live pointer to your site and let them fetch whatever happens to be there that day. We take one measurement, freeze it, and serve that frozen copy forever after at a permanent URL. That's a deliberate design choice, not a limitation, and it's worth explaining why it's the right one for a system built to be cited.
What actually gets frozen
A snapshot is built from two things captured at the same moment: the audit already on file for that page, and a deeper one-time fetch that reads the page in full — readable text broken into sections, the heading outline, every structured-data entity, links with their anchor text, images with alt text, and tables as rows. Both come from a single fetch, so a snapshot never mixes a score measured on Monday with content that changed on Wednesday. The result is written once to data/llm-submissions/{provider}/{id}.json and served in three formats at the same canonical path — HTML for people and crawlers, JSON for agents that want the provenance and the measurements kept separate, and Markdown with YAML front matter for models reading the page as a document.
Why not just re-crawl your live page every time
The obvious alternative is to have /ai-directory/{provider}/{id} fetch your URL live on every request, the way a search engine cache sometimes does. We don't do that, for a few concrete reasons. First, consistency: a page an AI system decides to cite should say the same thing an hour from now as it does today, or the citation itself becomes unreliable. Second, a live re-fetch would re-introduce exactly the problem our own audit exists to catch — a page that renders fine in a browser but returns something different, or nothing useful, to a fetch that doesn't execute JavaScript the way your browser does. Freezing the page at a moment when we've already confirmed what a crawler actually receives removes that risk entirely. Third, permanence is the point: a directory built on the idea that "this is what we verified, on this date, and it hasn't moved" is a much stronger signal to hand a model than a link that might 404 or change meaning next quarter.
The deterministic ID that makes a snapshot permanent
Every submission's id is derived, not generated randomly: it's the first 20 hex characters of a SHA-256 hash of provider:report_id, prefixed l_. That means the same report published to the same directory always resolves to the same id, and the storage layer writes it with a create-only operation — if a file already exists at that path, the write is skipped and the existing snapshot is returned untouched. Submitting the same report to the same provider a second time is genuinely a no-op, not a refresh; it can't silently overwrite what's already citable. Each snapshot also carries its own snapshot_sha256, a hash of the exact frozen JSON, so anyone reading the machine formats can verify the content hasn't drifted from what was originally published.
Two engine calls, two different jobs
This ties into a distinction that's easy to miss: running an ordinary audit and publishing a snapshot don't call the same thing behind the scenes. An audit calls our engine's SEO-only endpoint, which is why ordinary reports stay small and can be re-run cheaply. Publishing calls a separate, deeper endpoint that performs the full-page capture described above. That capture is never written back into your report — it exists only inside the snapshot that requested it, so pages you audit but never publish don't pay the cost of a capture nobody asked for, and each provider's frozen copy comes from its own independent fetch rather than a shared cache.
What this means if you update your page
Because a snapshot is immutable by design, improving your page after publishing doesn't rewrite what's already out there under that id. If you fix an issue the audit flagged and want the AI directory to reflect it, you re-audit the page to get a new report, then publish that new report to the directory. Since the id is derived from the report id, a genuinely new audit produces a genuinely new snapshot rather than colliding with the old one — both remain reachable, which is honest: the old snapshot really was an accurate capture of your page at that time, and the new one is an accurate capture of it now. Nothing about this workflow silently discards history.
Why this matters before you submit
The practical takeaway is simple: get the page right before you publish, because publishing locks in what we found. Run the audit, work through anything it flags, confirm the score clears our publishing bar, and only then send it to Gemini, ChatGPT or Claude's directory. If you want the deeper mechanics of how a page earns a spot in the directory in the first place, our directory overview post and our walkthrough of structured data for AI search engines are the right next reads. Freezing isn't a corner we cut to save engineering time — it's what makes a directory of pages worth an AI system trusting in the first place.