A 200 OK is not a health check: my llm.txt was base64 for months

This one is about my own site, which makes it slightly more embarrassing and considerably more useful.

llm.txt is the file you publish to tell AI crawlers who you are — the document ChatGPT, Claude, and Perplexity read when someone asks them about your company. My robots.txt explicitly invited those crawlers and pointed them at it.

For months, it served this:

IyBsbG0udHh0IOKAlCBEaWdpU2NhbGFiaWxpdHkKIyBEb21haW46IGRpZ2lzY2FsYWJpbGl0eS5j...

Base64. The whole file. Every crawler I invited got a wall of nonsense, and my sitemap.xml had the same problem.

How it happened

A PowerShell round-trip. Reading a file and writing it back through the wrong pipeline can re-encode the content — and because the result is still a valid file with a valid content type that returns 200 OK, nothing downstream complains.

It is a class of corruption I have hit before in another repo with emoji getting double-encoded the same way. The lesson I had written down was "don't round-trip non-ASCII files through PowerShell." The lesson I had not written down was "...and check the output afterwards."

Why no monitor caught it

Every check I had was green, and each one was reasonable in isolation:

• The file exists — true
• The URL returns 200 — true
• The content type is text/plain — true
• The response is non-empty — true
• The deploy succeeded — true

Not one of those checks asks the only question that matters: is the content the content? Availability monitoring answers "is it there," and I had quietly assumed that also answered "is it right."

What I do now

For any file whose entire purpose is to be read by something that isn't a browser, assert on the first bytes of the content, not the status code:

# llm.txt must start with its own header
curl -s https://digiscalability.com/llm.txt | head -c 10 | grep -q '^# llm.txt' \
  || echo "FAIL: llm.txt is not plain text"

# sitemap must be XML, not something that merely returns 200
curl -s https://digiscalability.com/sitemap.xml | head -c 5 | grep -q '^<?xml' \
  || echo "FAIL: sitemap is not XML"

Two lines. They would have caught this the day it happened.

The same principle scales up: a health check that only proves a process is listening will happily stay green through an empty database, an expired credential, or a config that points at the wrong environment. A health check should assert something only a healthy system could produce.

The wider point

The files nobody looks at are exactly the files that rot, because there is no human in the loop to notice. Your robots.txt, sitemap.xml, llm.txt, OG images, RSS feed, and .well-known endpoints are all read by machines that will never file a bug report.

If a file's audience is a robot, your only feedback loop is the one you build yourself.

Fixed in commit 15038dd on the DigiScalability site.