Framer looks fantastic in a demo. The animations are smooth, the editor feels like Figma, and a designer can ship a beautiful landing page faster than they could in almost any other tool. The problem isn't the demo — the problem is what happens six months in, when the marketing site needs to scale, when SEO actually starts to matter, and when the technical limits of the tool start to compound. We've seen enough Framer-based SaaS marketing sites at the recovery stage to write a clear opinion: Framer is the wrong choice for a SaaS marketing site you plan to grow, and the reasons aren't visible until you're already locked in.
[Insert diagram: a maturity curve showing the lifecycle of a SaaS marketing site — early validation (Framer works), MVP launch (Framer still fine), 6 months in / scaling content (Framer starts cracking), 18 months in / programmatic SEO (Framer is the bottleneck). Annotations show which technical limits show up at each stage.]
This isn't an argument that Framer is bad software. It's a great visual design tool. The mismatch is specifically between what Framer is good at (visually rich, mostly-static pages) and what a SaaS marketing site needs to be (a technical SEO surface that scales to hundreds of pages, supports a serious CMS workflow, and renders cleanly in AI search). The same gap exists between Framer and Webflow as the underlying website builder choice — but this post goes deeper on the specific technical problems with Framer that the comparison post can't cover in depth.
If you're a SaaS founder evaluating Framer right now, here are the six issues to know before committing.
The "cotton candy" framing — why Framer is so appealing
The Framer pitch is real. The editor is closer to Figma than any other website builder, which means designer-founders can build sites without learning Webflow's class system. Animations and interactions are click-and-loop instead of multi-step setups. The output looks polished out of the box. For a designer who wants to ship a site this week, Framer feels like a superpower.
The trap is that Framer optimizes for the first impression, not for the long game. There's a phrase that captures it: Framer is the cotton candy of website builders. The first bite is delicious — fluffy, sweet, immediate dopamine. It doesn't sustain you. It's not a meal. Steak and potatoes (Webflow, custom code) take longer to prepare and the first bite isn't as exciting, but they're what you need if you're sitting down for a real meal.
The cotton-candy effect explains why designer-founders specifically gravitate to Framer: the design quality at the moment of evaluation is exceptional, and the design quality is what they care about most. They don't yet have the operational experience to know what the site will need to do six months in. By the time they find out, the site is built, the team knows Framer, and the cost of migration is steep.
The six technical problems below are what shows up after the cotton-candy phase wears off.
Problem 1 — REM support is broken
This one is in the weeds but it matters a lot. Modern web development uses rem units for sizing — relative units that scale with the user's base font size. REM is the accessibility standard. It's what every browser dev tool teaches. It's what every reasonable design system enforces. Pixels are the legacy alternative, and they don't scale for users who've increased their font size for readability.
Framer supports REM only on text. Spacing, margins, dimensions — all in pixels by default. There's no way to define spacing scales in REM units the way you would in Tailwind, Webflow, or hand-rolled CSS. The downstream effect is that Framer sites don't respect user font-size preferences for layout, only for typography. Accessibility tools fail in subtle ways. Some users on assistive tech can't read the site comfortably.
Webflow supports REM throughout. Custom code with Tailwind supports REM throughout. Wix and Figma sites have the same limitation as Framer (REM only on text, sometimes not even there). This isn't a niche concern — it's a baseline accessibility expectation that Framer doesn't meet.
Problem 2 — CSS variables aren't preserved in the output
If you set a color or spacing variable in Framer's editor, the variable exists in the editor's data model — but it doesn't survive to the rendered HTML/CSS as a CSS custom property. The compiled output has the raw color values inlined into the elements directly.
Why does this matter? CSS variables are how modern sites theme consistently, switch between light/dark modes cleanly, and let designers update one value to propagate across the entire site. Without them in the output, every color change has to be re-rendered by Framer's compiler against every element that uses the value. The site author can still update colors in the editor — but third-party themers, analytics tools that want to inherit brand colors, browser extensions, and any external integration that expects standard CSS variables breaks.
This is the kind of issue you don't notice until you try to do something specific (run a brand refresh, integrate a third-party widget, build a dark mode), and then you discover you can't.
Problem 3 — Class inheritance doesn't work
This is the biggest structural issue. In every reasonable web stack — Webflow, Tailwind, hand-rolled CSS, even old-school Bootstrap — you build with classes that inherit. A heading-1 class gets style X. A heading-1-large class extends heading-1 and adds Y. Change heading-1 and all the variants inherit the change.
Framer doesn't have meaningful class inheritance. Every element gets its styles set individually. The "class" concept in Framer is more like a saved style preset that you apply once — there's no parent-child cascade. If you have fifty pages with heading styles and you want to change them all, you can't change one parent style and have the children inherit. You have to update each one or use Framer's component system, which has its own limitations.
This is a hard ceiling on scale. A small site with twenty pages is manageable. A SaaS marketing site that wants to ship a hundred programmatic SEO pages, fifty blog posts, twenty product pages, and a comparison page library is going to struggle. Webflow's class system is one of the reasons SaaS teams pick it: you can build a real design system that scales across content surfaces. Framer doesn't offer that.
Problem 4 — Margin isn't a first-class concept
Most web layouts use a combination of padding (inside the element) and margin (outside the element, between elements). Framer's layout engine is built around padding and absolute positioning — margin support is limited and inconsistent. Designers coming from Figma often don't notice because Figma also doesn't have margin as a primary concept (it has "auto-layout spacing" which behaves somewhat like padding).
The problem shows up when you're building responsive layouts that need to flow correctly across breakpoints. Margin is what gives you predictable vertical rhythm between elements. Without it, designers tend to wrap elements in extra containers with padding, which inflates the markup and makes the site harder to maintain.
This is a smaller issue than the class inheritance problem, but it's part of the pattern: Framer's primitives are optimized for visual design tools, not for the underlying HTML/CSS conventions that scale.
Problem 5 — Programmatic SEO is structurally limited
The strongest SEO play for a SaaS marketing site at scale is programmatic content — generating hundreds or thousands of pages from a database with a consistent template. Comparison pages, integration pages, alternative-to pages, location pages, use-case pages. The teams that do this well (like the founder who shipped 24,000 SEO pages we mentioned in our Claude Code Skills post) compound the SEO over time.
Framer's CMS supports basic templated pages, but the workflow for programmatic SEO at scale is awkward. The CMS doesn't have rich enough relations to support nested data structures. The page templates are limited compared to Webflow's CMS. Bulk import workflows are clunky. The result is that teams trying to do serious programmatic SEO on Framer either give up or migrate to a stack that supports it (Webflow, or Next.js + a headless CMS like Sanity).
This connects directly to the competitor comparison page strategy — if you want to ship one alternative-to page per competitor, ten or fifteen comparison pages, and a programmatic library of integration pages, Framer's CMS is going to be the bottleneck. The work is technically possible but the iteration speed is poor.
Problem 6 — Heading hierarchy bias
This one shows up in real-world Framer sites all the time. Framer's text components default to specific semantic levels based on the visual style preset the designer picks. Pick "Headline 1" style and you ship <h1> whether you wanted that semantic level or not. We covered the deeper SEO impact of this in H1, H2, H3 for SEO: Why Most SaaS Sites Get Heading Hierarchy Wrong — broken heading hierarchy hurts SEO rankings, AI search citations, and accessibility.
Framer does let you override the semantic level independently of the visual style. But the override is buried in a property panel that designers rarely touch. The default behavior produces broken hierarchy — multiple H1s on a page, H4s after H2s with H3 skipped, decorative H1s in shared components. If you're on Framer, this is a per-page audit you have to run repeatedly. Webflow has its own version of this issue but the audit surfaces it more clearly; custom code gives you full control.
When Framer IS the right choice
For honesty: Framer has real fits.
Portfolio sites for designers and creative agencies. The visual flair and ease of building beautiful one-off pages is exactly what portfolio work needs. The site has 10-20 pages, no programmatic SEO ambition, and the designer is the only person maintaining it. Framer is great.
Validation pages for early-stage products. You're testing whether the messaging resonates before you commit to a real marketing site. Spin up a Framer landing page, run ads to it, measure conversion. When you find the version that works, then migrate to a real stack for the production marketing site. The cost of building in Framer is low and the throwaway-ability is a feature, not a bug.
Single-purpose campaign pages. A product launch, an event registration, an interactive demo. These don't need the long-term SEO surface that the main marketing site needs. Framer's polish wins here.
Designer-led teams without dev support, with simple SEO needs. If your team is mostly designers, you don't expect to ship a lot of content, and your SEO strategy is "rank for our brand name and get traffic from social and direct," Framer can work indefinitely. The technical limits don't bite hard when your content surface is small.
The pattern across these fits: short-horizon, low-page-count, design-first. Framer optimizes for those exact conditions. The mismatch is when teams use Framer for the opposite scenario — long-horizon, scaling page count, SEO-first.
How to migrate off Framer (when you're ready)
If you're already on Framer and the technical limits are starting to bite, the migration path is well-trodden. The usual destination is Webflow (closer paradigm shift, easier transition) or Next.js + a headless CMS like Sanity (more flexibility, harder transition). The work is real but manageable:
- Export your content from Framer's CMS. Framer supports JSON export of CMS collections. Get a clean dump of all your content.
- Rebuild the design system in the target stack. This is the time-consuming step. Don't try to migrate visuals 1:1 — use the migration as an opportunity to clean up the design system.
- Set up the URL redirects. Every Framer URL needs a redirect to the new URL to preserve SEO. This is critical and often overlooked.
- Re-launch and monitor. Search rankings will dip for 2-4 weeks during the transition as crawlers re-index. Expect it; don't panic.
We've helped several clients through this migration. The work is finite; the long-term payoff is substantial.
Frequently asked questions
"What about Framer Sites' new AI features?"
Framer keeps shipping AI-assisted features — design suggestions, content generation, layout automation. These are nice additions to the editor, but they don't address the underlying technical limits in the rendered output. Better AI in the editor doesn't make REM support work or unlock class inheritance. The structural issues live below the AI layer.
"Is Webflow's class system actually better?"
For SaaS marketing sites at scale, yes — meaningfully. Webflow's classes inherit, can be combined (button + button--primary adds the primary modifier), and act as a real design system primitive. The learning curve is steeper than Framer's, but the ceiling is much higher. Most CF clients building serious marketing sites are on Webflow or custom code for exactly this reason.
"What about Figma Sites?"
Worse than Framer for SaaS marketing use cases. Figma Sites is a brand-new product, REM support is even more limited, the CMS isn't there yet, and the SEO tools are minimal. It's fine for brand-guidelines microsites where the audience is internal team members. It's not ready for production marketing sites.
"Is custom code (Next.js + a CMS) better than Webflow?"
Different trade-offs. Custom code gives you full control over technical SEO, scalability, and infrastructure — but the framework choice matters. React-based frameworks like Next.js can ship with SEO problems if not configured carefully (server-side rendering vs static generation, metadata handling, sitemap generation). Webflow gives you 80% of the technical SEO benefits with much less developer effort. The right choice depends on your team's composition. We covered this in detail in our Best Website Builder for SaaS Marketing Sites post.
"How much SEO traffic will I actually lose by being on Framer?"
Hard to quantify without auditing your specific site, but the patterns we see: Framer sites tend to have 30-60% fewer ranking keywords than equivalent Webflow sites in the same category, primarily because the heading hierarchy issues and programmatic SEO limits compound. AI search citations also suffer — the LLM crawlers prefer structured content with clean semantic hierarchy, which Framer makes harder to produce consistently.
"When should I plan to migrate off Framer?"
The trigger is one of: (a) you're hitting a ceiling on the number of pages you can manage in Framer's CMS, (b) you're losing organic traffic and your SEO audit shows technical issues you can't fix in Framer, (c) you're planning a programmatic SEO investment that Framer can't support, or (d) your team is growing and the lack of class inheritance is making design system maintenance expensive. If any of these apply, the migration is worth planning now. Doing it under pressure (after traffic has already declined or after the team is already frustrated) is more expensive than doing it deliberately.
