Why a custom Webflow CMS breaks at scale
Webflow CMS handles the first few dozen entries well: collections, reference and multi-reference relationships, filters on template pages.
Problems don't start at the beginning, but when the content model outgrows the original design — when there are more than ten collections, and second- and third-level relationships appear between them.
The first typical failure is field desynchronization. A field was renamed or its type changed in one collection, but templates, nested lists, and filters that referenced it keep pulling the old value.
On the surface the page is alive, but some cards render empty, and filtering conditions silently stop triggering.
The second is duplicates and "dangling" entries. When content is moved manually between collections and when imported via CSV, the same entity gets created twice, and relationships point to the outdated copy.
CMS constraints don't flag this as an error: a broken reference simply doesn't render, and it can only be noticed by spot-checking pages.
The third is manual edits that don't survive a structure update. If a content editor fixed text directly in an entry, and then the collection structure was rebuilt for a new section, some of the edits are lost when fields are overwritten.
At content scale, this turns into regular reconciliation of "what it was before and what it became after" — manual and without guarantees.
Next, we break down how this is closed: a collection schema with headroom for growth, relationship rules, and checks that catch desynchronization before publication, not after.
What a well-designed collection structure delivers
The structure of collections in Webflow CMS is essentially the project's data schema: which entities exist, how they reference each other, and which fields are required.
If it was designed before content was added, an editor publishes a piece in minutes; if it was "built up as you go," every edit turns into manual synchronization of a dozen cards.
The key effect is the share of manual operations. When relationships between collections are defined through reference fields rather than by duplicating text, a change to an author or category is pulled into all cards automatically.
In practice, this eliminates 60–80% of manual edits during bulk updates and closes an entire class of failures: mismatched names, broken links, duplicate entries.
The second effect is publishing speed and onboarding. A clear schema with meaningful field names and hints lets a new editor reach independent work in one or two days instead of a week: they see where to enter what, and they can't accidentally break the layout.
The third is data integrity. Required fields, type constraints, and a single source for recurring entities prevent the accumulation of "junk" that later has to be cleaned up manually.
We design the schema so that it can withstand growth: adding a new page type does not require rebuilding existing collections.
Implementation options: native CMS, custom fields, external source
The choice of approach is determined by three parameters: how many entity types are in the model, how complex the relationships between them are, and who will be editing the content.
A native CMS covers most tasks without code, but runs into limits on the number of collections and fields. Custom fields extend the model as long as the logic fits within validation rules.
An external source is needed when data lives in another system and must remain the single source of truth there.
| Option | When it fits | Limitations of the approach |
|---|---|---|
| Native CMS | A catalog, blog, or reference with a predictable structure and one-to-many relationships | Hard limits on the number of collections and fields, no computed values or conditional logic |
| Custom fields and relationships | Composite types, cross-references, or a different set of fields per category are needed | Model complexity grows: the editor needs instructions, and development needs a change management policy |
| External data source | Content is already managed in another system, and real-time filtered queries are needed | Dependence on the availability and schema of the external service, caching and failure handling on our side |
In practice, approaches are combined: static sections are kept on the native CMS, dynamic data is pulled from an external source, and custom fields are added only where the model breaks down without them.
This separation reduces the number of edits as the catalog grows and leaves the editor with a clear interface.
We define the boundaries of each option before the start: which entities will remain in the CMS, what will move to an external source, and where custom logic will be required.
This eliminates rework at the content population stage, when changing the architecture is most expensive.
How we design and implement custom collections
We start the design with the content model: we analyze which entities live in the system, who creates them, and by what rules they are connected.
At this stage we lock down the relationship schema — one-to-many, reference lists, nested collections — because reworking the structure after it has been populated is more expensive than pausing for approval.
- Analyzing the content model. We list the entities, their attributes, and their lifecycle: what is created manually, what is pulled from a reference list, what is computed. The output is a map of fields with types and required status.
- Relationship schema. We determine how collections reference each other, where intermediate tables are needed, and where a reference field is sufficient. We check that the structure will withstand growth: adding a section does not break existing relationships.
- Setting up fields and roles. We create fields for each content type and configure access for editors, authors, and moderators. Role-level restrictions eliminate the class of errors where content is edited by someone who shouldn't be editing it.
- Data migration. We transfer existing content from the old system: we clean up duplicates, normalize the markup, and map old fields to new ones. We run the migration on a copy and compare the number of records and relationships before and after.
- Testing editor scenarios. We walk the path from creating a record to publishing: draft, preview, rollback, updating related blocks. This is where non-obvious field conflicts surface that aren't visible on an empty database.
- Load testing. We observe how lists and filters behave on a real volume of content, not on ten test records.
- Project handover. We deliver the collection schema, role descriptions, an instruction manual for editors, and a regulation for adding new fields — so the client's team can evolve the structure without us.
Each step ends with an artifact: a model map, a relationship schema, configured roles, a migration report. This way, at handover the client is left not with "it kind of works" but with a documented structure that can be extended.
What you keep after project handover
The project is handed over not as "account access," but as a complete package your team can keep working with without us. Below is exactly what we transfer for each Webflow CMS project.
- Collection schema — a map of all CMS collections with the purpose of each, the relationships between them (reference and multi-reference), and the nesting logic. It shows why content lives where it does and what happens when a new entry is added.
- Field descriptions — a table for each collection: field name, type, whether it is required, allowed values, default. Fields that cannot be renamed without editing templates are marked separately.
- Relationship rules — which collections reference each other, where a relationship is required and where it is optional, and how this is reflected on template pages.
- Access roles — a permissions matrix: who edits content, who manages collections, who publishes. Separate roles are configured for editors so they cannot break the structure.
- Publishing policy — the order in which edits go to production: draft → review → publish, what to do on rollback, and how changes are coordinated between editors.
- Editor guide — a step-by-step document with screenshots: how to add an entry, fill in fields, link relationships, queue it, and publish. Designed for someone without a technical background.
- Template map — which pages are assembled from which collections and fields, so that editing content does not require editing the layout.
All of this consists of living documents in your repository, not a one-off file. When the collection structure changes, we update the schema and field descriptions in the same commit, so the documentation does not drift from reality a month after launch.
Case study: rebuilding a catalog with 40 relations without stopping publications
The client is an industrial supplier with a catalog built on 40 relations between collections: a product referenced a category, a category referenced a series, a series referenced documents and analogs.
The catalog ran on Webflow CMS, and every structural edit turned into a manual pass through hundreds of cards: relations broke, publishing took hours, and after an update you had to manually verify whether cross-references had fallen off.
What it was before
Publishing a single item took an average of 40 minutes: the content manager edited the card, manually re-linked related records, and checked that links didn't lead nowhere.
When the collection structure changed, the error rate reached a third of all edits — some relations remained broken, and that was discovered already in prod.
What we changed
We rebuilt the relations model: moved repeating entities into separate collections, set up reference fields instead of duplicating text, and added integrity checks at the build stage.
Publishing no longer depended on manual re-linking — relations are pulled in automatically, and mismatches are filtered out before deployment.
What it became
| Metric | Before | After |
|---|---|---|
| Item publishing time | ~40 minutes | 5-7 minutes |
| Manual edits per item | 12-15 | 2-3 |
| Error rate when changing structure | ~30% | isolated cases |
Publications didn't stop for a single day: the rebuild was done in parts, old and new relations worked in parallel until the catalog fully transitioned.
Rollback to the previous scheme remained available at every step — if the checks had revealed a problem, we would have returned to the previous structure without data loss.
How a custom collection differs from a single entity
A custom collection is a separate content type with its own field schema, while a single entity is a record inside an existing collection.
The difference shows up not in the editor, but in how the data fits into the structure: one large collection with a dozen optional fields quickly turns into a dumping ground where half the attributes are empty for most records, and filters and sorting operate on sparse values.
When content differs in how often it changes, it is moved into related collections.
A reference list of cities or categories changes once a quarter, while product cards change daily; keeping them in a single entity means reindexing the entire set every time the reference list is edited.
A relationship via a reference field allows the reference list to be updated in a targeted way, while querying by the relationship remains predictable.
Access rights are the second criterion. If content editors and the owners of the reference list are different people, it is difficult to delineate roles within a single collection: rights are granted for the collection as a whole, not for individual fields.
Splitting into related collections gives a clean role model: one group edits records, another only reference values, and no one touches someone else's schema.
A practical rule: if an entity has more than two or three fields that are filled in rarely and only by part of the records, or if it is edited by a separate role — move it into a custom collection and link it.
If the fields are homogeneous and change in a single stream — keep it as a single entity; an extra relationship will add queries on output without any gain in structure.
Technical concerns before starting work
Content migration is the first thing asked about before starting. We collect a map of the current entities in advance: what record types exist now, how they relate to each other, where the duplicates and "junk" fields are.
Then we lay them out across CMS collections and configure the relationships between them so the structure can withstand catalog growth instead of turning into a flat list of hundreds of records. We preserve old URLs through redirect rules — search traffic and external links are not lost.
What are the platform's limitations and what can be done about them?
Every platform has a ceiling: limits on the number of records, link nesting depth, media volume, and API request frequency. We check these boundaries at the schema design stage, not after launch.
If a task hits a limit, we move part of the logic to an external layer — the platform remains the storefront, while heavy operations go beyond it.
How do we separate editor roles?
We configure roles according to actual responsibilities: a content editor edits texts and media but does not touch the collection structure; a senior editor manages relationships and publishing; an administrator is responsible for the schema and access.
We grant permissions on the principle of least privilege — an accidental template edit will not break the layout of the entire site.
What about support after launch?
After handover, a protocol remains: how to add new fields, how to roll out changes without downtime, whom to contact in case of failure. We document this and hand it over to the client's team — the site lives on without the contractor's constant involvement.
What are the risks of migration?
The main risks are loss of relationships between records and broken URLs. We mitigate them as follows: first we migrate the structure and relationships to a test environment, verify the number and integrity of records, and only then switch the production domain. Rollback to the previous version remains possible right up to the moment of switching.
Let's discuss your content model and come back with a plan
To come back with an implementation plan rather than generalities, we need your current picture: what content types already exist, how they relate to each other, and what prevents the editorial team from working without a developer.
Describe the task in free form — a list of pages, reference directories, repeating blocks, and access roles. That is enough to estimate the scope and spot weak points in the structure.
Next, we build a relationship diagram: which collections become sources, which ones reference them, where reference directories and filters are needed, and where static fields will suffice.
Based on this diagram, we estimate the scope of work and the rollout order — what we migrate first, and what can be rolled out later without taking the site down.
- Analysis of the current content structure and the points where the editorial team is stuck with manual editing
- A collection relationship diagram: sources, references, reference directories, filtering rules
- A scope estimate: how many collections, fields, and templates will need to be built
- A phased implementation plan with a clear result at each stage
- The order of data migration and a check that old page URLs are not lost
- A role breakdown: what the editor changes on their own, and what remains with the developer
- A list of pre-launch checks and the rollback procedure if something goes wrong
The next step is a short, to-the-point conversation: you show the structure, we ask clarifying questions, and we come back with a scope estimate, a relationship diagram, and an implementation plan. Describe the task — we will come back with specifics.
