Framer already serves your pages as Markdown to AI. Almost nobody knows
Framer serves a Markdown version of every optimised page to any client that asks for it. Two ways to ask: an `Accept: text/markdown` request header, or `?md` on the end of any URL. No plugin, no setting, nothing to configure. Framer documents both. Whether AI crawlers use either one, nobody has published, including Framer.
Category
Platform
Reading time
6 min
Framer serves a Markdown version of every optimised page to any client that asks for it. Two ways to ask: an Accept: text/markdown request header, or ?md on the end of any URL. No plugin, no setting, nothing to configure. Framer documents both. Whether AI crawlers use either one, nobody has published, including Framer.
Desses is a Framer Partner and a Framer Pro Expert, and we sell Framer development, so read the rest knowing where my money comes from. The Pro Expert standing is automatic, earned by taking at least $500 in commissions on client project handoffs. Nobody at Framer decided I was good.
What comes back when you ask for Markdown
Markdown delivery on Framer is server-side content negotiation: ask for a page as text/markdown and Framer hands back that page's text as Markdown where it would have handed back HTML. The page itself doesn't change. The representation does.
Framer's help article describes the two request methods, the ## Navigation block appended at the bottom of every Markdown page, and two limits. It says nothing about frontmatter. We got that with curl. Every page we pulled opens with YAML carrying title, description and published, which is observed output, absent from Framer's documentation.
One thing in that frontmatter is worth knowing before you lean on it. The published value is identical on every page of a site. On 8 September 2026, desses.co returned Sep 8, 2026, 1:43 PM UTC on its homepage, about and contact pages, and framer.com returned Sep 8, 2026, 12:18 PM UTC on both pages we pulled. That timestamp tracks the last site publish. An agent reading the frontmatter for freshness gets told everything on your site went live this afternoon.
How you request the page | What Framer returns | Why you'd use it |
|---|---|---|
Plain | Pre-rendered HTML with JSON-LD, H1 and canonical | The default. What every crawler gets without asking |
| Markdown with YAML frontmatter and a Navigation section | Content negotiation. Same URL, different representation |
| The same Markdown | Works in a browser address bar, so you can audit a page without curl |
Framer's LLM comment lives on framer.com, and your site doesn't get it
There is a comment addressed to language models in the head of framer.com:
It's real, it's verbatim, and it's custom code. In framer.com's source it sits between <!-- Start of headStart --> and <!-- End of headStart -->, the block where Framer injects whatever a site owner has typed into Project Settings, Custom Code. Somebody on Framer's own team typed it in. Your Framer site does not inherit it.
We checked two Framer-hosted sites, desses.co and oma-kase.com. Both carry the empty headStart block. Neither carries the comment. View source on your own Framer site and you'll have the same answer in ten seconds, which is why you should hear it here first.
Two more machine-addressed lines sit in that same head, in a second custom-code snippet: a rel="describedby" pointing at framer.com's llms.txt, and a rel="alternate" type="text/markdown" pointing at ?md. Also custom code, also absent from both customer sites.
Those three lines are the interesting part. They are Framer's own bet on what a crawler does when it lands on a page: that some agents read HTML comments, that some follow rel="alternate" to a text representation, that rel="describedby" earns the line it costs. The company that built the Markdown endpoint is hedging three ways on its own marketing site and shipping none of the hedges to yours.
Copy all three into Project Settings, Custom Code. I'd do it. It costs nothing and something might read it. Framer has published no evidence that any of the three changes a single citation.
Every Framer page is pre-rendered before it's served
Framer's documentation puts it plainly: "Although Framer sites are built with React, every page is pre-rendered to HTML on our servers before it is served. AI agents and crawlers that do not execute JavaScript still receive the full text of your page."
We tested it the boring way. A curl against a Framer content page with GPTBot's user agent returns two JSON-LD blocks, one H1, the canonical link, and roughly 160,000 characters of body text in the initial HTML response. Nothing waiting on the client. A React site that fails this test returns an empty shell and a script tag.
That matters because the fetches deciding whether you get quoted read raw HTML. No major AI crawler executes JavaScript on a live fetch, on the two measurements anyone has published. Framer pre-renders into that raw HTML and offers stripped Markdown on top of it. Both facts have been public for months and I can't find anyone who has put them together in writing.
Nobody has measured whether crawlers use it
Two documented limits. Markdown is generated only for optimised pages, and it drops out while a site is rate-limited, so a crawler arriving mid-spike gets nothing where a browser got Markdown ten minutes earlier.
The bigger gap is empirical. Framer makes exactly one claim about who uses the endpoint, in the help article, about the Accept header: "This is the primary method used by most AI tools." No study, no log sample, no number, no link. It's a sentence.
Framer has published no data on whether crawlers request the Markdown version. No third party has. We haven't either. Anyone quoting you a figure for this today made it up.
The nearest comparable case is a warning. Ahrefs found 97% of domains carrying a valid llms.txt got zero requests for it in a month, in the most llms.txt-aware population anybody has measured. That file is the cautionary tale. My argument for why ?md should fare better is that it lives on the page's own URL, and a crawler holding the URL can simply ask. I have no measurement behind that.
We're running server-log analysis across client Framer sites, filtering for markdown-negotiated requests by verified bot IP. When there's enough to say something, we'll publish the numbers, including if they're boring.
What this doesn't do
Markdown delivery won't make a Framer site visible in AI answers. It removes one obstacle, and the obstacles it leaves standing are bigger.
Thin content served as clean Markdown is still thin content. If the site isn't being crawled at all, none of this applies, and the logs will tell you that first.
Google says the whole category is unnecessary. From Search Central's documentation on AI features: "You don't need to create new machine readable files, AI text files, or markup to appear in these features." They're describing AI Overviews and AI Mode, both grounded in the Google index, where the ordinary crawl already holds your text. The Markdown endpoint is aimed at the other half of the market, the standalone assistants doing live fetches.
Framer's own AEO material, honestly assessed
Framer runs an AEO scanner at framer.com/aeo. It works on any URL, including sites not built in Framer, wants your URL, first name, last name and business email before it runs, and Framer's own disclaimer says results may not be perfect. Budget for the follow-up email.
The written guides are the weak part. Framer's answer-oriented pages guide is a short page of generic AEO advice, and its schema step recommends FAQ markup. Google's FAQ rich result stopped appearing on 7 May 2026 and the documentation came down on 15 June 2026. The guide never mentions the Markdown endpoint, the pre-rendering, or the three lines Framer runs in its own head.
What we do on a Framer build
Check ?md on every page template before launch. Homepage, service page, CMS article, category page. A template returning nothing isn't optimised yet and goes on the fix list.
Copy Framer's own three head lines into Project Settings, Custom Code. Cheap, reversible, unproven.
Add JSON-LD through custom code with CMS variables, using {{FieldName | json}} for safe escaping. We do it for the search index and expect nothing from it on a live fetch.
Put the answer in visible text near the top of the page. Then read the logs, because server-log analysis is the only method that shows whether retrieval bots reach your content at all.
If you want the build side of that, our Framer development work covers the setup end to end.
If you're on Framer and want to know what an agent sees, send me your URL. I'll run ?md on your three most important pages and send back what came out, plus what I'd change. Twenty minutes, costs nothing.