Making Edge Delivery AI-Readable (Without Rebuilding Everything)

April 2026

Why this matters now

AI agents are becoming real consumers of the web.

GPTBot, ClaudeBot, PerplexityBot, and internal enterprise pipelines are all crawling content. And they are doing it the same way search engines have for years: raw HTML, no JavaScript, no browser rendering.

That creates a problem.

Most modern sites assume a browser. They assume JavaScript will run. They assume content can be assembled at runtime. AI agents see none of that.

If it is not in the HTML response, it does not exist.

How agents actually find your content

There are two signals that matter.

The first is still structured data. JSON-LD in the head tells an agent what a page represents. That part has not changed.

The second is newer. Agents are starting to look for site-level indexes like llms.txt. These act as a simple, crawlable map of your content.

Those indexes are often exposed through links in the head:

rel=“alternate” type=“text/plain” title=“LLMs.txt” href=”/llms.txt”
rel=“alternate” type=“text/plain” title=“LLMs-Full.txt” href=”/llms-full.txt”

This is the entry point. If you do nothing else, make it easy to discover.

The constraint everything falls out of

AI agents do not execute JavaScript.

That one rule simplifies the architecture a lot. Anything you want an agent to understand has to be:

This is the same constraint SEO has always had. The difference is the depth of data now expected.

What EDS already gives you

One of the reasons this pattern works well with EDS is that most of the pieces already exist.

On the page side, JSON-LD is handled as content. You add it to metadata and it is rendered into the HTML at publish time. No extra work required.

On the site side, you already have a full content index. query-index.json is generated automatically and used for feeds and related content.

That means you are not starting from scratch. You already have both page-level meaning and site-level structure.

The only thing missing is how that structure is exposed.

The gap

query-index.json is useful, but it is not how most AI agents consume content.

They expect something simpler. Something predictable. Something they can crawl without needing to interpret an API.

That is where llms.txt fits.

The key shift is this:

You are not creating new data. You are reshaping what already exists.

Turning the index into something agents can read

This is where the CDN edge comes in.

EDS handles rendering. It is not responsible for transforming data into alternate formats.

A Cloudflare Worker sits in front of EDS and does that transformation on demand.

Here is the flow:

That is the entire system.

What the Worker actually does

At its core, the Worker is just mapping fields.

Here is a minimal implementation:

export default {
async fetch(request, env) {
const url = new URL(request.url);
if (url.pathname === "/llms.txt") {
  return handleLLMs(env, false);
}

if (url.pathname === "/llms-full.txt") {
  return handleLLMs(env, true);
}

return fetch(request);
}
};
async function handleLLMs(env, includeBody) {
const res = await fetch(${env.EDS_ORIGIN}/query-index.json);
const json = await res.json();
const lines = json.data.map(entry => {
let output = ${entry.title}\n${entry.path}\n${entry.description || ""};
if (includeBody && entry.body) {
  output += `\n${entry.body}`;
}

return output;
});
return new Response(lines.join(”\n\n”), {
headers: {
“content-type”: “text/plain”,
“cache-control”: “public, max-age=3600”
}
});
}

There is nothing complex here. That is the point.

You are not building a system. You are exposing one that already exists.

What you end up with

Once this is in place, your site exposes two useful entry points.

The first is a lightweight index with titles, URLs, and descriptions.

The second is a full index that includes the body content.

Both are:

And they require no additional data source.

Where JSON-LD fits into this

The Worker solves the site-level problem. JSON-LD solves the page-level problem.

In EDS, this stays simple. Add a metadata row in your document that includes your JSON Object

Metadata |
json-ld | “@context”:“https://schema.org”,”@type”:“BlogPosting”,“headline”:“AI-Readable Edge Delivery”}

EDS renders it into the HTML automatically.

That is all you need.

You can generate schema dynamically if you want, but in most cases that just adds complexity. Keeping it authored alongside the content is cleaner and easier to maintain.

Putting it together

There are really only three moving parts:

Each layer does one job.

That separation is what keeps the system simple.

Final thought

The interesting part here is not the Worker.

It is recognizing that you already have the data.

Most implementations over-engineer this. They build pipelines, duplicate indexes, or try to generate everything dynamically.

EDS already solved the hard part. The pattern is just about exposing it correctly.