Should You Serve a Markdown Version of Every Page?

Should you serve a markdown version of every page?

Only if machines are a primary audience for your content. Documentation sites have a strong case and most marketing sites do not. The pattern is real and spreading, but it solves a problem that only exists when agents read your pages as often as people do.

I went looking at this because I kept noticing a pattern while researching. Several vendor documentation sites now publish a plain text twin of every page, addressed by adding a file extension to the URL.

Here is what is actually being served, why it exists, and the honest answer about whether a business site should copy it.

What are vendors actually doing right now?

Serving a clean markdown copy at a predictable URL. Webflow's developer documentation states that a documentation index is available at the root level at llms.txt, that appending llms.txt to any URL gives a page level index, and that appending .md gives the markdown version of any page.

I checked rather than assuming. Requesting the markdown variant of Webflow's rate limits reference returns plain markdown with a short header block telling the reader that appending .md to any page URL gives clean markdown, pointing to the full documentation index, and naming an MCP server endpoint for AI client integration.

Google does something similar with its own search documentation. The guide on optimising for generative AI features is available as a plain text markdown file at its own URL, and that file is what I read rather than the rendered page.

Two large vendors, same instinct. The people who most understand how machines consume documentation have decided that machines deserve their own copy.

Why would a plain text copy of a page help at all?

Because rendered pages are full of things that are not the content. Navigation, cookie notices, related links, interactive components and scripts all arrive alongside the text. A markdown twin delivers the content without the furniture, in a format that is trivially easy to parse.

There is a size argument too. A documentation page might be a few hundred kilobytes of HTML and a few kilobytes of actual content. If an agent is reading dozens of pages to answer a question, the difference between those two numbers is the difference between a fast answer and an expensive one.

And there is a fidelity argument, which matters most. Headings stay headings, code stays code, tables stay tables. Anything that converts HTML to text loses structure somewhere, and structure is what makes a document usable rather than merely readable.

None of that changes how a human sees your site. The rendered page stays exactly as it was. This is an addition, not a redesign.

How does this relate to llms.txt?

They solve two halves of one problem. An llms.txt file is an index that tells an agent what exists and where. A markdown page variant is the content itself in a clean form. Webflow's documentation ships both, which is the pattern worth noticing.

An index without clean content sends an agent to pages it still has to fight through. Clean content without an index means an agent has to discover each page some other way. Together they make a site genuinely navigable by something that is not a browser.

If you are starting from nothing, the index is the cheaper first step and the one with an existing convention. I wrote about setting it up and, more importantly, auditing it in what to check in an llms.txt audit, and the basics are in what llms.txt actually is.

What does it cost to do this on Webflow?

More than it costs on a documentation platform. Documentation sites are usually built from markdown already, so serving the source is close to free. A Webflow site stores rich text in the CMS, so a markdown twin means converting content and serving it at a new URL, which is engineering work rather than a setting.

I am not going to tell you Webflow has a feature for this, because I have not verified one. If you are considering it, check the current Webflow documentation for what is supported today rather than trusting any article, including this one, about what the platform can do.

The honest framing is that this is a build. Budget it as one, and ask what it is worth before you start, because the answer for most marketing sites is not very much.

There is a cheaper middle path worth considering. Rather than a twin of every page, publish clean machine readable versions of the handful of pages that carry the facts people ask about: your pricing model, your integrations, your technical requirements. Those are the pages an assistant is most likely to be asked about, and the ones where a wrong answer costs you a deal.

What are the risks of publishing a second copy of every page?

Duplication and drift. You now have two representations of the same content, and the moment one is updated without the other, agents and people are reading different things. That failure is silent and it is exactly the kind that persists for months.

There is also an indexing question. Two URLs with the same content is the classic duplicate content situation, and it wants deliberate handling through canonical signals and crawl directives rather than hope. I would not ship this without deciding explicitly what search engines should do with the second copy.

The third risk is scope. Publishing a clean, complete, easily parsed copy of your content makes it easier for anyone to use, including people you would rather not. That is a reasonable trade for documentation and a real decision for anything proprietary.

Who should actually do this today?

Anyone whose product is used through documentation. If developers integrate with you, if your support content answers technical questions, or if your users routinely ask an assistant how to do something in your product, a clean machine readable copy is a direct investment in getting those answers right.

API providers are the clearest case, which is why the examples are where they are. When an agent is writing code against your platform, an incorrectly parsed parameter table becomes a bug in somebody's software, and that is a support cost you pay.

Knowledge heavy businesses come next. Legal, financial and compliance content where precision matters and where an approximation is worse than nothing.

For an ordinary marketing site, the case is weak. Your pages are short, your structure is simple, and a well built HTML page is already easy to read. The problem this pattern solves is not the problem you have.

What would I do instead for a marketing site?

Make the HTML itself cleanly parseable, which pays off for every reader rather than one class of them. Semantic headings, a direct answer under each heading, real text rather than text baked into images, and content that does not depend on scripts to appear.

That last point is the one that actually costs sites visibility today. Content assembled by JavaScript after load is a far bigger obstacle to machine readers than the absence of a markdown twin, and it is a problem plenty of sites have without knowing. I went through the specifics in how AI crawlers handle JavaScript rendered pages.

Fix that first. If your rendered HTML contains your content, in order, with sensible headings, you have captured most of the benefit this pattern offers, at a fraction of the cost.

What should you do next?

Open one of your most important pages, view the source, and check whether the main content is present as plain text in the HTML. If it is, you are in reasonable shape and a markdown twin is an optimisation you can postpone indefinitely.

If your content only appears after scripts run, that is the work. Fix the rendering before you think about serving a second format, because the second format solves a smaller problem than the one you already have.

And if you do run a documentation site, go and look at how Webflow and Google are doing this. Copying a working pattern from people with more traffic than you is the cheapest research available.