WordPress Child Themes

A child theme inherits templates and styles from a parent theme while keeping selected customisations separate. It can protect code changes from being overwritten by parent-theme updates, but it is not required for every visual adjustment and it does not make custom code maintenance-free.

When a child theme is useful

• A developer must override parent-theme templates
• Custom PHP or substantial CSS belongs specifically to the presentation layer
• The parent theme will continue receiving updates
• The customisations need a clear, version-controlled home

When it may not be needed

• The change is supported by theme settings or global styles
• The adjustment belongs in a plugin because it controls functionality
• The site uses a custom theme with its own update process
• Only a small amount of safe additional CSS is required and the storage location is documented

How inheritance works

The child theme declares a parent theme and can supply its own stylesheet, functions and selected templates. WordPress uses the child version where an override exists and otherwise falls back to the parent. This relationship means parent updates can still change assumptions that the child theme relies on.

Common mistakes

• Editing the parent theme directly as well as creating a child theme
• Copying many parent templates without a reason, making future comparison difficult
• Putting business functionality into the child theme so it disappears when the design changes
• Failing to record who wrote the custom code
• Assuming a child theme automatically receives compatibility fixes

Safe development process

1. Create a staging site and current backup.
2. Put the child theme under version control where possible.
3. Override only the file or behaviour that genuinely needs changing.
4. Document the reason for each customisation.
5. Test parent-theme updates on staging.
6. Check templates, forms, navigation and critical mobile layouts after every relevant update.

Handover requirements

Child-theme handover

Item	What the business should receive
Files	A complete copy of the child theme
Source history	Repository or change log where available
Dependencies	Exact parent theme and required plugins
Licence	Rights to use the custom code and any third-party assets
Update process	Instructions for testing parent and WordPress updates
Rollback	A known-good backup or deployable previous version

What to check before removing it

Never deactivate or delete a child theme on a live site simply because its name looks unfamiliar. Test on staging and identify which templates, styles or functions would disappear.

Practical next step

Ask a developer to list every customisation in the child theme and label it as presentation or functionality. Move business-critical functionality to an appropriate plugin before redesigning.

Child theme versus custom plugin

Code that changes presentation or overrides a theme template often belongs in a child theme. Code that creates a business function, content type, integration or rule should usually survive a redesign and may belong in a custom plugin. This distinction prevents important behaviour disappearing when the theme changes.

Review after parent-theme updates

An overridden template can become outdated when the parent theme changes markup, accessibility behaviour or security handling. Compare customised files with the new parent version and test affected journeys. WordPress will not automatically merge the supplier’s improvement into the copied child template.

Keep comments and a change log concise but specific: state the business reason, the original behaviour and how the change is tested.

Sources and date checked

This guide was checked on 21 July 2026. WordPress, hosting environments and extensions change, so recheck the relevant official documentation before making a major change.

• WordPress child themes handbook
• WordPress theme handbook
• WordPress documentation