--- title: "Framer CMS Limitations (and How to Work Around Them)" description: "Framer CMS has real limits on collections, filtering, and code access. An honest breakdown of what you'll hit and how to work around each one." canonical_url: "https://framerhub.io/blog/framer-cms-limitations" last_updated: "2026-10-06T00:00:00.000Z" --- 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, and most articles about it either gloss over them or bury them in marketing copy. We build plugins that patch these exact gaps for 1,500+ professionals, 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 most common wall people hit first: **collection and published-page limits tied to your Framer plan**, not 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 isn't a workaround so much as planning ahead: - Check your current plan's page and collection limits at [Framer's pricing page](https://www.framer.com/pricing) 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](https://www.framer.com/help/articles/limiting-the-number-of-visible-cms-items/) on a page — and it exists for a reason. Rendering hundreds of CMS items in a single collection list without pagination slows the page down, especially on mobile. 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 CMS filtering is single-field: you can filter a collection list by one condition — a category tag, a boolean, a single dropdown value. The moment a client asks for "filter by category *and* price range *and* location," native Framer forces you into one of two bad options: 1. **Manual variants** — building a separate design state for every filter combination. This explodes exponentially. Three filters with four options each is 64 variants to maintain. 2. **Skipping the feature** — telling the client it's "not really how Framer works," which is technically true and professionally unsatisfying. Neither scales. This is exactly the gap [CMS Filter](/plugins/framer-cms-filter) closes — realtime search, multi-field filtering (category + tags + price simultaneously), dual-thumb price range sliders, and shareable, SEO-friendly URL parameters for filtered states, all configured from Framer's native panel with zero variant management. It's the #1 CMS filter plugin on the Framer Marketplace for a reason: this is the single most requested feature gap in Framer CMS. If you're building a [directory site](/blog/framer-directory-website-guide), real estate listings, or a job board, budget for this from the start rather than discovering it mid-build. ## 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](https://www.framer.com/help/articles/issues-with-code-components-accessing-the-cms/) — 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. ## 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](/blog/import-csv-to-framer-cms) 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
Limitation Native Framer Workaround
Collection/page caps Plan-tier limit Plan ahead, archive unused items
Large list performance Basic pagination Design pagination pattern early
Multi-field filtering Single condition only CMS Filter
Deep collection relations Shallow reference fields Flatten data model or sync tool
Code component CMS access Timing/exposure limits Use native CMS elements where possible
Bulk import Official CSV Import plugin, with limits Test small, verify reference fields
## 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 after shipping 100+ 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](https://www.framer.com/pricing) 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 [CMS Filter](/plugins/framer-cms-filter) specifically to solve — and it's the limitation most people search for when they land on this page. For the broader CMS setup, our [complete Framer CMS guide](/blog/framer-cms-complete-guide) 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](https://www.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.