Should I offer Markdown versions of my pages for AI?

Don't build a parallel set of Markdown pages expecting AI engines to prefer them. As of October 2026, no engine documents using them.

Google is the clearest on this. Its guide to generative AI features says you don't need new machine readable files, AI text files, markup or Markdown, because Google Search doesn't use them. Its AI features page adds that a page only needs to be indexed and eligible for a snippet to appear as a supporting link in AI Overviews or AI Mode, with "no additional technical requirements".

The idea behind Markdown versions is reasonable. Clean text is easier for a machine to read than a page buried in scripts. But the fix for that problem is your HTML, not a second copy of it. Many AI crawlers don't run JavaScript. If your pricing only appears after scripts run, those crawlers see a page without your pricing. A Markdown file doesn't change what they get from your real URL.

So the next move is to fix the page itself: render the important facts on the server and state them plainly.

Google's guide to optimizing for generative AI features, dated 10 July 2026, is direct. It says you don't need "new machine readable files, AI text files, markup, or Markdown to appear in Google Search (including its generative AI capabilities), as Google Search itself doesn't use them." It adds that doing so "will neither harm nor help your site's visibility or rankings in Google Search, as Google Search ignores them."

Two things follow from that wording:

• It's scoped to Google Search. The same paragraph says it's "completely fine" to create and maintain llms.txt or similar files for other services that use them. Google isn't speaking for ChatGPT, Claude or Perplexity.
• It's neutral, not negative. Google isn't telling you to delete files you already have. It's telling you they don't count.

The same guide rejects related shortcuts. It says you don't need to write in a special way for AI, and that there's no ideal page length. It also rejects the idea that you must chunk content for LLMs. The pattern is consistent: Google wants the normal page, crawlable and indexable, and nothing extra.

Outside Google, the evidence is an absence. OpenAI's crawler documentation describes three agents: GPTBot for training, OAI-SearchBot for ChatGPT search, and ChatGPT-User for user-triggered fetches. It describes robots.txt controls for each. It says nothing about reading Markdown copies or AI text files.

The same holds across the engines our evidence base checked. None of OpenAI, Anthropic, Perplexity, Microsoft or Meta documents parsing llms.txt. The llms.txt idea itself is a community proposal, not a standard any engine has adopted. Our guide to llms.txt and whether any engine reads it covers the file in detail, and the llms.txt glossary entry gives the short definition.

Absence of documentation isn't proof that every engine ignores these files. It does mean nobody has shown a benefit. The 2026 critical survey of 45 GEO studies (arXiv 2607.14035) contains no controlled test of llms.txt. If you can't point to a document or a study, you're paying maintenance cost for an unmeasured effect.

What engines do document is access: which bot reads which robots.txt rule, and whether your host lets that bot through. That's where to spend the effort.

Some Markdown is harmless or useful for reasons that have nothing to do with AI visibility.

Fine

• Developer docs. If your users want raw Markdown to copy into their own tools, offering it is a product decision. Google says it won't hurt you in Search.
• An existing llms.txt. Leaving one in place does no harm in Google Search. Just don't expect it to move anything.

Risky

• Bot-only copies. Serving one version to people and another to crawlers drifts toward cloaking. Our answer on separate versions of pages for AI crawlers explains why.
• Copies that drift. Two versions of a pricing page go out of sync. If an engine ever reads the stale one, it repeats the wrong number.
• Hidden instructions. Text aimed at steering AI answers, hidden from people, is adversarial content. It's illegitimate and a reputational risk. Never use a machine-only file to carry it.

The rule of thumb: one page, one set of facts, the same for every visitor.

The rendering evidence is the strongest in the field. Vercel found that ChatGPT and Claude crawlers fetch JavaScript files (11.50% and 23.84% of their requests) but don't execute them, so they can't read client-side rendered content. Independent testing in June 2026 found the same for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot and PerplexityBot. Googlebot is the main exception, because it renders.

Here's the order of work:

1. Diff raw and rendered HTML. Fetch a key page with JavaScript off, then render it in a browser. List every price, product name and claim that appears only in the rendered version.
2. Move those facts into the server response. Use server-side rendering or prerendering for the content that matters. The SaaS pricing page playbook walks through this for prices.
3. State facts as plain sentences. A specific price, number or one-line definition on a fetchable page gives an engine a sentence it can quote. That's the only on-page signal with experimental support, and it promises nothing about selection.
4. Check access per bot. Confirm robots.txt allows OAI-SearchBot, PerplexityBot and Claude-SearchBot, then confirm your firewall doesn't turn them away. The AI Crawler Checker requests a page as each crawler and shows which ones get blocked.
5. Look for accidental suppression. Template-level noindex, nosnippet, max-snippet:0 or data-nosnippet can keep content out of AI answers.

None of this guarantees a citation. It removes the blocks that are yours to remove. For the wider evidence, see on-page rewrites versus access fixes.