Most Framer versus Webflow advice is out of date about the CMS
We went to check a claim about Framer's CMS for a client and found the sources contradicted the vendor's own documentation.
This article started as a different one. We set out to write about where Framer's content system stops being enough, using the limits everybody cites, and went to confirm those limits before publishing. They did not survive the check. Several widely repeated claims about what Framer's CMS cannot do are contradicted by Framer's own documentation, which is a more interesting finding than the article we intended, and a useful warning about how platform comparisons age.
What do the comparison posts get wrong?
The relational claims, which are the ones people make decisions on. A recurring line is that Framer has no native way to relate one collection to many items in another, and another is that collections cannot be nested. Framer's own documentation describes collection references and multi-reference fields, and describes nesting collections inside other collections to show related content on a detail page. Whatever was true when those comparisons were written, it is not what the vendor documents now. If you are choosing between platforms on the basis of a relational limitation, that is the specific claim to verify before it decides anything.
Why should you not trust the numbers in this article either?
Because platform limits are commercial decisions that change whenever pricing changes, which is often. Item caps, collection counts, page counts and what sits behind an add-on are all revised as vendors restructure their plans, and an article carries whatever was true on the day it was written with nothing to signal when that stopped. This is why we have not printed a table of figures here: it would be the most quoted part of the page and the first part to become wrong. The durable advice is the method rather than the numbers. Open the vendor's current pricing and limits pages, and write what you find into the project brief with the date attached.
So what does actually separate the two?
How the site gets edited after launch, and by whom, which is a question about your team rather than about feature lists. Framer's canvas is closer to how designers already think, so a design-led team ships and iterates on it quickly. Webflow's model is closer to how the web is actually structured, which is slower to learn and pays back when several people who did not build the site have to maintain it for years. Both will build a marketing site with a blog and case studies. The one that suits you depends on whether the person changing the site next month is a designer or a marketer.
Does the CMS ceiling ever actually decide it?
Occasionally, and much later than the comparison posts imply. Most businesses choosing between these tools are building something in the low hundreds of content items and will still be there in five years, which is nowhere near any current ceiling on either platform. The projects where the cap genuinely decides are the ones generating pages systematically: directories, large catalogues, deep publisher archives. If that is you, the item count is the first thing to check and it may well rule one out. If it is not you, choosing on a limit you will never approach means optimising for a problem you do not have, at the cost of the one you do.
How should you read a platform comparison at all?
Check the date, check who profits from the conclusion, and verify any specific limit against the vendor before it decides anything. Almost every comparison in this category is published by a studio that builds on one of the two, and that does not make them dishonest, but it does mean the conclusion was available before the research. This article has the same problem and we build on both, which is a weaker guarantee than we would like. The reliable move is not to find an unbiased article. It is to take any factual claim that matters to your decision and confirm it at the source.
What if you already chose based on the old information?
Probably nothing, because a working site is a working site and a migration costs real money. If the platform you are on does what you need, the discovery that you chose it for a reason that has since stopped being true is trivia rather than a problem. The time to act is when you are hitting an actual wall, and then the question is whether that wall is still there rather than whether it was there when you decided. Re-check before migrating, because moving a site to escape a limitation that has since been lifted is an expensive way to learn that documentation changes.
