Test HTML and Markdown delivery through your cache
HTML and Markdown can be correct at the origin while the CDN serves the wrong representation. Test the normal delivery path in both request orders, then repeat after a source update.
Add these checks to your llms.txt monitoring when publishing multiple representations of a page.
Reproduce the failure as a sequence of requests
A representation mix-up often looks intermittent because the first request changes what the cache holds. In a fictional setup, the same address can serve HTML or Markdown according to a request header. A browser request fills the cache with HTML. A later Markdown request receives that cached HTML instead of the intended representation.
Testing each format once in isolation may miss the sequence that causes the defect. Write down the URL, the selecting header and the response received, then reverse the order. The test is about what one request leaves for the next.
| Sequence to test | What to compare |
|---|---|
| HTML followed by Markdown | Whether the second response has the requested representation |
| Markdown followed by HTML | Whether a browser receives Markdown unexpectedly |
| Repeated request for one format | Whether content and relevant metadata stay coherent |
| Request after a content update | Whether the served revision is the intended one |
This matrix applies to a negotiated representation setup. If the site uses distinct explicit URLs, test those URLs and their routing instead of adding negotiation assumptions that do not describe the system.
Read Vary as part of the cache contract
The RFC 9111 rules for the Vary response header explain how request-header values affect reuse of stored responses. When representation selection depends on a header, the cache needs to account for the appropriate variation. The exact configuration still has to be checked in the implementation.
Do not treat the presence of Vary as proof that every intermediary behaves as intended. Record the request and response headers from the failing sequence and compare them with the site's delivery design. The source response, an edge response and the browser's stored response can involve different stages.
Likewise, a correct content type does not prove semantic freshness. A response labelled Markdown can contain yesterday's restriction or a link to an older release. Delivery checks establish which representation arrived; content checks establish what it says.
Keep cache repair separate from content repair
If changing the request order changes the returned format, investigate cache selection and routing. Editing the Markdown generator may leave that problem untouched. If the format is correct but the content omits a prerequisite, investigate the transformation or its source.
Preserve the small request sequence that demonstrated the problem. Use it again after the correction, including both request orders. A cache purge may temporarily hide a faulty variation rule; the second request is what shows whether the underlying selection now works.
For a release check, include a recognisable content change rather than relying solely on a timestamp. An updated prerequisite or corrected link can show which revision was served. The observation remains tied to the tested URLs and conditions, so report those alongside the result.
Choose an explicit delivery contract
There are two designs worth distinguishing. Separate URLs give HTML and Markdown different addresses. Content negotiation serves different representations from the same address according to a request header.
The llms.txt proposal describes Markdown URLs and discovery links. It does not require every site to implement header-based negotiation. Prefer the design your publishing system can maintain reliably.
For separate URLs, verify that each one returns the expected content type and body. For negotiation, document precisely which header selects the representation. An undocumented convention makes a successful test hard to reproduce.
Keep validators specific to the content
An entity tag or modification date is useful only when its meaning is clear. Record which revision it identifies and whether that revision belongs to the HTML, the Markdown or a shared source document.
When the page changes, check the path a client normally uses. A direct request that bypasses a cache is diagnostic evidence, but it cannot certify the ordinary delivery path.
The same caution applies to a 304 response: it participates in a validation exchange. Your report should retain the request that produced it and the cached representation to which it applies, rather than treating the status as a standalone content check.