Framer, Webflow or Next.js for AI search

Framer for a marketing or content site that has to stay readable to AI crawlers without an engineer on staff. Webflow once the archive outgrows Framer's ceilings and you need a mature CMS API. Next.js when the site is the product. Rendering is close on all three. Everything below it is where they split.

Desses builds in Framer and Next.js. We're a Framer Partner and a Framer Pro Expert, and we turn down Webflow builds and rebuilds. Read the rest with that in front of you. A Webflow buyer can't hire us for a Webflow site, which is the whole reason I'm willing to publish a Webflow column.

Every Webflow cell below is read from Webflow's own documentation and linked per row. We haven't run any of it against a live Webflow site, and I flag those cells. Framer sells AEO as a feature and runs a scanner behind a lead form. Webflow sells it as a paid product behind a Team or Enterprise plan and an add-on. Neither can be objective about the other.

"Legible to an AI crawler" has one useful meaning: the page returns its full text in the first HTML response, before any JavaScript runs. Every other row is downstream, and the evidence that this is what crawlers do sits in its own article.

Twelve rows that decide a platform

Two Webflow cells carry a warning label. Nobody at Webflow publishes a rendering model, so the first row infers one from a sentence in a different help article. The schema-escaping cell reports an omission in the docs. Three checks close both gaps in an afternoon: fetch a live Webflow page with JavaScript off and count the body characters, bind a quote-heavy CMS field into head JSON-LD and view source, then rename a slug and watch the old URL.

Rendering is the row the others hang on

Framer's documentation puts it flatly: "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 checked it the boring way. A curl against a Framer content page as GPTBot returns two JSON-LD blocks, one H1, the canonical link and 160,000 characters of body text in the initial response.

Next.js can produce the same full-text response and it can produce an empty shell with a script tag. That's the whole trade in one line. Control you're obliged to use.

The Markdown row is the widest gap on the list

Framer serves a markdown version of any page to anything that asks, on every paid plan, nothing to configure. The output covers optimised pages only and drops out while a site is rate-limited. Webflow runs the same conversion automatically for LLM requests, on Enterprise sites, after a custom domain and a migration to Webflow's Cloudflare infrastructure. Same capability, four gates in front of it. On Next.js it's a route you write in an afternoon.

Weigh the row carefully. Neither vendor has published a number on how often crawlers request the markdown version, and neither have we. A feature nobody has measured demand for is worth nothing to plan around.

What the schema rows are worth, honestly

Less than three tidy rows suggest. The one controlled study found AI Overview citations falling 4.6% on pages that added JSON-LD, and no AI system tested extracted anything from JSON-LD on a direct fetch. The full evidence walk is its own article. Treat those three rows at a tenth of the weight of the first one, and treat llms.txt as decoration.

The robots.txt row is the one that can lose you everything

Blocking the wrong crawler costs more than picking the wrong platform. GPTBot builds training corpora and blocking it costs nothing in AI search. OAI-SearchBot builds the index ChatGPT cites from, and blocking that removes you from ChatGPT search. Same shape at Anthropic. The crawler article has the full table.

All three platforms hand you the file. Framer gates the override at Pro, which is the practical reason a content site starts at Pro whatever the CMS math says. Most sites that lose AI visibility lose it by being unreadable, not by being blocked.

When not to pick Framer

Forty collections and 40,000 items are hard ceilings, fully loaded, with every add-on paid. There's no enterprise phone call that moves them. Webflow's Premium plan sits at 40 collections and 20,000 items and its Team plan goes to 100, so the collection ceiling has somewhere to go over there. A publisher sitting on a 60,000-item archive has already made this decision and doesn't know it yet.

The API argument I made in the first version of this page no longer holds, and I'd rather retire it in public than leave it standing. Framer shipped a Server API on 12 February 2026 that syncs CMS collections with external sources like Notion or Airtable, publishes changes and updates project settings, from any server, triggered by a webhook, a scheduled job or an agent. CI-driven content pipelines run on Framer now. So does bulk migration by script. Anyone still writing that the Framer CMS is unreachable outside the editor is working from a stale page. Mine included.

The maturity gap survives. The Server API runs on streaming WebSockets, and Framer's own FAQ answers the REST question with "you can see how you could expose the API as REST endpoints in the example here", plus a reminder to add strong authentication yourself. That's a wrapper you own and maintain. Webflow's Data API v2 has been a documented REST surface for years. Moving 12,000 articles onto a seven-month-old WebSocket API is a different risk from moving them onto a mature one, and the client carrying it should be told which one they're taking.

A large editorial operation with real workflow, roles and approvals is not a Framer job. I say that as a Framer Partner whose revenue depends on Framer builds, because the alternative is hitting the ceiling in month nine and having that conversation with a client who paid me to see it coming.

Where Framer is the right call: a marketing site, a product site, a content hub in the low thousands of items, a team where the people publishing aren't engineers. Most companies reading this.

When Next.js is the answer, and when it's overkill

Next.js earns its place when the site is the product, when the content pipeline needs an API you can write against without a wrapper, or when you need URL shapes the hosted platforms can't make. It earns it again when the thing is app-shaped: accounts, real-time state, permissions, anything where the CMS is the smallest part of the build.

It's overkill for a 40-page marketing site with a blog. Hosting is the cheap part. Every copy change goes through a deploy, and whoever owns the site waits for someone who reads code. Marketing teams that need a sprint ticket to ship a landing page ship fewer landing pages, and that shows up in the numbers long before rendering does.

Next.js gives you every row in that table and hands you the bill for maintaining all of them.

What we'd run before deciding anything

Fetch your three most important pages with JavaScript off and count what comes back. If the body text is there, the platform is doing its job and the rest is content work. If nothing is crawling your site, a replatform won't fix that, so check the size of the prize before anyone signs anything.

Read your robots.txt and check OAI-SearchBot, Claude-SearchBot and PerplexityBot are allowed, verified by IP against Anthropic's published ranges. Then pull a month of server logs and count AI bot hits per page template. That's your baseline, measured from real requests.

Count your CMS items and multiply by your publishing rate for three years. If that number crosses 40,000, Framer is off the table today rather than in year three.

If you want us to run all of that against your build, how we scope and price this work is the place to start.

If you're weighing a replatform, send me your current URL and a rough item count, and I'll tell you whether the move is worth it. Fairly often it isn't, and I'll say so.