Synced Patterns in WordPress

What a synced pattern is: the current name for what WordPress called a reusable block — an arrangement of blocks stored once as a wp_block post and inserted everywhere by reference rather than by copy. Edit the content from any instance and every other instance updates immediately, because only one copy exists; every place it appears is a pointer to that same post.

Stored as a post type, not as page content

A synced pattern is not part of the post content of the page that displays it. WordPress stores it as its own post, of type wp_block, and the page merely embeds a reference block pointing at that post's ID — the same reference-by-ID design the Navigation block uses for its own wp_navigation posts. Opening the page in the code editor view shows a short reference comment, not the actual markup — the real content lives in the referenced post and is fetched at render time.

That single fact explains the two effects people notice:

• Editing is instant and global, because there is exactly one source of truth. Fixing a typo once fixes it on every page using the pattern.
• Deleting the source post breaks every page that referenced it, leaving an empty gap where the reference block used to render, since the ID it points to no longer resolves to anything.

The trap: editing one instance edits all of them

This is the most common complaint about synced patterns, and it is not a bug — it is the entire feature working as designed. Someone inserts a synced pattern for a call-to-action box, uses it on ten pages, then edits the button text on one page expecting a page-specific tweak. All ten pages change, because editing any instance edits the one underlying post. If even one page needed different wording, it should never have used a synced pattern in the first place, or that one instance needed converting to a regular copy before editing.

Converting to a regular (unsynced) copy

Any inserted synced pattern can be detached from the shared source: select it, open the block toolbar's options menu, and choose the option to convert it to regular blocks. That copies the current rendered content into the page as ordinary blocks with no further connection to the wp_block post. From that point it behaves exactly like a non-synced block pattern — safe to edit locally, and unaffected by later changes to the source, or by the source being deleted.

There is no reverse operation. Once detached, blocks cannot be re-synced back to the original post; a new synced pattern has to be created from scratch if that behaviour is wanted again later.

Where they live in the admin

Synced patterns are managed alongside other patterns in the site editor's patterns view, in a section kept separate from theme-supplied and core patterns so only the site's own synced entries show. Because they are an ordinary post type under the hood, they also show up wherever custom post types are queryable, which matters if a site's search or an export routine was not written to account for them — a general grounding in how custom post types work makes that behaviour less surprising.

When a synced pattern beats a shortcode or a template part

A synced pattern is the right call for something a non-technical editor needs to update visually — a promo banner, a contact block — where a shortcode would require touching PHP and a template part would apply too broadly, to every page on that template rather than to a chosen subset of posts — the same reasoning that keeps a live list of posts inside a Query Loop block instead of a synced pattern.

Export and portability

Synced patterns travel with the standard WordPress export, since they are ordinary posts in the database, and they import back in on another site the same way. What does not travel automatically is the reference: content that embeds a pointer to a specific post ID only resolves correctly if the corresponding wp_block post imported with the same ID mapping, which the core importer handles, but a manual database copy or a mismatched partial import can leave references pointing at nothing. Moving a site between hosts via a full database migration is safe; hand-picking individual pages to move is where broken references tend to appear.

Common mistakes

• Editing an instance without checking how many pages use it. There is no built-in warning before a shared edit goes live everywhere.
• Deleting a synced pattern that is still referenced. The pages using it lose that content silently rather than falling back to anything.
• Expecting a detach to be reversible. It is not; converting to regular blocks is permanent for that instance.
• Using a synced pattern for content that legitimately differs per page. That need calls for a regular pattern, not a synced one.
• Forgetting they are a post type when writing custom queries or exports that should deliberately include or exclude them.

Verify

Insert a synced pattern on two separate pages, edit it from one, and reload the other to confirm the change appears there too — that is the reference behaviour working correctly. Then detach one instance, edit it, and confirm the other pages using the still-synced version are unaffected. If a page shows a gap where a pattern used to render, check whether the underlying wp_block post still exists before assuming a theme or plugin problem.