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

> How template parts and block patterns differ in WordPress block themes, where each is stored, and how to avoid template corruption on client handoffs.

Published 24 August 2026 by Jake at Pattern Paste.
Canonical: https://patternpaste.com/blog/template-parts-vs-block-patterns/
Tags: Site Editor, Block themes, Patterns

---

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.

| Property | Template parts | Block patterns |
|---|---|---|
| Storage location | `parts/*.html` or `wp_template_part` post type | `patterns/*.php`, plugin, or inline in `post_content` |
| Scope of edits | Global: editing in one place updates all pages | Local: editing affects only that specific post |
| Insertion target | Theme templates (`index.html`, `single.html`) | Page content canvas via standard editor inserter |
| Client edit risk | High: accidental changes affect the whole site | Low: content changes remain isolated to that page |

## 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`):

```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:

```html
<!-- 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`:

```html
<!-- 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](/patterns/), or explore [four ways to add patterns to WordPress](/blog/add-a-block-pattern-to-wordpress/).*