Replacing Webflow with Claude Code: what actually works
Coding agents have made owning a website in code cheap enough that teams are leaving visual builders over it. The experiments that fail all skip the same layer. What moving off Webflow to agent-built, human-directed code takes when it has to hold up in production.
Over the past year a genre of article has taken shape: someone cancels their Webflow subscription, points Claude Code at an empty repository, and writes up what happened. The stories travel because the premise is real. Coding agents have collapsed the cost of owning a website in code, and people who could never justify a hand-built site before are finding they can have one now.
The write-ups fall into two camps, and it is worth noticing who writes each. The cautionary ones — crawl errors in Search Console within days, an agent that fixes one issue while creating another — are largely first-person accounts of solo experiments, like Karpi Studio’s test, whose author kept the agent-built site for a small personal project while concluding that a site which mattered would go back to Webflow. The reassuring ones, which conclude you should keep Webflow and add AI on top, are mostly written by Webflow agencies. Both camps are describing something true from where they stand. Neither describes what the move looks like when an engineering team runs it.
We have a position in this discussion worth disclosing. wayf.ai, the site you are reading, is a code site, and the people who run WAYF build and operate it with coding agents doing the implementation. What the site says, which pages exist, how they are structured, and what ships are decisions made by those people; the agents turn those decisions into code inside written conventions, and nothing reaches production until a person has read the diff and checked the rendered page. The site previously ran on a visual builder — Framer, a platform we still partner on and build with when it fits. The pipeline behind our own changes is the one we give clients.
What the agent actually changed
The case for a visual builder was that maintaining hand-written code required a developer on call, and the builder replaced that developer with a subscription. For a decade that trade made sense for most marketing sites.
Coding agents reprice the trade. The maintenance work that justified the subscription — a new section, a layout fix, a landing page for Thursday’s campaign — is now something an agent does in minutes from a plain-language request. What is left on the other side of the ledger are the builder’s structural costs, which have no agent workaround: per-seat editor pricing, CMS collection and item caps, content that lives in the vendor’s database, and a design system that cannot leave the platform. We covered those limits in detail in our Webflow-to-Payload guide; they are unchanged. What changed is that the thing they were traded against got cheap.
Webflow sees the same shift — it now ships an official MCP server so agents can drive the Designer and CMS APIs directly. Agent-plus-Webflow is a real option, and for teams staying on the platform it is a good one. It moves the work into the agent while the seats, the caps, and the vendor’s database stay where they were.
Why the solo experiments fail
Read the failure stories closely and the pattern repeats. The agent generates a site; the site deploys; nobody with production experience looks at what shipped. Redirects from old URLs are missing. Metadata is malformed. The sitemap references pages that do not exist. Search Console notices before the owner does, and each request to fix the report resolves one line and breaks another, because the agent is debugging its own unreviewed output with no test suite underneath it.
None of this is an argument about agent capability. It is what running any codebase without engineering discipline looks like, at agent speed. Webflow never asked its customers to think about review gates or CI, because the canvas previewed exactly what publish would do. Off the platform, that guarantee has to be rebuilt.
The layer that makes it hold
Where sites built this way work in production, the setup looks the same. The site is a repository. No one — human or agent — pushes to production directly; every change is a pull request. CI builds each one and fails loudly on broken types, dead links, or a build that will not compile. Each pull request renders to a preview URL, so the person approving looks at the actual page. Production deploys from the main branch, and any deploy is revertable in one commit. Direction stays with people: someone decides what changes and why, the agent produces the diff, and a reviewer judges the result on the preview. The agent works inside written project conventions that encode the rules of the site the way a senior engineer would brief a new hire.
This is the “securely” in migrate off Webflow securely, and none of it is exotic. It is the standard discipline of software teams, applied to a marketing site now that a marketing site can afford it. Setting this layer up is where most of the migration effort goes.
For the marketing team, day-to-day looks like this: structured content — posts, case studies, job listings — lives in a CMS the company owns, with drafts, scheduling, and roles, priced without per-seat arithmetic. Page and layout changes are requests to the agent, in the team’s own words, answered with a preview link and shipped on approval. The scope of what can be asked for stops being bounded by what a builder’s settings panel exposes.
When Webflow is still the right answer
The honest cases for staying have not moved. A small site that changes rarely has little maintenance to reprice. A team with no one willing to approve pull requests — even with previews making that a visual, non-technical act — should not adopt a pipeline nobody will operate. And a team mid-campaign with working Webflow muscle memory should finish the campaign first; replatforming during a push is how both suffer. Webflow with its MCP server is also a legitimate way to get agent leverage without moving, at the price of keeping the platform’s structural limits.
What we would not recommend is the path the failure stories document: cancelling the subscription and letting an agent free-run at production with no review layer. The experiments have run that test often enough.
Running the move properly
A Webflow exit done as an engineering project has a known shape. Export what the platform lets you export — CMS content comes out; the design system does not. Rebuild the templates in a modern framework. Move structured content into a CMS your company owns, or into the repository itself when the content is simple. Stand up the pipeline — CI, preview deploys, review rules, redirects for every old URL — before the team starts directing daily changes through the agent, so that from the first day of operation nothing lands unreviewed.
This is the shape WAYF runs on its own site and can run for yours — the same discipline behind our enterprise CMS migrations, applied at marketing-site scale, with AI agents in the loop the way we already use them in our own delivery. The Webflow migration page is where to tell us what you are running. A free consultation and a scoped, fixed quote come before any commitment.
FAQ
-
Can Claude Code replace Webflow?
For the code itself, yes — an agent can build and maintain a marketing site in a modern framework, and the result is faster, portable, and free of per-seat and collection limits. What the agent does not replace is the production discipline Webflow bundled in: review before publish, staging, rollback, monitoring. Teams that set that layer up run production sites this way, with people deciding what changes and agents doing the implementation. Teams that skip it end up in the fix-one-break-one loop the first-person write-ups describe.
-
Can ChatGPT or Codex replace Webflow instead?
The agent matters less than the setup around it. Claude Code, Codex, and other coding agents can all edit a well-structured repository; they all also degrade the same way without review gates and CI. Pick the agent your team already works with, and spend the decision budget on the repository structure, the deploy pipeline, and who approves changes.
-
Is it secure to let a coding agent manage our website?
It is as secure as the pipeline you run it through. An agent with direct production access is a risk; an agent whose every change lands as a pull request, built by CI, rendered on a preview URL, approved by a person, and revertable in one commit, operates inside the same guardrails as a human developer. That pipeline is standard software engineering, and setting it up is most of the actual migration work.
-
What does the marketing team use instead of Webflow's editor?
Structured content moves into a CMS the company owns — Payload is what WAYF deploys — where editors keep drafts, scheduling, and roles without per-seat pricing. Layout and page changes go through the agent: the request is written in plain language, comes back as a preview link, and goes live on approval. The practical trade is more room to ask, since requests stop being bounded by what the builder's UI exposes.
-
How do we move a Webflow site to code?
Export what Webflow lets you export, rebuild the templates in a modern framework, move structured content into a CMS or the repository, and stand up the pipeline — CI, preview deploys, review rules — before the team starts directing day-to-day changes through the agent. Our Webflow migration page covers scoping; a free consultation and a scoped, fixed quote come before any commitment.
Sources
We're booking content platform
engagements for 2026.
Twenty-five minutes to walk through the work and decide if we're the right team for it. Scoping and a fixed price come after.