Feature Request: WebFetch should follow `<link rel="alternate" type="text/markdown">` and send `Accept: text/markdown`
Problem
When WebFetch retrieves a page that provides an agent-friendly markdown version via <link rel="alternate" type="text/markdown">, it ignores the tag entirely and summarizes the HTML through a small model. The result is a lossy summary instead of the clean, structured markdown the site author intended agents to consume.
This matters because the ecosystem is converging on standard mechanisms for agent-friendly content:
<link rel="alternate" type="text/markdown" href="...">in HTML (used by WordPress.org, Jekyll, Eleventy, Astro sites)Accept: text/markdowncontent negotiation (supported by Cloudflare "Markdown for Agents", Vercel, Mintlify)
Neither is consumed by WebFetch today.
Proposed solution
- Send
Accept: text/markdownheader on WebFetch requests. If the server returnsContent-Type: text/markdown, use that response directly — no summarization needed. - If HTML is returned, check for
<link rel="alternate" type="text/markdown">in the<head>. If present, follow it and return the markdown content instead of summarizing the HTML.
This would be a small change with high impact for any site that's already invested in being agent-friendly.
Example
https://blog.ivanovishado.dev/en/whats-in-my-claude-md/ includes:
<link rel="alternate" type="text/markdown" href="/en/whats-in-my-claude-md.md">
The .md endpoint returns full frontmatter + markdown body with Content-Type: text/markdown. But WebFetch returns a lossy summary of the HTML instead.
Related issues
- #5945 — proposed fetching
/llms.txtat domain root (different mechanism, same goal) - #2476 — llm.txt & prompt.txt support
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗