The CMS Isn't the Problem. The Boundary Is

For content negotiation to behave correctly, every caching layer needs to distinguish the representations. WordPress sites may have a page cache, a hosting cache, a reverse proxy, and a CDN. The response can say Vary: Accept, but that header doesn’t guarantee every intermediary will incorporate the header into its cache key.

Get this wrong and an ordinary visitor could receive Markdown where HTML was expected—or an agent could get cached HTML despite explicitly requesting Markdown.

Header-based Markdown is disabled by default in LLM Markdown. Enable it only if you can verify that every relevant cache honors the variation. Explicit .md URLs are more predictable because HTML and Markdown have distinct cacheable URLs.

It’s also worth noting that a raw Markdown response doesn’t run browser-side analytics scripts. That’s expected, but operationally relevant for anyone comparing agent traffic with conventional website analytics.

These details are part of the feature, not edge cases to hand-wave away. The hard part of exposing an alternate representation is often everything surrounding the conversion itself.

I’m wary of the rush to rebrand every technical decision as an AI optimization strategy.

Will publishing Markdown help an agent ingest your content? For an agent that requests or discovers the endpoint, quite possibly. Will it guarantee more citations in AI-generated answers, better rankings, or preferential treatment from a model provider? No. There’s no credible basis for promising any of that.

LLM Markdown advertises eligible Markdown endpoints using HTML alternate links and HTTP Link headers. Those make the alternate representation discoverable to clients that understand them. They do not force a crawler to retrieve the document, let alone use it.

That’s fine. Not every useful technology needs to be sold as a growth hack.

I can make a narrower promise and actually test it: request an eligible .md URL, and WordPress returns a structured Markdown representation of the published page.

This is the second WordPress plugin I’ve released publicly, and it has reinforced my preference for small software that solves a narrow problem.

Too many plugins now manage to do simultaneously too much and too little. You need one feature; you inherit a control panel, an external account, overlapping libraries, and a steady stream of Pro upsells. Sometimes the software starts working against WordPress rather than with it.

I wanted a different experience: install the plugin, choose the content types, adjust a selector if the theme requires it, verify the output, and move on. Sorted.

That doesn’t mean shipping an unfinished proof of concept. Real users asked for tables, optional images, and HTTP negotiation. Those requests made the plugin better. Version 1.1 added in-editor Markdown previews, per-post opt-outs, extraction diagnostics, more noindex integrations, and HTTP-header discovery. Each change improved the same core responsibility.

For a full feature walkthrough, setup instructions, and the 1.1 release details, see LLM Markdown 1.1: What’s New and How It Works.

I expect the way websites present information to change considerably as more software consumes the web on our behalf. We may eventually think of the website less as a fixed set of page designs and more as curated information that can be rendered differently for different requests.

Maybe that takes a decade. Maybe parts of it happen much sooner. It’s a larger conversation than this plugin.

The practical question today is simpler: when a new consumer needs our existing content in a different form, do we need to rebuild the publishing system—or can we adapt what it already produces?

For a lot of WordPress content, I think the answer is sitting in the rendered page.

LLM Markdown is available free on WordPress.org. If Markdown endpoints are the thing you need, I’d like the plugin to be the thing you install, configure once, and forget about.