Does it make sense to use Cloudflare Markdown for AI Agents?

Yes, but primarily as delivery and retrieval optimization, not as a proven AI visibility hack.

• It helps some agents and retrieval pipelines access a cleaner and cheaper version of the content.
• It may reduce token and parsing overhead.
• But so far, we do not have solid evidence that it increases AI citations, mentions, or referral traffic on its own.

If you do not buy into the launch hype around it as a visibility lever, today’s data mostly supports that position.

1. What this feature actually does

According to the official documentation, this is not a new URL pattern or a new file like llms.txt (Cloudflare docs).

It is content negotiation:

• the agent sends Accept: text/markdown
• Cloudflare fetches the HTML version of the page
• it converts it to markdown at the edge
• it returns a markdown response with Content-Type: text/markdown

That is an important nuance. The feature does not solve discovery, but delivery. In other words, it does not help a bot find the page, but it helps it read the page in a cleaner form if it has already asked for it (Cloudflare blog).

2. What Cloudflare is clearly optimizing for

Cloudflare’s official framing is heavily centered on efficiency: token count, context window planning, less HTML noise, and easier parsing for agents (Cloudflare docs).

You can also see that in the fact that the markdown response includes x-markdown-tokens and that the documentation describes the feature mainly as a convenient way to deliver a cleaner document to agents (Cloudflare blog).

So the first realistic conclusion is:

• this feature clearly helps the Cloudflare + agent/client stack with more efficient data transfer and processing
• on its own, it still does not prove improved site visibility

3. Is anyone actually using it?

Here, the answer is more interesting than with llms.txt.

With llms.txt, most evidence so far points to very weak real-world usage in public crawl workflows. With Cloudflare markdown negotiation, we already have a signal that some systems are actually using it.

The best practical evidence today is Suganthan’s experiment (Suganthan):

• over 44 days, he recorded 1421 markdown requests
• the requests came from headless Chrome pools, Claude infrastructure, axios clients, and several markdown-specific tools

That means:

• this is not purely a marketing fantasy
• some retrieval pipelines are genuinely requesting the markdown version

That is a substantial difference compared with llms.txt, where the problem is often the lack of requests in the first place.

4. Does it mean better AI visibility?

This is where caution is needed.

Suganthan explicitly states that his data does not prove higher citation frequency in AI answers, higher referral traffic, or better visibility in ChatGPT, Claude, Perplexity, or Google AI results (Suganthan).

It only shows that someone is genuinely reading the markdown variant, but we do not know what downstream effects follow from that.

That is the key difference between consumption evidence and performance evidence. Today’s data is still much stronger for the first than for the second.

5. How to verify it on your own site

If you want to assess it without buying into launch hype, the most practical approach is a short validation workflow.

1. Verify that the endpoint actually returns Content-Type: text/markdown.
2. Check that the response also returns Vary: Accept and behaves as a variant of the same resource (Cloudflare docs).
3. Compare the HTML and markdown variants to ensure they remain semantically equivalent.
4. Log requests with Accept: text/markdown so you know whether anyone is actually requesting it.
5. Track which URLs and which clients read the markdown variant most often.
6. Only then evaluate whether citation footprint, referral signals, or any other assisted business value changes.

Without that kind of validation, it is easy to end up testing a feature that exists in configuration but produces no measurable change on your site in practice.

Personal experience: This is exactly where I hit a wall myself, because I simply do not have a site on Cloudflare. That is a good example of the limitation. From my server access logs, I know that so far no bot has tried to request Content-Type: text/markdown from me, so in practice I do not have much to report yet. I also discussed it with other people, and right now it simply is not worth building because the time required can be invested elsewhere, and more intelligently.

In the future, I will have a site where I can use this in a real way, but I am waiting for that deployment. Once that happens, I will add my own measured data here. I did not want to keep waiting with the article any longer.

6. Does it help the website or mostly Cloudflare?

The honest answer is: both, but asymmetrically.

Where it clearly helps Cloudflare and the agent stack

• smaller payload than full HTML
• lower token overhead
• less noise from navigation, JS, and boilerplate
• simpler ingest into retrieval or agentic workflows

This is the best-supported part of the story today, because it is exactly what both the official documentation and the launch messaging focus on (Cloudflare docs, Cloudflare blog).

Where it can help the website

• if the agent genuinely prefers clean markdown over poor HTML extraction
• if the site runs on heavy JS or a complex DOM
• if you need to make content easy to read for AI-assisted tooling
• if you are targeting docs, knowledge bases, or agentic product use cases

Where it remains unproven

• growth in citations
• growth in mentions
• growth in referral traffic
• better positions in AI search surfaces

This is exactly where the launch hype was strongest, and exactly where the evidence is weakest today.

7. When it can realistically help

It makes the most sense where the main problem is parsing friction, not a discovery deficit.

Typically:

• API and developer docs
• knowledge bases
• pages with heavy front-end layers
• sites that want to be usable in agentic workflows

In these cases, the credible [hypotéza] is this: if the agent already visits the page, the markdown version may improve ingest quality or reduce the retrieval system’s costs. But that still does not mean the agent will discover the page more often or cite it more often.

8. When it probably will not help much

A. The site already has clean HTML and a good SSR/ISR layer

If the page is fast, text-clean, well server-rendered, and does not hide critical content in JS, the markdown variant is often solving a relatively minor problem.

B. The site’s main problem is discoverability

If the site is not well indexed, internally linked, entity-legible, and citation-worthy at the content level, Markdown for Agents is only addressing a secondary stage.

C. The site expects direct traffic or a citation boost from the feature

That is the riskiest expectation today. We do not yet have evidence for that kind of effect.

9. Operational and methodological limits

It is worth being cautious here from a technical perspective as well.

The official documentation lists operational limits, for example conversion from HTML only and response size limits. The external experiment also shows that the feature may not work consistently across all stacks and can silently return HTML (Cloudflare docs, Suganthan).

That means that before evaluating anything, you need to verify:

• that you are actually returning text/markdown
• that the response quality is reasonable
• that the content remains semantically equivalent

Otherwise, you can easily end up measuring the effect of a feature that is not actually running.

10. Risk: a second representation of reality

Beyond the hype, there is a second issue here: trust.

As soon as a separate representation of a page exists for an agent, the question becomes:

• is it really just a cleaner form of the same content?
• or can it turn into a machine-only layer with a different meaning?

That matters because AI search is already highly sensitive to cloaking-like behavior, hidden instructions, and situations where machines and humans see different prices, claims, or facts. A critical perspective on this trust problem also surfaced in the SEO community immediately after launch (Search Engine Land).

In Cloudflare’s implementation, the basic story is still automatic HTML conversion, but as soon as people start optimizing around it deliberately, the pressure for divergence between the human and agent view increases.

From a governance perspective, the healthy rule is:

• use it as a format converter
• do not use it as a hidden second content layer

11. Is duplicate content or a penalty a risk?

The most likely answer is:

• duplicate content penalty on its own is probably not the issue
• cloaking or a trust problem potentially is, if the meaning starts to diverge

Why:

• Markdown for Agents typically does not create a new public URL, but a different representation of the same resource via content negotiation
• that is technically a different situation from the classic two URLs with the same content
• Cloudflare also returns Vary: Accept, so this is a variant of a single response, not a new standalone indexing endpoint (Cloudflare docs)

From a search engine perspective, the bigger issue is not duplicate content, but whether the markdown version remains equivalent to the HTML version. Google has long said that duplicate content is usually not a spam policy violation unless it is deceptive or manipulative (Google FAQ).

This is exactly where the risk of cloaking-like behavior appears. If the markdown variant changes facts, adds extra instructions, hides or rewrites important information, or shows a different commercial or editorial layer than the HTML version, then it is no longer a harmless format conversion, but a different document for the machine. Google explicitly treats showing crawlers different content from what users see as a problem (Google website testing).

The practical safe rule is:

• the same meaning
• the same facts
• the same primary content layer
• no bot-only additions that you would not want to show to a human visitor as well

If the markdown is truly just a cleaner serialization of the same content, duplicate risk is low. If it turns into an agent-only page without a new URL, the risk is not primarily duplicate content, but trustworthiness, similarity checks, and possible classification as cloaking. Similar warnings were also voiced by Google and Bing representatives in the debate about separate markdown versions for LLMs (Search Engine Land).

12. The most realistic verdict

Markdown for Agents is not meaningless based on today’s data. But it is not a proven visibility lever either.

The best current reading is:

• llms.txt = currently mostly an experimental mapping layer with weak adoption
• Markdown for Agents = a genuinely used retrieval utility on some agentic paths

From the website’s perspective, that means:

• as a low-friction technical improvement, it may make sense
• as a higher priority than indexability, quality HTML, content structure, and crawler governance, it does not make sense today

Practical recommendation

It makes sense to enable it if

• you are already on Cloudflare
• you have a docs-heavy or knowledge-heavy site
• you want to help agents with cleaner ingest
• the implementation cost is minimal

I would not expect from it on its own

• more citations
• more AI referrals
• better Google AI Overviews visibility
• better AI Mode performance

What to measure after enabling it

• requests with Accept: text/markdown
• which URLs request the markdown variant
• which clients or user agents are doing it
• whether the AI citation footprint of those URLs changes
• whether referral or assisted business value changes

Without that measurement, this is just another AEO [hypotéza].

FAQ