How Do You Build a Pricing Page in Webflow That Updates Itself?

How Do You Build a Pricing Page in Webflow That Updates Itself?

Move the plans and the features into CMS Collections, then bind the page to those Collections instead of typing prices into the Designer. After that a price change is an edit in the Editor, not a design ticket. The build takes a day and it saves that back within a quarter.

Pricing pages are the most edited page on most B2B sites and the one least able to handle editing. They are usually three hand-built columns with the numbers typed in, which means every change needs someone with Designer access and every change risks breaking a layout.

Here is the structure we use, the field types it needs, and the parts that bite.

Why Should Pricing Live in the CMS at All?

Because pricing changes more often than design does, and the two should not be coupled. When a price is typed into a static text block, changing it requires opening the Designer, finding the right element, editing, and publishing the whole site. That is four chances to break something unrelated.

There is a second benefit that matters more over time. Once plans are structured data, you can reuse them. The same Collection can feed your pricing page, a comparison page, a plan picker inside a modal, and a plain text pricing file for AI agents, all from one source of truth.

The third reason is audit. A Collection item has a last-updated timestamp and a clear history of what changed. A text block has neither, which is how sites end up with a price on the homepage that nobody noticed was three months out of date.

How Should You Model Plans and Features?

Two Collections, joined by a reference. Plans holds one item per tier. Features holds one item per capability. Then each plan references the features it includes, which is what lets you build a comparison grid without hand-maintaining a matrix.

The instinct to use one Collection with a long list of checkbox fields is the trap. It works until you add a feature, at which point you are editing the Collection schema and the design rather than adding a row of content. Adding a feature should be adding an item.

Collection	One item is	Key fields
Plans	A pricing tier	Name, monthly price, annual price, summary, CTA link, order, highlighted switch
Features	A capability	Name, short description, category, order
Plan features	A feature as it applies to a plan	Reference to plan, reference to feature, value or limit, included switch

That third Collection is optional and it is the one that separates a good model from a workable one. If a feature is simply included or not, a multi-reference from the plan is enough. If a feature has a different limit per plan, such as seats or API calls, you need somewhere to store that value, and the join Collection is where it goes.

Which Field Types Do You Actually Need?

Fewer than you think, and the names matter because they are what the API expects. Webflow's field types reference documents PlainText, RichText, Number, Switch, Option, Link, Image, Date, Color, and the two relationship types, Reference and MultiReference. That list is the whole vocabulary you need here.

Use Number for prices rather than PlainText, even though PlainText is easier. A number can be formatted, compared, and sorted. A price stored as text becomes a string like 49 per month that you cannot do anything with later, including generating an annual figure.

Use Switch for the yes or no properties: whether a plan is highlighted, whether it is public, whether a feature is included. Use Option for anything with a fixed set of values, such as a billing interval or a plan category, so editors pick rather than type.

How Do Reference Fields Work in Webflow?

A Reference field points one item at one item in another Collection. A MultiReference points at several. Webflow's API documentation shows the shape: a Reference field is created with a type of Reference and a metadata object containing the collectionId of the Collection it points to, and the value is the referenced item's ID as a string.

MultiReference works the same way, with the target Collection's collectionId in metadata, and values written as an array of item ID strings. Option fields are slightly different again: each option gets a unique id, and to set one you retrieve that id and pass it as a string.

Those details only matter if you are writing to the CMS through the API, but they are worth knowing before you design the model, because they tell you what is cheap to change later. Our guide to Webflow reference fields goes through the Designer side.

How Do You Handle a Monthly and Annual Toggle?

Store both prices as separate Number fields on the plan and switch between them in the browser. Do not try to calculate the annual price from the monthly one, because real pricing almost never divides cleanly and the discount is a marketing decision, not arithmetic.

Render both values into the page, hide one, and let a small script swap which is visible when the toggle changes. Both numbers are then present in the HTML, which matters for search engines and for AI answer engines that do not run your JavaScript.

Add a third field for the annual saving if you want to display it, and let the editor type the number. It is tempting to compute it, and then a plan has a promotional annual rate and the computed figure is quietly wrong on the page nobody rereads.

How Do You Build the Comparison Grid?

Nest a Collection list of features inside your plan list, or the reverse, depending on which axis you want to control. The pattern that survives edits best is rows of features, with a small Collection list inside each row rendering the value for each plan.

Use conditional visibility to change what a cell shows. A tick when the included switch is on, the limit text when a value exists, and a dash when neither applies. That way a feature with different limits per plan and a feature that is simply included or not use the same markup.

Keep the mobile version in mind while you build it, not after. A six-column grid is unreadable on a phone, and the usual answer is stacking by plan rather than by feature. Our notes on Webflow conditional visibility cover the rules available.

Can You Update Pricing From Another System?

Yes, and it is worth doing if pricing already lives somewhere authoritative. The Webflow Data API can write Collection items, so a change in your billing system or a finance spreadsheet can push into the CMS rather than waiting for a person to retype it.

You can also listen in the other direction. Webflow's webhook trigger types include collection_item_changed and collection_item_published, which means a price edit can notify Slack, update a pricing file, or kick off a rebuild somewhere else. Webflow retries a failed delivery three times at ten minute intervals, so your endpoint needs to be reliable.

Our honest advice is to add this only when a second system genuinely owns the numbers. If marketing decides pricing, marketing editing the CMS directly is simpler and has fewer moving parts than a sync nobody maintains.

What Breaks When You Do This?

Three things, all predictable. Editors publish a half-finished plan because Collection items go live when published, so add a public switch and filter your list on it. Ordering drifts, because Collection lists sort by whatever you told them to, so add an explicit order number field rather than relying on creation date.

The third is the one that catches everyone. Deleting a feature that is referenced by plans leaves gaps, and Webflow will stop you deleting fields that are in use on your site. Plan for retiring a feature by switching it off rather than deleting it, and your comparison grid stays intact.

There is also a design risk. A CMS-driven grid renders whatever the data says, including a plan name three times longer than the column allows. Test with the worst realistic content, not the content you have today. Our piece on pricing page design covers the layout side.

Would We Always Recommend It?

No. If you have three plans, two prices, and pricing changes once a year, hand-built is fine and faster to ship. The CMS approach earns its keep when you have more than about four tiers, feature lists that change, or more than one page showing the same numbers.

The tipping point in practice is usually the second page. The moment pricing appears on both the pricing page and a comparison page, the duplicate is going to drift, and drifting prices are the kind of error that reaches a customer before it reaches you.

If you want a second opinion on whether your pricing page is worth restructuring, we are happy to look at it with you. We build these for B2B teams regularly at phoenix.studio, and the model matters far more than the markup.