Framer CMS List Fields: When and How to Use Them

Repeating content sounds simple until a site owner has to maintain it. A FAQ section with Title 1, Answer 1, Title 2, and Answer 2 may work at launch, but every new row makes the CMS harder to scan, reorder, and hand off. Framer’s CMS List field gives designers and editors a cleaner option: store related rows inside one field, then render them from one repeated design.

Framer introduced the List field on September 8, 2026 for repeating content such as FAQs, product features, tutorial steps, and case studies. The official update says editors can add or reorder rows in a way that resembles a CMS table, while designers can render them with the Repeat property. This guide explains when that structure helps, when numbered fields or a separate collection may still be better, and how to migrate without turning a tidy-up into a broken page. Read Framer’s announcement.

What the Framer CMS List field changes

The practical change is not merely that Framer added another field type. It changes where a repeated group lives. Instead of spreading one logical group across many numbered fields, you can place each row inside a single List field. The editor sees one grouped set that can grow or be reordered without renaming a chain of fields.

On the Canvas, a designer can insert a List that is not yet displayed or select an existing card and use Repeat so that the design is repeated for each row. Framer also says its Agent can convert repeated CMS fields into a List and reconnect the data on the Canvas. That automation is useful, but it should still be treated as a migration that deserves review.

The main benefit is editorial clarity. A person updating a service page can work with a group called “Benefits” instead of decoding Benefit Title 1, Benefit Description 1, Benefit Title 2, and so on. Reordering also becomes a content task rather than a field-renaming exercise.

Choose the structure by how the content behaves

There is no universal winner. Start with the relationship between the repeated rows, the page that owns them, and the way editors need to reuse them.

Use a List when the rows belong to one parent item

A List is the clearest fit when the rows make sense only in the context of the current CMS item. Examples include the steps inside one tutorial, the outcomes inside one case study, the ingredients inside one recipe, or the questions attached to one service page.

This keeps the editor’s task local: open the parent item, edit the rows, reorder them, and publish the change. It also avoids creating a separate collection merely to hold small supporting records that will never be used elsewhere.

Keep numbered fields only for a fixed, deliberately limited layout

Numbered fields can still be reasonable when the design intentionally allows exactly two or three slots and each slot has a different visual role. A “primary proof point” and a “secondary proof point,” for example, are not interchangeable rows even if their field types look similar.

If editors regularly ask for a fourth slot, need to change the order, or struggle to understand which field controls which card, the structure is signaling that it should become a List.

Use a separate collection when rows need their own identity

A separate collection remains useful when an item needs its own page, URL, filtering, cross-page reuse, independent publishing lifecycle, or relationships with other content. Team members, products, locations, and case studies often deserve that treatment. A List is better for owned sub-content; a collection is better for reusable entities.

A useful test is to ask, “Would this row still be meaningful if the parent page disappeared?” If yes, it may deserve a separate collection. If no, keeping it inside the parent as a List is usually easier for editors.

A practical migration checklist

The safest migration preserves the current page before changing the model. Use this sequence even if Framer’s Agent performs the conversion.

1. Inventory each repeated group. Note the current fields, the maximum number of populated rows, and where each value appears on the Canvas.
2. Define one row shape. List the fields that every row needs, such as title, description, image, label, or link. Do not carry forward fields that exist only because the old model was awkward.
3. Choose the rendering component. Decide which card, accordion item, feature row, or step design should repeat for every list item.
4. Convert a copy first. Framer says the Agent can convert repeated fields and reconnect Canvas data. Review the resulting field structure and every connection before changing the production version.
5. Check order and incomplete rows. Confirm that the new List preserves the intended sequence and that partially filled legacy slots did not become empty visible items.
6. Test content extremes. Add a short row, a long row, and the largest realistic number of rows. Verify wrapping, spacing, images, buttons, and accordion behavior at every breakpoint.
7. Review editor instructions. Rename the List and its nested fields in plain language, then document what belongs in each row and which fields are optional.
8. Publish only after comparing the migrated page with the current live page. Confirm that URLs, parent items, and unrelated CMS views were not changed.

What to test on the Canvas

A clean CMS model can still produce a poor page if the repeated design does not handle real content. Inspect the component at desktop, tablet, and mobile widths. Look for headings that wrap into buttons, images that crop important details, cards with uneven heights, and layouts that assume every row has the same amount of copy.

If the repeated block includes an interaction, test every state. An accordion should open and close predictably; a carousel should remain usable with one item and many items; a linked card should have a clear target. Also verify the empty state. If a List has no rows, the page should not leave an unexplained heading or blank gap.

Make the editor experience part of the design

The strongest reason to adopt a List is often not visual. It is the reduction in cognitive load for the person maintaining the site. Use field names that describe content rather than layout, keep the row shape consistent, and avoid nesting data simply because the CMS allows it.

For a handoff, show the editor three things: how to add a row, how to reorder it, and how the row appears on the page. That short explanation is more useful than a long technical document and makes it easier to spot when the content has outgrown the current model.

When a Framer specialist can help

If you are restructuring a live Framer CMS, the risky part is usually not creating the field. It is preserving content, reconnecting the Canvas, and testing every repeated layout across breakpoints. Nexio Studio’s Framer development service can help audit the model, migrate the repeated content, and verify the finished page. Start a conversation if you want a second set of eyes before the change goes live.

The simple rule

Use a List when several interchangeable rows belong to one CMS item. Keep numbered fields when the slots are intentionally fixed and visually different. Use a separate collection when the rows need to be reused, filtered, linked, or published on their own. That decision keeps the CMS understandable for editors and the Canvas easier to maintain.