Template parts vs block patterns: when to use each in the Site Editor

When developing block themes and configuring the WordPress Site Editor, teams frequently blur the boundary between template parts and block patterns. Both hold collections of blocks, and both can be inserted from the editor.

However, they operate in completely different layers of the WordPress database and template hierarchy. Confusing the two leads to template corruption, unexpected site-wide edits, and difficult client handoffs.

The architectural difference: frame vs content#

The simplest rule of thumb is separation of responsibility:

• Template parts define the global structural frame of your website (headers, footers, sidebars, mobile navigation menus). They belong to templates and apply site-wide.
• Block patterns define modular content sections (hero bands, pricing grids, testimonial carousels, feature lists). They belong inside individual pages and posts.

How template parts function#

A template part is registered as a static HTML file inside your theme's parts/ directory (for example, parts/header.html):

<!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group">
  <!-- wp:site-logo /-->
  <!-- wp:navigation {"layout":{"type":"flex","justifyContent":"right"}} /-->
</div>
<!-- /wp:group -->

When you insert a template part into a template, WordPress writes a reference block:

<!-- wp:template-part {"slug":"header","theme":"mytheme","tagName":"header"} /-->

When an editor modifies this header in the Site Editor, WordPress saves the customized version as a wp_template_part post in the database. Every page template referencing slug: "header" now renders that customized database record.

Why using template parts for page sections causes problems#

A common mistake in custom client builds is creating template parts for content sections (for example, parts/home-services.html or parts/about-team.html) and dropping them onto page templates.

This introduces two significant problems:

1. Unintended site-wide overrides: If a client edits the text of that section thinking they are editing just the home page, any other template referencing that part updates simultaneously.
2. Template pollution: Content becomes locked inside database template part records rather than standard post content, making SEO plugins, search indexing, and content exports difficult to manage.

Page-specific sections should always be inserted as block patterns into standard post_content.

How block patterns keep templates clean#

Block patterns provide ready-made section designs without creating global database references. When an author inserts a pattern into a page, the markup serialises directly into that post's post_content:

<!-- wp:group {"align":"full","layout":{"type":"constrained"}} -->
<div class="wp-block-group alignfull">
  <!-- wp:heading -->
  <h2 class="wp-block-heading">Core capabilities</h2>
  <!-- /wp:heading -->
  <!-- wp:paragraph -->
  <p>Modular architectures built on native block primitives.</p>
  <!-- /wp:paragraph -->
</div>
<!-- /wp:group -->

The author can modify headlines, swap images, and delete columns freely on that page without any risk of altering other templates or breaking global site layouts.

Clean Site Editor configuration rules#

To ensure a smooth handoff for content editors:

1. Restrict template parts to structural frames: Use template parts solely for headers, footers, and persistent sidebar structures.
2. Deliver page sections as patterns: Supply heroes, feature grids, pricing tables, and callouts as block patterns.
3. Lock template parts where necessary: In block themes, you can apply block locking ("lock":{"move":true,"remove":true}) on template parts in base templates so clients cannot accidentally delete site headers.

Pattern Paste is a curated library of 232 WordPress block patterns designed to drop cleanly into post_content, keeping your theme templates lean and protected. Browse the patterns, or explore four ways to add patterns to WordPress.