Framer CMS Limitations (and How to Work Around Them)

If you've built more than one CMS-driven site in Framer, you've hit a wall. Maybe it was a "you currently have more CMS collections than your plan allows" warning. Maybe it was realizing you can't filter a directory by category and price at the same time. Maybe it was a code component that couldn't read the CMS data you assumed it could.

Framer's CMS is genuinely good for what it's built for: structured content, dynamic pages, and clean editor workflows for non-technical clients. But it has real limitations. We build plugins that patch these exact gaps for 2,000+ Framer users, so we see the pain points daily. Here's the honest rundown, what actually limits you in Framer CMS, and what to do about each one.

1. Plan-Based Collection and Page Caps

The wall people hit first is collection and published-page limits tied to your Framer plan rather than to the CMS itself. Framer's help docs and community forum both confirm that CMS-generated pages count toward your site's total published page limit, so a collection with 400 items can quietly eat your entire page budget on lower tiers.

The fix is planning ahead:

• Check your current plan's page and collection limits at Framer's pricing page before you scope a CMS-heavy project.
• If you're close to the ceiling, archive unused collections or unpublish draft items, they still count if they're live.
• For agencies managing multiple client sites, budget plan tier into your quote up front. This is the single most common surprise we see freelancers hit mid-project.

This one bites experienced builders as often as beginners, because the limit isn't obvious until you're deep into a build. A five-page marketing site with one small collection never gets close. A directory, catalog, or listings site with hundreds of items generates hundreds of dynamic pages behind the scenes, and every one of those counts against your published-page limit, even though you only "built" a handful of templates. If a client's project is going to scale past a few hundred CMS items over its lifetime, price the higher plan tier into the proposal now rather than explaining a surprise upgrade later.

2. Visible Items and Large Collection Performance

Framer has a documented pattern for limiting the number of visible CMS items on a page. In our own builds, rendering hundreds of CMS items in a single collection list without pagination is where mobile page speed starts to suffer. Measure it on the project rather than taking a rule of thumb from an article, including this one.

Native Framer gives you:

• A max item count per collection list
• Basic pagination (previous/next)

What it doesn't give you natively: infinite scroll with lazy loading, "load more" patterns tied to filter state, or numbered pagination that stays SEO-crawlable while filtered. If your directory, blog, or product catalog is going to grow past a couple hundred items, plan the pagination pattern before you build the layout, retrofitting it later means rebuilding your list component.

3. The Real Limitation: Filtering

This is the one that actually changes what you can ship. Framer's native Dynamic Filters bind a search field, a dropdown, a checkbox group or a set of tabs to a page variable, and for one condition at a time that is a perfectly good baseline. The moment a client asks for category and price range and location together, with chips a user can remove and a result count next to them, you are past what the native model expresses, and the fallback, a design variant per filter combination, explodes exponentially (three filters with four options each is 64 states to maintain). Filtering is a big enough subject to have its own article: walks through the native setup step by step and marks the exact point it runs out.

4. Collection Relations Are Shallow

Framer supports reference fields, linking one collection item to another (a blog post referencing an author, a product referencing a category). What it doesn't do well is deep or many-to-many relations. A single reference field points to one collection. If you need a product that belongs to multiple categories, or a project that references multiple team members with per-relation metadata, you're working around the data model rather than with it, usually by duplicating reference fields or flattening relations into tag-style multi-select fields.

Workaround: model your content as flat as possible before you build. If a relation genuinely needs to be many-to-many with extra metadata, a plugin-level or external-database approach (like a lightweight Airtable or Notion sync) will save you more time than fighting Framer's native reference fields.

5. Code Components Have Restricted CMS Access

Code components can read CMS data, but not with the same freedom you'd get in a typical headless CMS setup. There are documented limitations when accessing the CMS with code, timing issues between what's available at design-time in Framer's canvas versus what's actually rendered on the live site, and gaps in what collection metadata is exposed to a component versus a native CMS list element.

Practically, this means:

• Simple "pull this collection and render cards" logic works fine with a code component.
• Cross-collection filtering, search, or sort logic inside a code component gets fragile fast, you're fighting the same constraints a plugin author has already solved for.

If you're building something that needs to manipulate CMS data programmatically beyond basic display, it's worth understanding what Framer's plugin and CMS APIs actually expose before you invest engineering time in a custom component. Our covers both surfaces and what each one permits.

6. Bulk Import and Field-Type Gaps

Getting existing content into Framer CMS used to be a real pain point. Framer now ships an official CSV Import plugin (with a companion CMS Export plugin for the reverse direction), which covers most bulk-migration needs. It's not without limits, though: reference fields between collections don't always resolve automatically on import, image fields expect a public URL rather than an uploaded file, and very large datasets still run into the plan-tier collection caps covered above. See our CSV import walkthrough for the full step-by-step process and the gotchas that actually trip people up.

Certain field types also have narrower configuration options than dedicated CMS platforms offer, structured video fields are a common example. If you're migrating an existing catalog, listings database, or blog archive into Framer, plan the import path before you plan the design. It's the part of the project most likely to blow your timeline if you leave it for last.

The same applies to media-heavy fields. If a client wants embedded video per CMS item, property walkthroughs, product demos, testimonial clips, the configuration options on native video fields are narrower than what a dedicated video CMS gives you. Test the exact field type with real client content early, not with placeholder data, so you find configuration gaps while there's still time to route around them.

7. What Actually Solves Each Limitation

Two honest notes on that last column. CMS Filter is our product, so read the filtering rows with that in mind, the native baseline is real and worth using first. And CMS Find & Replace works on plain text, rich text and link fields only; it leaves slugs alone and runs one collection at a time.

8. Search Doesn't Scale Past a Handful of Fields

Framer's native CMS search, where it exists on a collection list, typically matches against a single text field, usually the title. That's fine for a blog. It breaks down fast for a directory where a user expects to search across title, description, category, and location in one query. There's no native fuzzy matching, no relevance ranking, and no debounced realtime results as you type; you get exact or partial string matches against whatever field you wired up, evaluated on every keystroke without any performance guardrails.

For small collections (under 50 items) this is barely noticeable. Past a few hundred items, unoptimized search starts to feel sluggish, and users bail before results resolve. If search quality is core to the product, a job board, a marketplace, a resource directory, this is a second angle on the same underlying gap as filtering: Framer's CMS list component wasn't built for compound queries. Realtime, debounced, multi-field search is one of the reasons directory builders reach for CMS Filter alongside the filter and sort controls, rather than trying to patch native search with a code override.

9. Choosing a Plan Tier for CMS-Heavy Sites

Because so many of these limitations trace back to plan tier, page counts, collection counts, item visibility, it's worth treating "which Framer plan" as a scoping decision, not an afterthought you handle at checkout. A few practical rules we've settled on scoping CMS-heavy client sites:

• Estimate final item count, not launch-day item count. A real estate site launching with 20 listings will have 200 within a year if it's working. Price the plan for where the collection is headed, not where it starts.
• Count CMS-generated pages separately from static pages. A blog with 300 posts and five marketing pages needs headroom for 305+ published pages, not five.
• Re-check limits before every major re-scope. Framer's plan tiers and included limits change over time, what applied when you built the site a year ago may not match current allowances. Confirm against the live pricing page rather than working from memory or an old quote.
• Build the filtering and search layer assuming growth. If you're adding CMS Filter for a 30-item collection today, you're not over-engineering, you're avoiding a rebuild when it's 300 items in a year.

None of this is unique to Framer. Every hosted CMS platform ties some capability to a plan tier. The difference is that Framer's limits are less visible upfront than, say, a headless CMS's published API docs, you tend to discover them mid-build rather than during initial research. Scoping conversations with clients that explicitly name "collection growth" as a variable will save you the awkward mid-project upgrade conversation almost every time.

The Bottom Line

None of these limitations mean Framer CMS is a bad choice, for the vast majority of marketing sites, blogs, and portfolios, you'll never hit most of them. They matter when you're building something with real data density: directories, listings, catalogs, job boards. Know the walls before you scope the project, not after the client demo.

If filtering is the wall you're hitting, that's the one we built specifically to solve, and it's the limitation most people search for when they land on this page. For the broader CMS setup, our covers collections, fields, and dynamic pages from scratch.

FAQ

Does Framer CMS have a hard limit on collections? Framer limits collections and published pages based on your plan tier, not a universal cap. If you see a "you currently have more CMS collections than your plan allows" warning, check framer.com/pricing for your tier's current limit or archive collections you no longer need.

Why can't I filter by more than one field in Framer CMS? Native Framer CMS lists support a single active filter condition. Combining filters (category + price + location) requires either manual variant states, which don't scale, or a plugin like CMS Filter.

Can I limit how many CMS items show on a page? Yes, Framer supports item limits and basic pagination on CMS-connected lists, which helps performance on large collections. It doesn't add filter chips, sort controls, or shareable filtered URLs on top of that.

Can code components read Framer CMS data directly? Code components can access CMS data, but with real constraints around what's exposed at build time versus render time. For filtering, search, or cross-collection logic, a purpose-built plugin is more reliable than a custom component.

Is Framer CMS good enough for a directory or listings site? The data model works well for directories, real estate listings, and job boards. The actual gap is filtering, multi-field search, price ranges, and shareable filtered URLs aren't native, which is exactly what CMS Filter adds.