How to Add an llms.txt File to Webflow
- Webflow gives you no way to publish a plain-text file at yoursite.com/llms.txt. The asset manager uploads files to Webflow's CDN, which sits on a different hostname than your site root.
- A page slug can't carry a .txt extension, so a page called llms-txt serves HTML at /llms-txt. Wrong path, wrong content type.
- The route that works is a small proxy in front of Webflow, usually a Cloudflare Worker that answers /llms.txt and forwards everything else to your site.
- llms.txt adoption is partial. No major AI operator documents it as a signal its crawlers follow, so treat the file as a cheap bet rather than a lever.
- Only your own server sees whether a crawler fetched it. Publishing the file and having it read are two separate events, and only one of them is in your control.
Short answer: Webflow has no clean setting for this, so you either put a proxy in front of the site or skip the file entirely. There is no third option that puts a real plain-text file at your root.
What llms.txt is, and why the path matters
llms.txt is a markdown file served as plain text at the root of a domain, at yoursite.com/llms.txt. Clients that look for it fetch that exact path. Put it on a subdomain, or in a folder, and most of them will never find it, because they don't go hunting.
The file itself is simple. A heading with your site name, a one-line summary in a blockquote, then grouped links to the pages you want summarised. That's the whole format.
It is a hint rather than a rule. Nothing about it changes how a crawler is classified, which matters once you look at the bot taxonomy and see that live fetches, index crawlers and training crawls are three different jobs. The same goes for Applebot-Extended (a robots.txt control token, not a crawler). It's a token you disallow, and it will never appear in a log.
What Webflow actually allows
Webflow serves pages you build in the Designer, plus static files you upload in the asset manager. Uploaded files get a Webflow CDN URL on a Webflow hostname. Your domain root is not a place you can write to.
I can't point you at a Webflow setting for root-level files, because I couldn't confirm one exists. If you have found one, you already know more than this post does.
Page slugs are the other tempting shortcut. A slug builds a page path, and Webflow won't give it a .txt extension. You end up with an HTML page at /llms-txt, which is a different URL serving a different type of content.
| What you try | Does it land at yoursite.com/llms.txt? | What you take on |
|---|---|---|
| Upload llms.txt in the Webflow asset manager | No. It gets a Webflow CDN URL on a different hostname. | Nothing. It also does nothing. |
| Publish a page with the slug llms-txt | No. You get HTML at /llms-txt with no .txt extension. | Nothing. |
| 301 redirect /llms.txt to the CDN file | Sometimes. Only clients that follow redirects will read the content. | A redirect rule, plus a check that the destination sends text/plain. |
| Cloudflare Worker on a proxied domain | Yes. The Worker answers /llms.txt directly. | DNS proxied through Cloudflare and a short piece of edge code to maintain. |
| Move to a host with a real file root | Yes. | A full site migration, which is far bigger than this file deserves. |
The route that works: a proxy in front of Webflow
You keep Webflow as your host and put something in front of it that answers one path.
Step 1: Send your DNS through Cloudflare
The domain has to be proxied by Cloudflare, which means your DNS records live there with the orange cloud on. Webflow keeps serving the site. Cloudflare just gets first look at each request.
Step 2: Write a Worker that answers /llms.txt
A Worker is a few lines of JavaScript that runs at the edge. Yours checks the path, returns the file if it matches, and passes everything else to Webflow untouched.
const LLMS = `# Your Site Name
> One line on what you do and who it is for.
## Pages
- [Pricing](https://yoursite.com/pricing): what it costs
- [Docs](https://yoursite.com/docs): how it works
`;
export default {
async fetch(request) {
const url = new URL(request.url);
if (url.pathname === "/llms.txt") {
return new Response(LLMS, {
headers: { "content-type": "text/plain; charset=utf-8" }
});
}
return fetch(request);
}
};The content-type header is the part people forget. Send it as text/html and you have rebuilt the page-slug mistake with extra steps.
Step 3: Test the response
Run curl -i https://yoursite.com/llms.txt. You want a 200 and a content-type of text/plain. If you see a 404 or an HTML body, the Worker route isn't matching and the request is going straight to Webflow.
llms.txt will not do the job people want it to do
If you want the file because you'd rather AI systems didn't train on your content, this is the wrong tool. llms.txt has no enforcement. The blocking conversation belongs in robots.txt, and even there the picture is messier than most posts admit. Blocking a training crawler does not remove your site from that operator's answers, because the indexer and the live fetch are separate tokens. Should You Block AI Training Bots but Allow Answer Bots? walks through that split in detail.
It also doesn't stop the crawlers nobody asked for. Bytespider (ByteDance) is a training crawler that sends no traffic back, regardless of what your llms.txt says.
Nobody is obliged to read it, so watch the crawlers instead
Publishing one costs a few minutes. Several documentation platforms and developer tools do read llms.txt. No major operator has publicly committed to honouring it, and neither OpenAI, Anthropic nor Google documents it as a signal their crawlers follow. That is the honest state of play, and any post claiming otherwise is selling you something.
Your server is the only place that can tell you whether the file was fetched. Keep a Worker log line, or read the request logs on whatever sits in front of Webflow.
Most sites do not have that hooked up to anything useful. Why GA4 Can't Show You AI Citations covers the gap on the human side. On the crawler side, Kymo keeps the crawler user-agent on the crawler's own event row so a classification stays auditable, and stores no user-agent string for human visitors. Cookieless Analytics, Explained Without the Jargon explains why that split matters. The AI crawler directory lists every agent Kymo classifies, and if you have ever confused two agents from the same company, ClaudeBot vs Claude-SearchBot: What Each One Does on Your Site is worth ten minutes.
If you want the short version of what to do about any of it, The Small Business Guide to AEO covers the practical steps. And you can check where you stand today without installing anything, using Kymo's free AI visibility checker.
My recommendation
Do the Cloudflare Worker if you already run your DNS through Cloudflare and you like having the file at the correct path. Publish it, log it, and move on. Skip the whole thing if you're on a free Webflow plan with a webflow.io subdomain, if a proxy is new territory for you, or if you haven't yet measured which crawlers already reach your pages. The file is a cheap bet, and cheap bets only pay off after you can see what's hitting your site.
Check what already crawls you
Run the free AI visibility check on your own URL. It reads public signals only, so your site does not need Kymo installed, and the report arrives by email. If you'd rather watch the crawler traffic continuously, start tracking it and see which AI engines already fetch your pages.
Start free → 14-day free trial. No card required.