Response headers

The _headers file, why it exists, and where it has to live.

Reed writes a _headers file into every build:

1
  Content-Type: text/markdown; charset=utf-8
2

3
/llms.txt
4
  Content-Type: text/plain; charset=utf-8
5

6
/*/llms.txt
7
  Content-Type: text/plain; charset=utf-8

Why it exists

Static hosts guess content types from file extensions, and most guess wrong for .md — commonly application/octet-stream, which makes a browser download the file rather than render it. The markdown mirrors and llms.txt are the machine-readable half of your documentation; served as a binary download they are close to useless.

It belongs at the root of the served tree

Cloudflare Pages and Netlify read _headers from the top of the served directory, and its rules match served URL paths.

If your site is mounted under a path, this creates a split that is easy to get wrong:

1
served-root/
2
  docs/           ← the contents of dist/
3
    index.html
4
    llms.txt
5
  _headers        ← stays HERE, not inside docs/

The /*/llms.txt rule in the emitted file is what covers the mounted case — it matches llms.txt one directory down, which is where a based site’s copy actually lives.

Hosts that do not read it

_headers is a Cloudflare Pages and Netlify convention. Other hosts need the equivalent expressed their own way:

nginx — a types block or location with add_header
S3 + CloudFront — Content-Type metadata set per object at upload
Vercel — a headers entry in vercel.json

Reed emits the file it can emit. Translating it is your host’s business, and skipping the translation costs you the markdown surfaces rather than the site.

Verifying

Check the served content type rather than the file’s presence:

1
curl -s -o /dev/null -w "%{content_type}\n" https://docs.example.com/llms.txt

Expect text/plain. Getting application/octet-stream means the rules are not being applied — most often because _headers ended up inside the mount directory instead of at the root.