WordPress Child Themes Explained: When You Need One and When You Don’t
Most people encounter the idea of a child theme at the worst possible moment , right after a theme update wiped out every custom tweak they'd spent hours making. A child theme stops that from happening. It's a small layer that sits on top of your main theme and holds all your changes safely, so updates to the parent theme don't erase them. Whether you actually need one depends on how you're building your site, and that's what this guide works through.
On this page
What a Child Theme Is
A WordPress child theme is a separate layer that sits on top of an existing theme and holds only your changes, nothing else.
Think of it like a car engine straight from the factory. The parent theme is that engine, thousands of hours of engineering, tested and tuned, doing the real work under the bonnet. When you want to change the colour of a component or swap out a bracket, you don’t pull the engine apart. You work on a copy of the part, keep the original untouched, and fit your modified version on top. That’s exactly what a child theme does. It inherits every style, template and function from the parent automatically, so your site still looks and behaves as expected. The only thing stored in the child theme is what you personally changed, which might be a handful of lines in a stylesheet or a single modified template file.
The practical upside is straightforward. When the parent theme receives a security update or a bug fix, you apply it without wiping out your own work. Your modifications live separately and survive the update intact.
The Problem It Solves
Most people who edit a parent theme directly don’t realise the risk until the damage is done. You open the theme editor, tweak a font size, adjust some spacing, maybe drop a line of custom CSS into the stylesheet. It looks exactly right. Then a few weeks later the theme author pushes an update, you click that familiar blue button, and every single change you made disappears. The update overwrites the theme files completely, which is precisely what it is supposed to do. The problem isn’t the update mechanism. The problem is that your edits were sitting in files that were never meant to be touched.
A child theme separates your customisations from the parent’s core files. WordPress loads the child theme first, falls back to the parent for anything you haven’t overridden, and your changes survive every update cleanly. If you’re curious how the structure beneath a theme works, understand it before you start customising anything.
The fix is straightforward once you know the cause. The painful part is usually finding out the cause after the fact.
What Lives Inside a Child Theme
The style.css file
A minimal child theme is two files. The first is style.css, which does less than its name suggests. Its real job is the header comment block at the top, where WordPress reads the theme’s name, version, and most importantly the Template: line that points back to the parent. Without that single line, WordPress has no idea the two themes are connected. You can add actual CSS rules beneath it, and many developers do, but the file earns its place just by declaring the relationship.
The functions.php file
The second file is functions.php. This is where the child theme loads the parent’s stylesheet and where you add any PHP customisations, hooks, or extra functionality. Changes here stay completely separate from the parent’s own functions.php, so a parent theme update cannot overwrite them.
That separation is the whole point. The parent theme carries the full design system, the template files, and the layout logic. The child theme holds only what you changed. Picture a site where you need custom fonts and a tweaked header colour. Rather than editing the parent directly, those two rules sit in the child’s style.css and survive every future update untouched. If you want to understand how theme architecture feeds into broader performance and structure decisions, that connection runs deeper than most people assume.
When You Need One
The clearest signal is whether you’re touching the theme’s files directly. If you open functions.php to add a custom function, edit style.css to change a font size, or drop a PHP snippet into a template file, you’re working inside code that a theme update will overwrite completely. One click on “Update” and your changes are gone, with no warning and no recovery.
The same applies to custom CSS that goes beyond what the WordPress customiser holds safely. A few colour tweaks in the customiser are fine. But if you’re writing rules to restructure layouts, override third-party plugin styles, or fix display issues on specific page templates, those belong in a child theme’s stylesheet where they’ll persist.
PHP hooks, custom page templates, and any caching configuration tied to theme behaviour all follow the same rule. If it lives in a theme file and you wrote it yourself, protect it with a child theme. Set it up before you start, not after you’ve already lost a week of work.
When You Can Skip It
Not every WordPress site needs a child theme. For a lot of builds, it’s an unnecessary layer of complexity.
If your site is built on a block theme using Full Site Editing, the customisation you make lives inside the database, not in theme files. The same goes for page builders like Elementor or Bricks, where your layouts and styles are stored as post data rather than in PHP templates. Even a classic theme where everything is managed through the WordPress Customiser or a dedicated plugin puts your changes somewhere WordPress itself controls. In none of those cases does a core theme update have any path to overwrite your work, because your work was never sitting in the theme folder to begin with.
You can find a similar principle when understanding how WordPress caches and stores data at different layers. What matters is where your changes actually live, not what they look like on the surface.
Skipping a child theme in these setups isn’t cutting corners. It’s just reading the situation correctly.
Block Themes and Full Site Editing
Block themes handle customisation in a fundamentally different way to classic themes, and that changes the child theme calculation considerably. With a classic theme, editing a template file means touching PHP inside the theme folder, so a child theme is the obvious protective layer. Block themes built for Full Site Editing store their templates and style variations in the database instead, pulled out through the Site Editor rather than through raw files.
That means when you make changes in the Site Editor, those changes live in your database and survive a theme update automatically, because the update only touches the files, not your saved database records. A child theme adds no protection there. There’s nothing in the files to overwrite.
For most block theme users, a child theme is unnecessary. Your typography tweaks, colour choices and custom templates are database entries, not files. Where it does still apply is if you’re writing custom PHP, adding template parts as actual files, or modifying the theme at a code level rather than through the editor. At that point, the old rules come back into play.
Setting One Up
The manual route
Create a folder inside wp-content/themes/, name it something like twentytwentyfour-child, then add a style.css with a header block that names the parent theme and a functions.php that enqueues the parent stylesheet. That’s it. WordPress picks it up automatically, and you activate it from the Themes screen like any other theme. No build tools, no terminal commands, no engineering degree required.
The plugin route
If that still feels fiddly, a plugin like Child Theme Configurator does the same job through a form in your dashboard.
Either way, setting up a child theme isn’t the hard part of a WordPress project. The hard part is knowing when to bother, which is what the rest of this article covers. Where it does matter is in how WordPress handles assets and caching once your custom stylesheet is in place, so understanding that layer saves you chasing phantom style issues after a parent theme update.