WordPress Template Parts: Headers, Footers, and Reuse

A WordPress template part is a reusable structural region within block templates. Headers and footers are the common examples. Edit one part, and every referencing template can use the update.

Template parts belong to site structure, not unique page content. They help several templates share one maintained region. Block themes manage them through the Site Editor.

Use a part when the same structure belongs across templates. Do not create one for every small section. Too many parts make ownership harder to trace.

Template parts compared with related tools

The official WordPress comparison classifies template parts as site structure. Synced patterns and ordinary patterns belong to user content. That distinction guides composition. The longer version is in site editor vs block editor.

How template parts connect to templates

A template includes a Template Part block referencing a saved part. The reference identifies which shared region should render. Several templates can use it. We wrote that up in block patterns vs templates.

A Single template may reference the main header and footer. An Archive template can reference those same parts. Their central definitions prevent structural drift.

The template controls where the part appears. The part controls its internal blocks. Moving the reference changes one template; editing the part changes every reference.

This two-level ownership explains many save screens. WordPress can list both template and part changes. Review each object separately before confirming.

Where to manage template parts

With a block theme, open Appearance and then Editor. Choose Patterns, then find Template Parts. Interface labels can shift between WordPress releases.

The official Site Editor Patterns guide places template parts in this section. It also documents editing and duplication actions.

You can also select a part while editing a template. WordPress can open the shared object directly. Check the destination label before changing anything.

Theme-supplied parts can coexist with user-created parts. Names should reveal purpose and variation. “Header” and “Header minimal” communicate useful differences.

How to create a template part

1. Open Template Parts through the Site Editor.
2. Choose the action for adding a part.
3. Enter a specific structural name.
4. Choose the closest structural area.
5. Build the part with supported blocks.
6. Open List View and inspect nesting.
7. Test responsive and keyboard behaviour.
8. Save the new shared object.
9. Add its reference to intended templates.
10. Preview every affected template context.

Creation alone does not display the part. Templates must reference it. Document those references before assuming a part is unused.

Building a header template part

A header usually contains Site Logo, Site Title, Navigation, search, or buttons. Group and Row blocks organise those components. Keep nesting purposeful.

The logo should link appropriately and include accessible text treatment. Navigation needs visible focus and reliable submenus. Buttons need meaningful labels.

Desktop width alone is insufficient. Test wrapping, collapsed navigation, browser zoom, and long translated labels. Headers fail quickly under constrained space.

A minimal landing header may deserve another part. Do not mutate the main header for one campaign. Create a purposeful variant and assign it through templates.

Building a footer template part

A footer commonly contains navigation, contact details, legal links, and brand information. It may also contain a call to action. Keep required information discoverable.

Use current dates or dynamic output where accuracy matters. Hardcoded years become maintenance tasks. Shared factual content needs an explicit owner.

Footer navigation can use a different navigation entity from the header. Name each entity clearly. Editing link structure differs from editing footer layout.

Test the footer after every plugin adding banners or widgets. Page endings can accumulate competing elements. Mobile spacing and reading order deserve particular attention.

Can you create several headers and footers?

Yes. A site can maintain several template parts for different structural contexts. Templates choose the appropriate reference. Variants should represent real requirements.

A shop may need commerce navigation. A landing page may need fewer links. A logged-in area may need account actions.

Avoid variants differing only by arbitrary colour. Global or local style choices may solve that need. Structural variants should differ in content or composition.

Name each part by role and audience. Record every template using it. Delete a variant only after removing or replacing all references.

Template parts and navigation ownership

A template part can contain a Navigation block referencing separate navigation data. The part owns placement and surrounding layout. The navigation entity owns its links.

Changing header spacing should not require changing links. Adding a link should not require rebuilding the header. Keep those objects conceptually separate.

One navigation entity can appear within several parts. A link change can therefore reach unexpected locations. Record usage and preview each context.

File defaults and database overrides

Block themes can ship template parts as HTML files. The theme also registers their names and areas. These files provide default structures.

Site Editor changes can create database overrides. The customised part then takes priority over its file default. Updating the file may appear ineffective.

Resetting a customised part can reveal the current theme default. That reset removes user changes. Back up and review before using it.

Teams need a source-of-truth policy. Decide how Site Editor changes enter version control or migrate between environments. Do not rely on manual memory.

How template part edits spread

1. An editor opens the shared template part.
2. The editor changes its internal blocks.
3. WordPress saves the shared object.
4. Every referencing template resolves the updated part.
5. Page caches may preserve older rendered output.
6. Cache refresh reveals the new structure publicly.

This reach is the feature, not an accident. Review all important template contexts. A correct blog header may fail inside a shop or account page.

Do template parts affect performance?

Template parts do not inherently slow WordPress. Their contained blocks determine queries, markup, and assets. A heavy header can affect every referencing page.

Navigation depth, logo images, search, and interactive scripts can add work. Measure complete pages. Include mobile interaction and uncached server responses.

Shared parts can improve performance governance. One lean correction reaches many templates. That leverage deserves regression testing before deployment.

Accessibility and SEO checks

Headers and footers should use appropriate landmarks. Navigation needs accessible names when several menus appear. Heading levels should support the surrounding template.

Keyboard users need visible focus and logical order. Mobile menus need operable controls. Skip links must target existing main content.

Search engines depend on crawlable navigation and meaningful links. Repeated footer text should remain accurate. Avoid stuffing shared regions with repetitive keywords.

Validate several combined templates. A correct part can create duplicate landmarks when another wrapper supplies them. Context determines the final semantics.

Backing up and migrating template parts

Complete backups need theme files and database customisations. Either layer alone may be incomplete. Keep uploads when parts reference Media Library assets.

The Site Editor can export theme changes. Review exported files before deployment. Confirm that template references and part slugs remain consistent.

After migration, open each important part directly. Then preview every referencing template. A visible header alone does not prove the correct source is active.

Theme switching changes available defaults. User-created parts may persist but lose styles or assignments. Test the complete switch on staging.

Template parts beyond headers and footers

Sidebars can become template parts when several templates share them. Repeated utility bars or announcement regions can qualify too. Their ownership must remain structural.

A part can represent a general region through its assigned area. Areas help WordPress organise parts within the editor. They do not determine frontend placement alone.

Templates still decide placement and frequency. The same part can appear more than once. Test landmarks and repeated identifiers when doing this.

Do not turn ordinary article sections into template parts. Content ownership becomes confusing. Patterns or synced patterns usually suit those sections better.

When not to create a template part

Do not create a part for structure used within one template only. Keeping it directly inside that template makes ownership clearer. Abstract after verified reuse.

Do not create one for shared factual content alone. A synced pattern better signals content ownership. Template parts should frame site structure.

Do not create a part merely to shorten List View. Collapsing Groups can reduce visual clutter. Every shared object adds maintenance and deletion risk.

The weak case is decorative reuse across unrelated templates. Global styles or block styles may solve that need. Shared structure should have a structural purpose.

Revisions and recovery

WordPress can provide revision and reset tools for customised template parts. Interface availability varies. Confirm the recovery path before broad editing.

Resetting reveals the theme’s current file default. It does not necessarily restore an older custom design. Revisions and backups serve different recovery goals.

Practise restoring one important part on staging. Verify every referencing template afterward. Cache refresh may be required before the restored output appears.

Client access and template parts

Clients editing content rarely need unrestricted template-part access. Shared structural changes deserve trained roles. Capabilities should match actual responsibility.

Show clients how parts differ from navigation and page content. Use one live staging example. Then show the save panel’s separate object names.

Provide a request path for structural changes. Narrow access should not block legitimate work indefinitely. Clear ownership makes controlled updates faster.

Document which variants serve each business context. Include their responsible owner and rollback method. Review that map after redesigns.

Retire obsolete variants deliberately. Replace every reference first, then verify production before deleting the unused shared object. Test through every normal publishing role.

Common template part problems

• Editing one shared part for a local exception.
• Creating duplicate headers with unclear names.
• Confusing navigation data with header layout.
• Ignoring database overrides during theme updates.
• Deleting parts before replacing every reference.
• Testing only one template and screen width.
• Placing unique page content inside shared structure.
• Using excessive nested containers for simple layouts.

Fix ownership before styling around a problem. A duplicate or stale part can look correct temporarily. Clear sources prevent the issue from returning.

How to troubleshoot the wrong header or footer

1. Identify the page’s active template.
2. Open that template through the Site Editor.
3. Select its Template Part reference.
4. Confirm the referenced part name and slug.
5. Check for database customisation indicators.
6. Compare the active part with theme files.
7. Inspect navigation and synced content references.
8. Clear relevant caches once.
9. Retest logged out at the target URL.

Do not edit every header until one seems correct. Find the active reference first. Random changes multiply the source-of-truth problem.

A safe template part update workflow

1. Name the part and its responsible owner.
2. List templates referencing that part.
3. Create a current staging copy.
4. Back up files and database together.
5. Make the smallest required change.
6. Review every object in the save panel.
7. Preview all important template contexts.
8. Test mobile, zoom, keyboard, and logged-out views.
9. Deploy through the normal release process.
10. Verify production after cache refresh.

Record the change beside the part’s usage map. Shared structure deserves release discipline. Its visual editor does not reduce production reach.

Frequently asked questions

The verdict

Reliable template parts give specialised blocks a stable site frame. WP Block Suite extends content without replacing that architecture. Try the free plugins first. Then compare the $299 lifetime suite for several Pro needs.