Feature Request: WebFetch should follow `<link rel="alternate" type="text/markdown">` and send `Accept: text/markdown`

Resolved 💬 3 comments Opened Mar 30, 2026 by ivanovishado Closed May 3, 2026

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/markdown content negotiation (supported by Cloudflare "Markdown for Agents", Vercel, Mintlify)

Neither is consumed by WebFetch today.

Proposed solution

  1. Send Accept: text/markdown header on WebFetch requests. If the server returns Content-Type: text/markdown, use that response directly — no summarization needed.
  2. 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.txt at domain root (different mechanism, same goal)
  • #2476 — llm.txt & prompt.txt support

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗