An enterprise WordPress block system your marketing team cannot break

A page builder is a full WYSIWYG surface. It hands editors arbitrary widths, arbitrary colors and nested containers, and returns design drift plus a heavy front end, because the builder ships its own runtime to every visitor.

A block system inverts the trade. Editors get fewer decisions and better ones, and the output is native Gutenberg markup rendered by your own theme.

There is an exit question too. Page builder content is usually stored in the vendor’s own format, while block attributes live as block comments inside post content, a documented WordPress format.

Core blocks are the right foundation and we use them inside our own components: paragraphs, lists and headings all live inside our FAQ items. What core does not give you is your design system.

Third-party suites are quick to implement and give you limited control plus a dependency on somebody else’s roadmap. When the vendor deprecates a block, your pages become their decision.

The trade-off is honest: a custom library costs more up front, and pays back when the same design system has to hold across regions, sub-brands and a redesign.

They can change content, images, icons, block order, which blocks appear, and the options each block exposes:

• Background from a defined list, and a vertical padding step.
• Column count, layout variant and heading level.
• An anchor, so campaigns can deep link to a section.

They cannot set arbitrary hex colors, arbitrary font sizes, custom gradients or custom CSS, and they cannot rearrange the internals of a component. Those are switched off in theme.json, which disables custom color, custom font size, custom gradients and the default palette.

The line moves per client. Some teams want more spacing control, some want less. What matters is that the line exists in code rather than in a style guide nobody opens.

Twenty to forty covers most enterprise sites. Fewer and editors start abusing blocks for jobs they were never built for. More and the inserter becomes its own usability problem.

The rule we hold to: one well-configured block beats three similar ones. If two differ only by arrangement, they should be one block with a layout option. Our features block carries five layout variants rather than existing five times.

This site runs 48 blocks, but that count includes inner components such as FAQ items, testimonial items and grid columns that never appear in the inserter on their own.

Because blocks store attributes and render on the server, a visual change is a change to templates and tokens, not to content. Update the templates and the design tokens and every existing page picks it up, with no bulk re-save and no block validation errors.

What does need work is anything the new design makes structurally obsolete, such as a block whose layout no longer exists. That is a migration, and a small one next to re-authoring every page.