Skip to content
Docs menu

Content type

Content-type text/plain or text/markdown

In short: Serve /llms.txt as text/markdown or text/plain with charset=utf-8, never as an HTML page from a catch-all route.

  • Category: Retrievability & Access · weight 10 of 100 within the category
  • Retrievability & Access is worth 15 in every profile (points of 100, by scoring profile)
  • Audit ID R3 (as shown on reports) · rubric v2.1

What it checks

Whether the file is served as text/plain or text/markdown.

Why it matters

Clients decide how to parse a response from its content type. A file served as text/html is treated as a web page, and many clients reject it or strip it badly.

When it applies

Always, for any llms.txt that exists and isn’t served as HTML.

An audit that doesn't apply, or that we couldn't verify, is removed from your score and its weight shared among the Retrievability & Access audits that do apply. It is never scored as a zero.

How it's scored

1.0 for every file that reaches scoring. A response served as text/html, or whose body is an HTML page, never gets here: the scan reports that a web page answered instead of an llms.txt, and nothing is scored.

How to fix

  1. Set Content-Type: text/markdown; charset=utf-8 (or text/plain; charset=utf-8) for /llms.txt.
  2. On static hosts, map the .txt extension explicitly if the default is octet-stream.
  3. Make sure a framework catch-all route isn’t wrapping the file in an HTML page.

Frequently asked questions

Should llms.txt be served as text/plain or text/markdown?
Either earns full marks. text/markdown is the registered markdown type (RFC 7763), and it makes charset required, so send text/markdown; charset=utf-8; text/plain; charset=utf-8 is what most servers send for .txt by default and is just as good.

Sources: RFC 7763: The text/markdown Media Type · MDN: Common media types

What happens if my server sends llms.txt as text/html, even though the body is markdown?
Clients choose how to process a response from its Content-Type, so we do the same: a text/html response is treated as a web page, not a file. The scan reports that a web page answered instead and nothing is scored, however clean the markdown inside is. This usually comes from a framework route or CMS page rendering the path; serve the raw file with a text type instead.

Sources: RFC 9110 §8.3: Content-Type · Content type

Is application/octet-stream a problem?
The rubric scores it 0.5, because it tells clients the bytes are an unknown binary and browsers download it rather than show it. Today this audit isn’t measured precisely and any non-HTML type scores the same, but fix it anyway: on nginx, location = /llms.txt { default_type text/plain; } (or a types mapping), and on other hosts add an explicit header for the path.

Sources: MDN: Common media types · nginx: default_type and types

How do I set the content type for llms.txt on Vercel?
A static public/llms.txt is served as a text file already. To be explicit, add a headers entry in vercel.json with "source": "/llms.txt" and a Content-Type of text/markdown; charset=utf-8 (or text/plain; charset=utf-8), and check with curl -I https://your-domain/llms.txt that no catch-all route is answering instead.

Sources: Vercel: vercel.json headers

In your research, how many sites serve llms.txt with the right content type?
All 156 tracked sites score 1.0, but this audit is not yet measured precisely, so that is not a finding about headers. Files served as HTML never reach scoring: they are reported as a web page answering instead of an llms.txt.

Sources: LLMSRank method · Content type