The fastest way to slow down a WordPress site and your own editorial workflow is to reach for a custom-coded block every time you want something to look reused. Gutenberg ships two flavors of patterns that handle most of that work without a single line of PHP, and knowing exactly where each one stops being enough is what separates a clean, maintainable site from a pile of bespoke blocks nobody wants to touch in two years.

This is a decision article, not a feature tour. The question is narrow and practical: for any given repeating element on your site, should it be a synced pattern, an unsynced pattern, or a genuinely custom block? Get the boundary right and you save yourself maintenance debt. Get it wrong and you either lose global control or you write code you never needed.

Three tools, three jobs

Quick definitions, because the renaming has confused everyone. What WordPress used to call "reusable blocks" became synced patterns in WordPress 6.3 (mid-2023). They are stored as the wp_block post type, edited in one place, and every instance on the site updates the moment you save the source. That is the literal "reusable" in the title.

Unsynced patterns are the opposite contract: insert one and you get an independent copy. Editing the original never touches what you already placed. They are a starting template, not a single source of truth.

Custom blocks are code — a block.json plus register_block_type(), or an ACF block, or a block built with a framework like Genesis Custom Blocks. They can hold logic, pull dynamic data, and expose structured editor controls that a static pattern simply cannot.

When synced beats custom

Reach for a synced pattern whenever the requirement is "this must be identical everywhere and I must be able to change it everywhere at once." The win cases are remarkably consistent across sites:

A call-to-action box linking to your current lead magnet or product. When the offer changes, you edit one pattern and 200 posts update.
An author or company bio appended to articles.
A promotional banner for a seasonal sale that needs to vanish site-wide on a specific date.
Legal or affiliate-disclosure lines, contact blocks, or a standardized "last reviewed" note.

People instinctively reach for a custom block here because "it appears everywhere and updates centrally" sounds like a job for code. It usually isn't. A synced pattern gives you the same central control with zero build step, zero deployment, and full editing by non-developers. If the content is static markup that propagates, custom code is over-engineering.

The one genuine risk: a synced pattern is a single point of failure. Break the layout in the source and you break it on every page simultaneously. Treat edits to a heavily-used synced pattern with the same care you would a global stylesheet — preview before you save, and avoid editing it inline from inside a post (it is easy to forget you are changing the master).

When unsynced beats both

Unsynced patterns win when the structure repeats but the content is unique every time. This is the case people most often handle wrong — either by forcing it into a synced pattern (then fighting to detach instances) or by building a custom block they didn't need.

Classic fits:

A product-review layout: image, rating row, pros/cons columns, verdict box. Every review fills it with different words.
A case-study scaffold: client, challenge, solution, results.
A tutorial skeleton: overview, prerequisites, numbered steps, conclusion.
An FAQ block group a writer expands and edits per page.

The advantage is editorial, not technical: writers start from a thoughtful structure instead of a blank canvas, which quietly enforces thorough coverage of the sections you care about. The trap is formula fatigue — if every reviewer treats the template as a rigid cage, your content starts to read like it was stamped out. Build unsynced patterns to encourage good structure, then expect and allow writers to deviate.

When custom actually beats patterns

Here is the line patterns cannot cross. A pattern, synced or not, is static saved markup. The moment an element needs to compute or fetch something at render time, you have left pattern territory and you need a block:

Dynamic data. A "latest 3 posts in this category," a live pricing table pulled from a custom field, a testimonial that rotates — anything that should change without someone re-editing the markup.
Interactivity and logic. Tabs with state, a filterable directory, an accordion driven by data, a calculator. The Interactivity API (stable since WordPress 6.5) is the modern path for this.
Structured, validated editor controls. When you want non-technical authors to fill specific fields — a star rating from 1 to 5, a required image, a dropdown — and you want to guarantee the output. ACF blocks shine here.
Versioned reuse across many sites. If the same component must ship to a dozen client sites and stay updatable from one codebase, that belongs in a plugin as a registered block, not as a pattern copied into each install.

If none of those apply — if you are really just reusing a fixed arrangement of headings, paragraphs, images, and buttons — a custom block is wasted effort. You will maintain a build pipeline and a deployment for something two clicks in the Site Editor would have solved.

A decision shortcut

Run any repeating element through three questions in order:

Does it need to render dynamic data or behave interactively? Yes → custom block. Stop here.
Must every instance stay identical and update globally? Yes → synced pattern.
Otherwise — same structure, different content each time → unsynced pattern.

That order matters because the costly mistake is answering "global update" first and reaching for code. Dynamic behavior is the only thing that genuinely forces custom; everything else is a pattern.

Registering and organizing what you keep

However you build patterns, register them so they survive. You have three routes: create them in the Site Editor under My Patterns (stored in the database as wp_block), register them in PHP with register_block_pattern(), or — the most portable option for a block theme — drop PHP files with header comments into the theme's /patterns directory so they travel with the theme and live in version control. Theme-bundled patterns are the right home for anything you want backed up and deployable; database patterns are fine for one-off site-specific content. You can also browse and import community layouts from the public WordPress Pattern Directory.

Whatever lives in your library, name it for findability the day you create it. Prefix by role — CTA: Newsletter, Layout: Hero image-right, Review: Product scaffold — so a library of thirty patterns stays scannable instead of becoming a flat, unsearchable list. Patterns also quietly encode design and accessibility decisions: bake correct heading levels and contrast-checked colors into the source, and you propagate good defaults; bake in a contrast failure and you propagate that to every page too. A pattern is a small design system, for better or worse.

The honest summary

Synced patterns beat custom blocks for static content that must update globally — and that covers more of your repeating elements than you'd guess. Unsynced patterns beat both when structure repeats but content doesn't. Custom blocks earn their keep only when something must be dynamic, interactive, validated, or versioned in code across sites. Most teams over-reach for custom and under-use patterns; correcting that is the single biggest maintenance win available in the modern block editor.

WordPress Gutenberg Patterns: When Reusable Beats Custom