A WordPress child theme is supposed to be a convenience — you get the parent’s templates and styles for free, and your customizations live safely in a separate directory. In practice, once your child theme grows past a handful of CSS overrides and starts managing its own templates, patterns, and functions, the parent becomes dead weight. A parent theme update you didn’t ask for can break a template you carefully modified. You end up wading through the parent’s code to understand behavior that has nothing to do with your site. At that point, converting your WordPress child theme to standalone is the right call.
What a child theme actually is
A child theme is just a directory with a style.css that declares a Template: header pointing at a parent. WordPress reads that header and loads the parent’s files first, then lets the child override them. That’s the entire mechanism. There’s no compiled output, no build step, no magic. Which means conversion is mostly a matter of copying files and removing one line.
When to convert a WordPress child theme to standalone
- Your child theme has its own full set of block templates (single.html, archive.html, etc.) and no longer inherits any from the parent
- Your
functions.phpis enqueuing the parent stylesheet explicitly — meaning you’ve already taken manual control of that dependency - You’ve stopped tracking the parent theme as something you want upstream changes from
- You want a clean git history without the noise of the parent theme’s files
If your child theme only overrides a few templates and relies on the parent for the rest, don’t convert yet. You’ll just be copying files you don’t fully understand.
Step 1 — Audit what you’re actually inheriting
Before touching anything, find out which parent theme files your child is using. In the WordPress admin, go to Appearance → Theme File Editor, or just inspect the theme directory:
ls wp-content/themes/your-child-theme/templates/
ls wp-content/themes/your-parent-theme/templates/
Any template in the parent that doesn’t have a matching file in your child is a dependency. You’ll need to copy those over, or accept that they’ll go missing after conversion.
Do the same for parts/, patterns/, and theme.json. The child’s theme.json deep-merges with the parent’s — if you’re relying on the parent’s color palette, spacing scale, or font definitions, you’ll need to replicate them.
Step 2 — Copy the files you need
Copy everything from the parent that you don’t already have in the child:
PARENT=wp-content/themes/twentytwentyfour
CHILD=wp-content/themes/your-child-theme
# Templates you're missing
for f in /templates/*.html; do
name=$(basename "")
[ ! -f "/templates/" ] && cp "" "/templates/"
done
# Block parts
for f in /parts/*.html; do
name=$(basename "")
[ ! -f "/parts/" ] && cp "" "/parts/"
done
For theme.json: if your child already has one, you need to manually merge the parent’s settings into it rather than just copying. Grab the parent’s version, look at the settings block, and pull in anything your child doesn’t define.
Step 3 — Update style.css
Open style.css and remove the Template: line:
/*
Theme Name: Your Theme
Version: 1.0.0
Description: Custom standalone theme
Author: You
*/
/* Remove or leave absent: Template: twentytwentyfour */
That’s the change that severs the parent relationship. WordPress will no longer look for a parent theme.
Step 3b — Reactivate the theme
Removing the Template: line from style.css severs the parent relationship at the file level, but WordPress stores the active parent theme name in the database separately. If you don’t reactivate, WordPress will still look for the old parent theme at runtime — breaking template resolution in ways that can be hard to diagnose.
After editing style.css, reactivate via WP-CLI:
wp theme activate your-child-theme-slug
Or go to Appearance → Themes in the admin and click Activate on your theme. Either way, this updates the template option in the database to point at your theme instead of the old parent.
You can verify it took effect:
wp option get template
# Should output your theme slug, not the parent
This is the step most guides skip — and the one most likely to leave you with a site that looks fine until you try to add a new FSE template and wonder why WordPress ignores it.
Step 4 — Fix functions.php
Child themes typically enqueue the parent stylesheet explicitly:
wp_enqueue_style('parent-style', get_template_directory_uri() . '/style.css');
Remove that line. get_template_directory_uri() used to point at the parent — now it points at your theme, and you don’t need to enqueue your own style.css separately (WordPress loads it automatically as the theme’s main stylesheet).
Also check for any calls to get_template_directory() in your functions. In a child theme this resolves to the parent; in a standalone theme it resolves to your theme. They should now point at the same place, but it’s worth grepping to be sure.
Step 5 — Activate and test
With the Template: line removed, WordPress will treat this as a standalone theme. If the parent theme is still installed, WordPress will ignore it. Activate your theme and walk through:
- Front page, single post, archive, 404 — confirm templates load
- Header and footer — confirm parts render
- Global styles — confirm
theme.jsonvalues (colors, typography, spacing) are intact - Any custom block patterns — confirm they appear in the inserter
If something is blank or broken, you missed a template or a theme.json setting. Check the browser console and the PHP error log — template resolution failures usually produce a notice.
Clean up
Once the standalone theme is working, you can safely remove the parent theme from WordPress entirely. There’s no longer a runtime dependency. If you’re tracking your theme in git, this is also a good point to commit a clean snapshot before doing anything else — you want a baseline that you know works before further development.
The whole process takes an hour if you’re methodical. The payoff is that your theme is now fully self-contained, and you’ll never be surprised by what a parent theme update does to your site.