Martin Splitt opened a recent episode of Google's Search Off the Record podcast with a question he says he gets asked constantly: should a website be converted into Markdown so that large language models have an easier time reading it? He came in with an opinion already formed. By the end of the conversation with John Mueller, that opinion had survived, but it picked up a lot of nuance along the way that the headline coverage mostly skipped.[1]

The short version that spread across SEO news sites this week is accurate but flattened: Google says HTML is the standard, Markdown gives you nothing for SEO.[2] That is true. It is also not the most useful part of what was actually said. The interesting part is why, and where the exceptions genuinely sit.

The Argument Before the Argument

Splitt's opening case for Markdown was reasonable on its face. Markdown gives you headings, lists, tables, links, and images using a fraction of the syntax HTML requires. It is harder to get wrong, faster to write, and the structure is readable even with no rendering at all. None of that is in dispute.

His counterargument to his own idea is what made the episode worth listening to. Every crawler that exists today already had to solve the problem of reading HTML at the scale of the entire web. Asking the ecosystem to suddenly prioritise a parallel Markdown version is solving a problem that does not exist, because the harder problem was already solved years ago.

That second line from Mueller is doing more work than it looks like. Splitt, it turns out, writes his own personal site entirely in Markdown through a static site generator he built himself, specifically because he does not want to type angle brackets. Mueller used that admission to pivot the whole conversation: if the advice is "don't bother with Markdown," but the person giving the advice writes in Markdown daily, the real answer needs more precision than a flat no.

What Markdown Actually Is, and Why It Exists

Mueller looked into the history for the episode. Markdown was created in 2004 by John Gruber and Aaron Swartz, with the goal of producing something close to plain, readable English that converts cleanly into HTML and back again.[1] It assumes HTML already exists. It is not a competitor to HTML. It is a more pleasant way to author the same eventual output.

Splitt's framing of this point is the most useful technical summary in the whole episode: Markdown gives you semantic structure almost by accident. A heading is unmistakably a heading. A link is unmistakably a link. There is very little room to accidentally make something look like a heading without it actually being one, which is a mistake that happens constantly in hand-coded or poorly templated HTML.

Why "Less Text" Does Not Mean "Better for AI"

The instinct behind wanting a Markdown version for AI systems is straightforward: open a raw HTML file in a text editor with no browser rendering it, and it is genuinely hard to read. Tags everywhere, inline styles, navigation markup tangled in with the actual content. Open a Markdown file the same way and it is still legible. A link still reads as link text in square brackets followed by a URL in parentheses.

Splitt's point is that this readability difference is real but irrelevant, because no crawler is reading raw HTML the way a human squints at a text file. Converting HTML into plain text is a solved, trivial problem with mature tooling on every side of the industry. The supposed advantage of Markdown, being easier to extract text from, stopped mattering once HTML-to-text extraction became a commodity.

There is a second, quieter cost that the conversation kept circling back to. Markdown by design strips out everything around the content: headers, footers, sidebars, the navigation that tells a crawler how a page connects to the rest of a site. Mueller pointed out that for a search engine specifically, those structural links are not noise to be removed. They are how Discovery works. A clean Markdown excerpt of an article with the surrounding site architecture stripped away is, from a crawling standpoint, a worse signal than the messy HTML it came from.

The llms.txt Question, Settled Pretty Bluntly

Splitt asked the natural follow-up: if not a full Markdown site, what about an llms.txt file, a plain text summary file aimed specifically at language models? Mueller had spoken directly with one of the people behind the original llms.txt proposal, and his read on its intended purpose was clear.

The file was never designed as a discovery mechanism, a way to get found by AI systems that have not encountered the site yet. It was designed for a narrower case: an AI agent that already knows about a site and a user, and wants a structured way to look around once it is already there. Mueller's framing of why the discovery use case fails is the sharpest line in the episode.

That is the core problem with treating any self-authored file as an AI optimisation lever. A file you control, describing how great your own site is, is not a credibility signal to a system trying to figure out which site is actually the best answer to a query. It is closer to a sales pitch the system has every reason to discount.

Where the Exception Genuinely Lives

Neither of them dismissed Markdown outright, and this is the part most of the secondary coverage compressed into a footnote. Developer documentation is the one category where both agreed a Markdown version earns its keep, because the audience reading it is frequently a developer or a coding agent that already works in Markdown natively and benefits from getting the raw syntax directly.

Mueller's closing line on this was blunt enough to quote directly: if you are selling shoes, you are not going to have a Markdown version of your shoe catalogue. He attributed the temptation to a developer bias, the assumption that because developers personally find Markdown easier, every type of website must benefit from the same approach. Most websites are not run by developers alone, and most content is not documentation.

The Parallel-Versions Problem Nobody Budgets For

The strongest practical warning in the episode had nothing to do with crawlers and everything to do with maintenance. The moment a site runs two versions of its content, a public HTML version and a separate Markdown or JSON version aimed at automated systems, it has taken on a maintenance burden that compounds quietly.

• 1 If the human-facing page breaks, a user notices and tells you. If the automated-only version breaks, nobody does, and a crawler may keep indexing stale or broken content indefinitely without any signal reaching you.
• 2 Every content update now needs to happen in two places, or through a pipeline that keeps them in sync. That pipeline is itself a new point of failure that did not exist when there was only one version of the truth.
• 3 Both Splitt and Mueller drew a direct comparison to dynamic rendering, an earlier-generation workaround where sites served a different version of a page to crawlers than to users. It worked as a stopgap, then became a maintenance and debugging burden once sites depended on it long term. A parallel Markdown layer risks the same trajectory.
• 4 The cleanest answer to wanting both formats is generating one from the other through a single pipeline rather than maintaining two sources by hand, the same approach Splitt already uses for his own site with its static-site-generator setup.

What This Means If You Run a Website

If someone on your team has asked whether converting the site to Markdown, or standing up an llms.txt file, would help with AI visibility or search performance, the answer from the people who build Google's crawling and indexing systems is consistent and specific. Clean, well-structured HTML with proper headings, working internal links, and clear semantic markup remains the entire foundation. Nothing about the rise of AI search systems changes that foundation, because those systems are still built on the same HTML-parsing infrastructure search engines have used for decades.

Where the conversation actually has room to add value is for sites with substantial developer-facing content, where a genuine Markdown layer generated from the same source as the HTML can serve coding agents and human developers without creating a second source of truth. For everyone else, including most commercial sites doing generative engine optimisation work, the energy is better spent on the boring fundamentals: structured data, clean semantic HTML, and a site architecture a crawler can actually navigate.