How to Build a WordPress Website with Gutenberg Blocks

A marketing team asks for a small content change: swap the hero image, adjust a headline, add a new testimonial.

On a site built with a page builder plugin, that request often still routes through a developer. Or through an editor slow enough that the marketing team stops asking.

On a site built with Gutenberg blocks, it’s a five-minute job. Same WordPress editor the team already uses to write blog posts.

That gap is why more agencies, cmsMinds included, default to Gutenberg blocks over page builder plugins for new WordPress builds. But “build it with Gutenberg blocks” gets said a lot without much explanation of what that actually involves.

This post covers the process cmsMinds runs, end to end:

• How a design turns into a reusable block list
• The two build paths (ACF Blocks or a fully custom block theme) and when each one fits
• A realistic timeline by project size

Why Gutenberg Blocks Instead of a Page Builder Plugin

WordPress Gutenberg blocks are the performance-optimized version of WYSIWYG editing.

They let a marketing team keep using the block editor they already know, without loading a page builder plugin’s extra CSS, JavaScript, and rendering layer on top of it.

That extra layer is the real cost. Page builder plugins like Elementor and Divi aren’t bad tools, they just work differently from WordPress core:

A Gutenberg block skips that layer entirely. It’s registered in WordPress core, rendered the way WordPress core expects, and edited in the same interface a content team already uses to write a blog post.

For a marketing team, this usually comes down to speed and flexibility, without giving up either one:

• A page builder buys flexibility at the cost of speed.
• A rigid, prebuilt theme buys speed at the cost of flexibility.
• Custom blocks, built for the business instead of pulled from a general-purpose theme, are the option that doesn’t force that trade.

Planning the Build: Design Analysis and the Reusable Block List

Reviewing Figma/XD Designs and Mapping Components

Before any block gets built, we audit the design file for what actually repeats.

That means going through every page in the Figma or Adobe XD file and noting which sections show up more than once, in the same or a slightly adjusted form:

• Hero sections
• Callout bands
• Card grids
• Logo strips

It also means checking how each section behaves at tablet and mobile breakpoints. A component that looks simple on desktop can hide a lot of responsive logic underneath.

The output is a component map: every distinct UI pattern in the design, tagged as one of two types:

• Structural: used once, specific to one page’s layout
• Reusable: used three or more times, a real candidate for a block

Building the Reusable Block List

Anything reusable becomes a candidate for its own Gutenberg block, built once and inserted wherever it’s needed instead of rebuilt page by page.

We scope each candidate before development starts:

• What fields does a content editor actually need to control (text, images, a repeatable list)?
• What should stay fixed by design instead of editable?

Setting the Technical Foundation

Header, Footer, and Global Navigation

We build the header, footer, and navigation once, as template parts, the site editor’s term for a piece of layout shared across every page.

Update the footer once, and it updates everywhere it’s used, without touching individual pages.

Global Theme Settings

Colors, typography, spacing, and button styles get defined once at the theme level instead of set page by page.

Both approaches keep design decisions in one place. The difference is how much of the theme is purpose-built versus how much comes from a starting foundation, which is exactly what the next section covers.

Developing the Blocks: Two Approaches

This is the step most “how to use Gutenberg” guides skip: there isn’t one way to build custom blocks.

cmsMinds uses two, and which one gets used depends on the kind of site being built.

ACF Blocks + Gutenberg, for Most Marketing Sites

For most marketing sites, we build blocks with Advanced Custom Fields (ACF) on top of Gutenberg.

This pairing produces semantic HTML that both search engines and AI systems can parse cleanly. That keeps the site fast and accessible, while giving the marketing team day-to-day flexibility to edit content without a developer.

It’s worth being direct about something that trips people up here: ACF Blocks aren’t a step down from “real” native blocks.

When ACF’s Blocks API registers a block, it appears in the same block inserter as every core WordPress block. A content editor works with it inside the same block editor, not a separate builder interface.

The distinction that actually matters, native blocks versus a page builder plugin, comes down to one question: does content get edited inside WordPress’s real block editor, or inside a walled-off canvas that generates its own markup?

ACF Blocks sit on the native side of that line. ACF is a development choice (PHP and field groups instead of hand-written JavaScript), not a page-builder substitute.

Custom Block Themes, for Publishing and Enterprise Sites

For publishing and enterprise sites, the better fit is usually a fully custom block theme: no ACF layer, blocks built directly with block.json and JavaScript, and the whole theme structured around full site editing.

This is the highest-performing, most native option WordPress offers today. It also costs more development time upfront, which is why it earns its keep on larger builds where that investment pays off over years, and less often on a marketing site that needs to launch in weeks.

Watch out: prebuilt blocks aren’t custom blocks

Custom blocks built for the business get confused with the prebuilt blocks that ship inside a block theme like Kadence, but they’re different things. A block theme’s prebuilt blocks are designed for general use across thousands of different sites. They’re a reasonable starting point, but they often don’t map to one business’s actual content needs. A custom block, built for one site’s real fields and real content, will.

Assembling the Site

Global and Synchronized Content

Some content needs to update from one place across the whole site. A partner logo strip is the clearest example.

Synced patterns handle this: edit the pattern once, and every page using it updates automatically. No one has to hunt down every page that shows a logo strip after a client swaps partners.

Reusable Patterns

Block combinations that show up together, a heading, a paragraph, and a button in the same layout, get saved as a pattern instead of rebuilt from individual blocks every time.

Patterns speed up page assembly and keep spacing and structure consistent, without a content editor needing to remember the right combination.

Building Page Templates

With the block library and patterns in place, we assemble page templates from them:

• A service page
• A landing page
• A blog post template

Each one gets built by arranging existing blocks and patterns instead of starting from a blank canvas.

Getting Ready to Launch

SEO Setup and Optimization

We check every block for proper heading structure and semantic HTML. A Gutenberg-built site loses its main advantage if the markup underneath isn’t actually clean. That includes:

• Metadata
• Image alt text
• Schema markup
• Clean URLs across every template

Responsive and Cross-Browser Testing

We test every block and every template across desktop, tablet, and mobile, and across the browsers real visitors are using, not just the one open on a developer’s machine.

Final QA and Optimization

A last pass checks functionality, spacing, accessibility, and performance against the approved designs, block by block and page by page, before anything goes live.

How Long Does It Actually Take?

There’s no single answer, but there is a realistic range. It depends mostly on how many custom blocks the design calls for and how complex the integrations are.

• Small sites: 2 to 4 weeks
• Mid-size sites: 2 to 3 months
• Enterprise sites: 3 to 6+ months

A small marketing site with a handful of reusable blocks and no complex integrations sits at the low end.

An enterprise build with a fully custom block theme, dozens of blocks, and integrations into other systems sits at the high end. That’s before design revisions or a content migration running in parallel stretch it further.

Conclusion

Gutenberg blocks versus a page builder isn’t just a technical preference. It’s a trade-off cmsMinds makes deliberately, and differently, depending on the project:

• Most marketing sites get ACF Blocks with Gutenberg: real flexibility for the content team, without a page builder’s performance cost.
• Publishing and enterprise sites get a fully custom block theme, built for a performance ceiling only a from-scratch build reaches.

Either way, the process holds the same shape:

• Audit the design for what repeats
• Build that as a reusable block
• Assemble it into templates
• Test everything before launch

The choice that actually matters is which of the two build paths fits the site in front of you, not whether Gutenberg is the right editor. For most WordPress sites built today, it is.