The complete AI readiness setup for Framer in 2026

A brand-new Framer site scores better on an agent readiness scan than a new site on almost any other hosted builder, and that is exactly what makes the remaining gaps hard to see. Framer pre-renders every page on its own servers, generates a robots.txt and a sitemap.xml for every published site, and hands any agent that asks a clean Markdown copy of the page. None of that needs configuring. So when a Framer site drops points, it drops them on the three surfaces a default cannot express: which AI crawlers you actually allow, an llms.txt, and a feed. This guide covers those three, verified on 4 September 2026 against Framer's own help articles and two live Framer sites.

Quick summary

What Framer builds before you touch anything

Framer's help article on AI agents states the mechanism in its own words, and the page was last updated on 7 August 2026: "Although Framer sites are built with React, every page is pre-rendered to HTML on our servers before it is served." That single sentence settles C3 and E3. A crawler that never runs JavaScript still receives headings, paragraphs, <title>, meta description, canonical, Open Graph tags and any JSON-LD you added.

The part fewer people know about is the Markdown. Framer serves a Markdown version of every optimized page at the same URL, reachable two ways: an Accept: text/markdown request header, or a bare ?md query parameter. That is check C1, passing by construction, on a platform where nobody had to write a line of code for it.

The size difference is the interesting bit. Both rows below were fetched from the live sites and verified on 4 September 2026:

Both Markdown responses came back as 200 text/markdown; charset=utf-8, with YAML front matter carrying title, description and published, then an H1, then the body. Framer appends a ## Navigation block of sitewide links to the end of each one, which its documentation describes, according to that same article, as a discovery aid so an agent can keep walking the site after it finishes reading.

Very few platforms clear C1 honestly. Most return HTML with a 200 status and get scored as a pass by any checker reading status codes alone, the false-pass pattern we have measured on Ghost, on Shopify storefronts and on Replit apps. Framer returns real Markdown, and it hard-404s what it does not have: on www.linkpreview.app, /llms.txt and /llms-full.txt answered 404 with a ten-byte body, and an invented path answered 404 with the site's own error page. E1 passes without help.

Why good defaults hide the gap

Here is the auto-generated file, fetched from www.linkpreview.app/robots.txt on 4 September 2026. Seventy-two bytes, in full:

User-agent: *
Allow: /

Sitemap: https://www.linkpreview.app/sitemap.xml

D1 passes. D2 passes, because the sitemap is declared. And B2 fails, because nothing in that file addresses an AI crawler by name. According to Framer's own article, "All AI and search crawlers are allowed by default in your auto-generated robots.txt", and it lists the agents it tests against: Googlebot, GoogleOther, Google-Extended, Bingbot, GPTBot, PerplexityBot, YandexBot and AhrefsBot.

Allowing everything is a real decision, and for most Framer sites it is the right one. It is also invisible. B2 asks whether a site has stated a preference about AI crawlers, and a wildcard says nothing about them. Google's robots.txt spec is why that matters mechanically: only one group applies to a crawler, the most specific one that matches, and every other group is ignored.

Framer knows this, which is why its own marketing site does not run the default. www.framer.com/robots.txt is 546 bytes, adds a set of query-parameter disallows, declares two sitemaps, and ends with a Content Signals line reading ai-train=yes, search=yes, ai-input=yes. That file is a custom upload, which is the same door you will use.

Path 1: the Files panel, on Pro and Enterprise

Framer's static file hosting is how anything lands at a fixed root path. The help article notes these settings "used to live in the Domains dashboard and are now in your project's Site Settings, under Hosting", so older tutorials point at a panel that moved.

1. Open your Framer dashboard.
2. Open Site Settings.
3. Go to Hosting → Files.
4. Click Add.
5. Upload the file.
6. Set the file path, without the file name. For a file at the domain root, that is /. For /.well-known/security.txt, the path is /.well-known.
7. Publish the site.

Supported text formats are PDF, TXT, CSV, JSON, XML, MD, VCARD and JS. Anything served as text/plain, text/xml, application/xml or application/json renders in the browser; other types download instead. That list is what makes .well-known capability files reachable on a $30/month Framer plan. Two platforms we have written up put them further away: on Webflow the only route is an API call requiring an Enterprise workspace, and on Ghost the theme middleware turns down .json entirely.

The trap worth writing down. Framer's robots.txt help article says it plainly: "When you upload a custom robots.txt, it replaces the automatically generated one." Replaces, not merges. The generated file's Sitemap: line goes with it, so if you upload a robots.txt without re-adding that line by hand, you pass B2 and break D2 in the same publish. Start from the generated file, not from a blank one:

User-agent: *
Allow: /

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

Content-Signal: ai-train=yes, search=yes, ai-input=yes

Sitemap: https://example.com/sitemap.xml

Then upload llms.txt the same way, at path /. Framer's llms.txt article is explicit that the file is optional, and its own FAQ answers the plan question directly: static file hosting for llms.txt "is available on the Pro and Enterprise plans". Framer publishes its own at www.framer.com/llms.txt, 5,900 bytes on 4 September 2026, and it is a good model: a one-line description, then H2 sections of annotated links pointing at the ?md version of each page rather than the HTML. If you would rather not hand-write one, the generator writes a spec-shaped starting point you can drop into the Files panel.

Path 2: serve the files in front of Framer, on any plan

Free and Basic sites cannot upload static files, so the root path is not yours. It still can be, if something else answers first. Framer documents reverse proxy hosting for exactly this: "your server requests pages directly from your Framer site and serves them to visitors", with Cloudflare, CloudFront, Vercel, Netlify and NGINX all named as supported platforms.

1. Add a custom domain to your Framer site to act as the origin, for example origin.example.com or a *.framer.website address.
2. Point your proxy at that origin. Framer's guide warns, verbatim, against using a *.framer.app domain here, because "framer.app domains aren't indexed by search engines, which will negatively affect SEO".
3. Add routes at the proxy for /robots.txt, /llms.txt and your feed, returning static text with the correct content type, and pass everything else through to Framer untouched.
4. Set the Canonical URL in your site's General settings to the public address visitors see.
5. Publish, then request each of the three paths on the public domain and confirm the proxy answered rather than Framer.

Two constraints from Framer's compatibility notes matter here: do not modify or remove tags inside <head>, and do not touch anything inside <div id="main">. Adding head tags is supported; rewriting Framer's own is not. This route also covers E5, which has no native surface on Framer at all. Verified on 4 September 2026, /rss.xml, /feed.xml and /blog/rss.xml all returned 404 on www.framer.com, and there is no help article for feeds, so a feed on Framer is either an uploaded XML file you regenerate when you publish, or a route on the proxy that reads your CMS.

Structured data through Custom Code

Schema is neither automatic nor gated. Framer's JSON-LD article puts the markup in Custom Code, inside a <script type="application/ld+json"> tag in the <head>, and CMS detail pages can reference collection fields with a {{Field | json}} filter that escapes the value safely. {{Created}} and {{Updated}} are built in on every CMS item, so a BlogPosting block gets its datePublished and dateModified without extra fields. There is also a {{field | unsafeRaw}} form for schema stored whole in a text field, which Framer flags as risky because it escapes nothing.

If the site you are working on is WordPress rather than Framer, or you are moving between the two, ThinkRank is the one to reach for. It owns robots.txt, the robots meta tag, schema, sitemaps and llms.txt in one place, which ends the familiar situation where three plugins each believe they are in charge of the same file. Adoption is also cheap, because it imports what you already configured in Rank Math, Yoast, All in One SEO or SEOPress rather than making you type it again. And where a Framer marketing site fronts a Shopify store on another host, StoreSEO covers the store-side half: it builds the llms.txt out of your live catalogue, including collections, pages and articles, and gives you an editor for agents.md as well.

Confirm it worked

Start with a scan, because it answers all nine checks at once. npx aiscan-cli yoursite.com in a terminal does it, and so does dropping the address into AIScan; there is no account and no cost either way. You get D1, D2, B2, C1, C2, C3, E1, E3 and E5 back with the evidence string behind each verdict, which is how you tell whether B2 has moved off zero named agents and whether C2 is reading a real file. Framer also ships its own free AEO scanner, which grades rendering, structure and metadata; running both is useful, because they disagree in interesting places.

If you would rather check by hand, three commands cover it:

curl -sI https://example.com/ | grep -i server-timing
curl -s https://example.com/robots.txt
curl -s -o /dev/null -w '%{http_code} %{content_type}\n' \
  -H 'Accept: text/markdown' https://example.com/

What each one should return on a finished Framer site:

The first is the one nobody mentions. Framer stamps ssg-status into its server-timing header, and on every optimized page tested it read ssg-status;desc="optimized". That matters because Framer's own limitation note says "Markdown is only generated for optimized pages", so a page whose header does not say optimized is a page with no Markdown twin, and C1 will report the miss without telling you why. The third command should answer 200 text/markdown; charset=utf-8. If it answers text/html, check the first command again before changing anything.

Where AIScan fits, and where it doesn't

The scan reads what a URL returns. It sees your robots.txt, whether an AI crawler is named in it, whether /llms.txt resolves, what content type comes back under Accept: text/markdown, and whether an unknown path 404s properly. It cannot see your Framer dashboard. It does not know your plan tier, so it cannot tell you that the missing llms.txt is a Basic-plan limit rather than an oversight, and it will not tell you a page is unoptimized, because that lives in a timing header no rubric grades. It also does not currently grade a feed's absence differently from a feed that exists but is never declared. Read the scan for what is served, and read the Files panel and the server-timing header for why.

Ship the three missing files

Framer hands you rendering, Markdown, robots.txt and a sitemap for nothing, which leaves a short and specific list. Name the AI crawlers you allow, publish an llms.txt, and decide whether you need a feed. Scan the site at aiscan.site and read B2, C2 and E5 first, since those are the three a Framer site fails while everything else passes. The bot access page explains what B2 is looking for in a robots.txt, content covers C1, C2 and E5, and discoverability covers D1, D2 and E1. For the file itself, llms.txt on Framer goes deeper on what to put inside it, and the mistakes that break a file are worth reading before you upload. For contrast, our Webflow walkthrough and Replit walkthrough show two hosted platforms answering these same questions very differently. Every platform walkthrough we have published is indexed at /guides.