How we make Craft CMS page builders in 2026

Because it's so highly customisable, Craft CMS doesn't come with a prescribed way to build pages. It's up to the developer to figure out something that suits the site.

We have a starting philosophy that shapes most of our builds these days, and we deviate from it or expand on it depending on what the site needs.

Matrix - for rows

Matrix is the OG.

It's a field type that lets you add sequences of blocks (which contain their own fields) and can be dragged and dropped to change their order.

In the past, this (or the similar Neo plugin), powered the entire content builder. We'd have dozens of block types, which could get a bit unweildy. I'd guess that most Craft sites online today will be using this technique in some shape or form.

The benefit is that it gives control to the editors of what appears on the page, but limits too much deviation that can lead to weird design decisions.

But that rigidity is also its drawback. A block might say you can have one call to action button, and it has to appear under the paragraph. Or that you can have an image to the right of the text, but not a Video. These kinds of things are what clients have reported as frustrations for years.

In an attempt to correct this, over the lifetime of a site it's common to introduce weird rules in dropdowns to try to add a bit more flexibility and they can become unweildy to use.

"What's the difference between side-by-side and featured image with text aside?"

Today, our starting point is that Matrix is for building out rows of content, with less definition about what's in those rows.

The starting point is a block called Content Row which includes a CKEditor.

Depending on the complexity of the site requirements, this might also allow users to change its appearance such as the row theme, how many coloumns it has, etc. If you pick a layout with 4 columns, we'll show 4 CKEditor fields.

Additional rows might be designed if they have a more rigid structure and the design really requires them to follow strict rules. That's no bad thing, but there's a time and a place for that rigidity.

CKEditor - for content

Craft's switch from Redactor to CKEditor as the preferred rich text editor provided a lot of nice improvements, but the big one for us was the ability to add nested entries within them.

This means instead of just headings, paragaphs, and basic text formatting we can now insert custom blocks such as accordions, video players, cards, buttons, galleries, etc. right inside the editor.

"Sorry, you can't put a video there" is solved. Editors who want text on the left and a video on the right make a new row with 2 columns, use the left CKEditor for the text and put a "Video" block in the right CKEditor.

All of the blocks are designed and controlled in code, so follow the site aesthetics.

The trade off is that editors can do things with blocks we didn't expect, which can lead to a few more bugs or some pages that are a bit OTT.

On balance, that's fine because we're always here to advise clients on how to build better pages and if a few bugs creep in because of how they want to use the website, we're here to fix it. The old, rigid content builder was probably just hiding these problems rather than solving them.

Improvement 1 - the nested entry picker

In my experience the main problem with understanding how to use a CMS is the naming of things. As developers, we have to name potentially quite complicated functionality in one or two words, which can be hard for editors to understand. Sometimes, there's multiple options that are ambiguously named, causing confuson of which to use.

At Mutual we have a custom plugin for our clients which replaces the CKEditor dropdown to a gallery, which shows a real representation of how that component looks on page.

We've found it's far easier for clients to choose the right one when they can see it.

Improvement 2 - reusable content

Many of our clients have the same content requirements across multiple pages. Perhaps it's a "About the company" blurb they like to put at the bottom of some pages, or a newsletter call to action that occasionally changes.

We introduce 2 sections in the CMS. Reusable Row and Reusable Content.

Reusable Row has the Matrix field, and allows them to compose one or more rows. Then, when they use the Matrix on a page they can add a Reusable Row block and select the entry from that section. When we render the page, we insert that row and whenever that resuable row entry changes, all pages that use it are automatically updated.

Reusable Content is an identical concept except instead of building re-usable Matrix compositions it's reusable CKEditor compositions; and these can be inserted directly into another CKEditor.

Improvement 3 - templated rows

In a similar way to Reusable Row we have Template Rows which are compositions of nice ways to present things, led by the designer. But where reusable rows are centrally managed, template rows are there to be cloned and adjusted each time its used.

Templates represent things that in the past might have been their own Matrix row, where we have a way we really think they should be presented but we don't want to force the client to only have one button, a single image, etc.

Our sites add a special button on the Matrix field called Add template which brings up a gallery of all of the templates available, and when they select a template those rows get appended to their content builder so they can freely make changes to suit their requirements on that page.

Conclusion

This approach isn't right for every person and every site, but after 10 years of tinkering with these, we've found this to be a model that works well for editors but stills gives us control over the elements that make up a page.

On the one hand, we're putting a lot of control in the hands of editors.

On the other, I think we were giving people too little control before.

One quick aside; we've also noticed that this approach of rows and content also works remarkably well for LLMs to compose some very nice looking pages from old content during site migrations. On a current project we're taking a bunch of reports produced as PDFs and converting them to web format using this approach and it's working very well.

A page builder is one of the bits of a site editors are going to spend most of their time using, so it's really worth getting it right for them.