Should I change anything on my Webflow site because of Source?
Not yet, and not in a hurry. Webflow announced Source at Webflow Conf 2026, and Webflow says it is available in a limited research preview. A research preview is an invitation to learn, not a migration deadline. The useful work this quarter is tidying what you already run.
I have been building on Webflow for a while as a Certified Webflow Partner, and I have watched a lot of people react to keynotes by rebuilding things that were working fine. That is usually the expensive choice. A keynote tells you where a platform is heading. It rarely tells you what to do on Monday.
So this piece is deliberately narrow. I am not going to guess at pricing, availability windows, or who gets access. Webflow has not published those, and I am not going to invent them. I am going to read what Webflow actually said, then talk about the decisions that are genuinely yours to make right now.
What exactly did Webflow announce at Conf 2026?
Webflow opened Conf 2026 with CEO Linda Tong on stage and unveiled Source by Webflow, described as a new platform for modern marketing teams and their AI agents. Webflow says Source connects your codebase and martech stack, bringing agentic and visual development into one shared environment.
Two details in that sentence matter more than the branding. The first is codebase. Webflow says Source makes code the foundation for everything that ships on your site, and that with direct access to that code its agents can take on larger changes without the constraints of an abstraction layer. That is a real architectural statement, not a marketing line.
The second is composable by default. Webflow says Source brings your codebase, CMS, hosting and marketing tools into one environment, and it explicitly includes sites you have already built in Webflow. Read plainly, that is Webflow saying your existing site is meant to be part of this, not stranded by it.
Webflow also introduced Views, which it calls a new primitive that lets teams customise workspaces for every member of the team. Views are described as dedicated surfaces for visual site building, campaigns, content and optimization.
What does a limited research preview actually mean for you?
It means the product is real enough to show and early enough that Webflow wants feedback before it hardens. It does not mean general availability, and it does not mean the shape you see today is the shape you will get. Plan around that uncertainty rather than against it.
I treat research previews the way I treat a beta CRM integration on a client project. I will happily read the docs, run a throwaway test, and form an opinion. I will not put a client's lead flow through it and promise them uptime. The difference between those two postures is who carries the risk if the thing changes next month.
There is also a quieter signal in the phrase. When a vendor ships a preview of a platform rather than a feature, it is telling you the direction is settled even if the details are not. Direction is the part you can plan against.
Why does Source matter more to developers than to marketers right now?
Because the headline claim is about code. Webflow is describing an environment where agents work against the real codebase instead of a visual abstraction. That changes what is technically possible before it changes anyone's weekly marketing routine.
If you are a marketer, the honest read is that Campaigns and Webflow AEO are closer to your day than Source is. Webflow describes Campaigns as a product that takes performance marketers from brief to live landing pages, personalized variants and matched ads. That is a workflow you can picture immediately.
If you are the person who maintains the site, Source is the announcement to actually think about, because it changes the assumptions under everything else. It is worth reading the expectations I set before Conf against what landed, because the gap between those two is where I learn the most.
What did Webflow announce alongside Source?
Quite a lot, and some of it ships closer to the ground. Webflow announced Campaigns for performance marketers, Assets for on-brand creative, Releases for staging big launches, content agents inside Webflow AEO, automatic Agent Instructions, and Agent Presence on the canvas.
Assets is the one I did not expect. Webflow describes it as an agentic way to produce and adapt on-brand creative, built on technology from Vidoso, a company Webflow says it acquired earlier this year. Acquisitions that surface as shipped features usually mean the team has been working quietly for a while.
Releases is the one I want most. Webflow describes it as a way to branch an entire site, including pages, CMS content, components, assets and locales, so big launches are staged together before they ship. Anyone who has ever published a Webflow site at the wrong moment understands why that matters.
Content agents in Webflow AEO are described as finding the topics where competitors are getting cited instead of you, then drafting original content in your CMS. That is a direct answer to the question every client has started asking me: not just how do I rank, but why is the model quoting someone else.
How do the MCP updates change day to day work?
Webflow says the MCP updates give agents expanded access to Webflow, specifically naming Interactions with GSAP, deeper CMS querying, and help managing deploys to Webflow Cloud. For anyone already driving Webflow through an agent, that is the most immediately usable thing announced.
If you already drive a Webflow site through an agent, this is where you will feel the difference first. Deeper CMS querying is the unglamorous one that changes the most. If an agent can ask better questions about your collection before it writes, it makes fewer bad guesses, and you review less slop.
I wrote separately about what the MCP release opened up for agents, and about what generated agent instructions actually mean in practice. Both are worth reading before you let an agent near a production collection.
What should you build now so it survives the move?
Build the things that are portable. A clean content model, honest component naming, real internal links and a site anyone can reason about will still be assets in any environment Webflow ships. Clever workarounds will not.
The single highest leverage thing I do on client sites is fix the CMS structure before anything else. Fields that mean one thing. Categories that are references rather than free text. Slugs that will not need rewriting in a year. None of that is exciting, and all of it survives a platform shift, because it is your data rather than Webflow's implementation.
The second thing is documentation that a person or an agent can read. If your site has rules, write them down somewhere the tooling can see them. That habit pays off whether the thing reading it is a new contractor, a content agent, or you in eight months.
What I would not do is architect around a preview. Building for an unreleased shape of a product tends to end in rebuilding it later, and that bill usually lands on whoever made the call.
When is waiting the right call?
Waiting is right when your current setup is not actually blocking you. If your site ships, your CMS is sane, and your team is not queuing behind a bottleneck, there is no prize for being early. Preview access is a cost as much as a benefit.
The exception is when the announcement names your exact pain. If you genuinely cannot stage a large launch safely today, Releases is worth watching closely. If your bottleneck is producing landing page variants, Campaigns is worth watching closely. Match the tool to the pain you already have, not to the one the keynote suggested you should have.
Across more than 70 projects for more than 25 clients over more than six years, the pattern is consistent. The teams that waited and kept their fundamentals clean adopted new platform capability faster than the teams that chased every release, because they had less mess to untangle when the thing was finally ready.
What is the honest risk of betting early?
The risk is rework, and rework is usually paid in your own hours rather than in fees. Previews change. Naming changes. Behaviour changes. If your client's revenue runs through something that is explicitly labelled a preview, you own that decision when it moves.
There is a softer risk too. Early access is fun, and fun is distracting. It is easy to lose weeks to interesting tooling that never moves a client outcome. I try to ask one question before I start: if this works perfectly, which client gets a better result this quarter? If I cannot name the client, I read the docs and move on.
None of this is an argument against curiosity. I will be reading everything Webflow publishes about Source, and I will test it the moment it is sensible to. I just will not confuse testing with committing.
What should you do next?
Read Webflow's own announcement rather than the summaries. Then spend an hour on your content model instead of your roadmap. The gap between a site that adapts easily and one that does not is almost always structure, and structure is something you can fix today without any preview access at all.
If you want a concrete starting point, open your main CMS collection and ask whether every field still means what it meant when you created it. Then check whether your categories are references or loose text. Then check whether an outsider could tell which template renders what. That is a boring afternoon that pays for itself repeatedly.
If you are weighing whether any of this changes your plan for the next quarter, or you want a second pair of eyes on a Webflow build before you commit to a direction, reach out. I am happy to talk it through and tell you honestly if the answer is to do nothing.
Get found, cited and the back office automated
Let's make your site the source AI engines quote and wire up the systems behind it.
Read more blogs
Let's get your website found and cited by AI
Tell me what you're working on, whether AI search is skipping your product, your back office is buried in manual work, or you need a build that does both.