How to Create a WordPress Child Theme (Step by Step)

What a WordPress Child Theme Is

A WordPress child theme is a small theme that sits on top of another theme, called the parent, and borrows almost everything from it while letting you change a few things safely. The child theme inherits the parent theme's design, templates, and functions, and you only add the pieces you want to be different. Everything you do not override simply falls back to the parent, so the child can be tiny, sometimes just two files, and still produce a fully working site that looks exactly like the parent until you decide to change something.

The point of this arrangement is separation. Your customizations live in the child theme's folder, and the parent theme stays untouched. That means when the parent theme releases an update, and good themes update often for security and compatibility, your changes are not wiped out, because they were never in the parent to begin with. If you would rather have a developer set this up and build your customizations properly, you can get a free quote and we will handle it.

Think of the parent theme as the finished house and the child theme as your renovations kept on a separate plan. When the builder ships an improved version of the house, your renovation notes still apply, because they were recorded separately rather than scribbled onto the original blueprints. That is the whole idea, and once it clicks, child themes stop feeling like an advanced trick and start feeling like basic hygiene for any site you plan to customize.

Why Use a Child Theme

The single biggest reason is update safety. If you edit a theme's files directly, your changes are stored inside that theme. The next time the theme updates, those files are replaced with the new versions, and every change you made is gone. People learn this the hard way: they spend a weekend tweaking a theme, everything looks great, then an automatic update arrives and the work vanishes. A child theme removes that risk completely, because your edits are in a folder the update never touches.

There are other good reasons too. A child theme keeps your customizations organized in one place, so you always know where your code lives and can move it to another site if you ever need to. It makes your changes easy to reverse, since switching back to the parent instantly removes everything the child added. And it gives you a clean place to add custom CSS, template overrides, and small functions without cluttering the parent or relying on a pile of plugins to do jobs a few lines of code can handle.

• Updates stay safe. Your work survives every parent theme update, which is the reason child themes exist.
• Changes are organized. Everything custom is in one folder, easy to find, back up, and reuse.
• Easy rollback. Switch to the parent and your customizations are gone cleanly, with nothing left behind.
• Room to grow. Start with a little CSS today and add template overrides and functions later as your needs grow.

The one honest caveat is that a child theme is only worth making if you plan to customize the theme with code. If all you want is to change colors and fonts that the theme already exposes in the Customizer or the Site Editor, you may not need a child theme at all. But the moment you want to touch CSS, templates, or PHP, a child theme is the right home for that work.

It is also worth clearing up what a child theme is not. It is not a way to combine two themes, and it is not a backup of your site. It borrows from exactly one parent, and it holds only your customizations, not a full copy of everything. People sometimes expect a child theme to protect them from every kind of change, but it protects one specific thing: the edits you make to a theme. Your content, plugins, and settings are separate concerns with their own protections, mainly regular backups. Understanding that boundary keeps your expectations realistic and points you at the right tool for each job.

When You Do and Do Not Need One

Child themes are useful, but they are not the answer to every customization, and making one you do not need just adds a file to maintain. The clearest way to decide is to ask where your change is going to live. If the change is code, meaning CSS you write yourself, edits to template files, or PHP functions, then a child theme is the right home and you should make one. If the change is a setting the theme already gives you, a child theme adds nothing.

Here is where you genuinely need a child theme. You want to add custom CSS beyond what the theme's options allow. You need to change the markup of a template, such as moving where the author name appears on a post. You want to add a function, register a menu location, or change how an excerpt is built. You are handing the site to a developer who will build ongoing customizations. In all of these, the child theme protects your work from parent updates and keeps it organized.

And here is where you do not need one. You only want to change colors, fonts, logo, and layout options the theme already exposes in the Customizer or the Site Editor, since those are stored in the database and survive updates on their own. You are adding a small snippet of CSS and your theme has a built in Additional CSS box, which is fine for one or two rules though it does not scale well. You are making content changes rather than design changes, which belong in pages and posts, not in theme files. Knowing the difference saves you from building machinery you will never use.

A fair middle ground exists too. Some people start with the theme's Additional CSS box for a rule or two, then graduate to a child theme once the customizations grow past what a single box can hold comfortably. There is nothing wrong with that path. The child theme becomes worthwhile the moment your changes are more than cosmetic tweaks the theme already supports, and especially the moment you touch a file rather than a setting.

Before You Start

Creating a child theme is not risky, but a few minutes of preparation makes the whole process calmer. First, take a full backup of your site, both files and database, so if anything goes wrong you can restore in minutes. This is good practice before any change, and our guide on backups covers doing it properly. Second, if this is a live business site, do the work on a copy first. A staging site lets you build and test the child theme without visitors ever seeing a half finished experiment.

You also need a way to add files to your site. You have two options: your host's file manager, reached through the hosting control panel, or an FTP or SFTP program that connects to your server. Either works. You will be creating a folder and a couple of text files inside the themes directory, which lives at wp-content/themes. Finally, note the exact folder name of your parent theme, because you will need it in a moment and it has to match precisely. You can find it by looking in wp-content/themes and reading the folder name, not the pretty display name.

One more thing worth deciding up front: which theme will be the parent. A child theme is tied to one specific parent, so pick a well built, actively maintained theme you are happy to keep. If your parent theme is abandoned or poorly coded, a child theme cannot fix that, and you may be better served by choosing a stronger foundation first. If you are unsure which theme to build on, our comparison of page builders and theme approaches can help you decide.

Step 1: Create the Child Theme Folder

The manual method is the classic way, and it is worth doing at least once because it teaches you exactly what a child theme is made of. Start by creating a new folder inside wp-content/themes. Give it a clear name based on the parent, with no spaces. A common convention is the parent folder name followed by -child. So if your parent theme folder is twentytwentyfour, name your child folder twentytwentyfour-child.

Inside that folder you will place, at minimum, two files: style.css and functions.php. That is genuinely all a working child theme needs. You can add an image called screenshot.png later so the theme shows a nice preview on the Themes screen, but it is optional and does not affect how the site works. Here is the file structure you are aiming for and what each piece is responsible for.

If you are using your host's file manager, navigate to wp-content/themes, create the new folder, then open it and create the two empty files. If you are using FTP, create the folder and files on your computer first, then upload the whole folder. Either way, the next two steps fill those files with the small amount of content that makes the child theme come alive.

Step 2: Write the style.css Header

Open style.css and add a special comment block at the very top. WordPress reads this block to learn the theme's name and, most importantly, which parent it belongs to. The one line that truly matters is Template, because it tells WordPress the exact folder name of the parent theme. Get this line right and the child works. Get it wrong and WordPress cannot find the parent, which is the most common reason a new child theme fails.

/*
Theme Name:   Twenty Twenty-Four Child
Theme URI:    https://example.com/twentytwentyfour-child/
Description:  A child theme of Twenty Twenty-Four
Author:       Your Name
Author URI:   https://example.com
Template:     twentytwentyfour
Version:      1.0.0
Text Domain:  twentytwentyfour-child
*/

Two details decide whether this works. The Theme Name can be anything readable, and it is what you will see on the Themes screen. The Template value must exactly match the parent theme's folder name, including capitalization, with no spaces and no display name. If your parent folder is twentytwentyfour, the Template line must read twentytwentyfour, not "Twenty Twenty-Four" and not anything else. This is the single point people trip over most, so double check it against the actual folder in wp-content/themes.

Everything below the closing */ of that comment is normal CSS, and you can leave it empty for now or add your first custom styles later. The header block on its own is what registers the theme with WordPress. Save the file, and you have completed half of the two file minimum. For the official reference on these header fields, the WordPress child themes documentation lists every supported line.

Step 3: Load the Parent Styles in functions.php

A child theme starts out with an empty style.css, which means that on its own it has no design at all. You need to tell WordPress to load the parent theme's stylesheet so the site keeps looking like the parent. The correct way to do this is with a function in functions.php that enqueues the parent style. Open your child theme's functions.php and add this.

<?php
add_action( 'wp_enqueue_scripts', 'ttf_child_enqueue_styles' );
function ttf_child_enqueue_styles() {
    wp_enqueue_style(
        'ttf-parent-style',
        get_template_directory_uri() . '/style.css'
    );
}

Here is what that does in plain terms. The wp_enqueue_scripts action is where WordPress expects themes to register their styles and scripts. The function hooks into it and calls wp_enqueue_style, pointing at the parent theme's style.css using get_template_directory_uri(), which always returns the parent theme's folder. That is the reliable, modern way to inherit the parent design, and it avoids an older technique using CSS @import that is slower and no longer recommended.

If your child theme will also have its own CSS in its style.css, enqueue both, loading the child after the parent so your styles win when they overlap. A slightly fuller version looks like this, and it also versions the child styles so browsers pick up your changes rather than serving an old cached copy.

<?php
// Load the parent stylesheet, then the child stylesheet.
add_action( 'wp_enqueue_scripts', 'ttf_child_enqueue_styles' );
function ttf_child_enqueue_styles() {
    $parent = 'ttf-parent-style';
    wp_enqueue_style(
        $parent,
        get_template_directory_uri() . '/style.css'
    );
    wp_enqueue_style(
        'ttf-child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array( $parent ),
        wp_get_theme()->get( 'Version' )
    );
}

One important note about functions.php in a child theme: it does not replace the parent's functions.php, it runs in addition to it. Both files load, with the child's running first. That means you never copy the whole parent functions file into the child. You only add the specific functions you want, which keeps the child small and avoids breaking the parent's own code.

Step 4: Activate the Child Theme

With both files saved and uploaded, go to your WordPress dashboard and open Appearance, then Themes. You should now see your child theme listed alongside the others, using the name you set in the header. Hover over it and click Activate. The moment you do, WordPress switches to the child theme, and because the child loads the parent's styles, your site should look exactly as it did before. If it looks broken or unstyled, that is almost always the enqueue step, so revisit the functions file.

After activating, click through a few pages of your site to confirm everything still renders correctly: the home page, a blog post, a page, and anything with a special layout. Because the child inherits the parent, nothing should have changed visually. Seeing an identical site is the sign of success, not a lack of progress. You now have a safe place to make changes that updates will never erase.

Do note that switching themes can sometimes reset widget areas or menu locations, depending on the theme, so check that your menus and any sidebar widgets are still assigned where they belong. If a menu came unassigned, just reassign it under Appearance, Menus. This is a one time housekeeping step, and it is why doing the switch on a staging copy first is a good habit for a busy site.

The Plugin Method

If editing files by hand is not for you, a plugin can create the child theme in a few clicks. Tools such as Child Theme Configurator and Generate Child Theme do the same work you just did by hand: they create the folder, write the header, and set up the enqueue for the parent styles. For many site owners this is the quickest route, and it removes the two things people get wrong most, the Template line and the enqueue function.

The steps are much the same across these plugins. Install and activate the plugin from the Plugins screen, open its page under Tools or Appearance depending on the plugin, choose your parent theme from a dropdown, and click the button to create the child. Within a moment you have a working child theme ready to activate, and some of these plugins can also help you copy specific parent template files into the child for editing, which saves a manual step later.

Child Theme Configurator in particular goes further by scanning the parent theme and offering a panel where you can add CSS overrides through the dashboard rather than editing files. That can be handy, though it also means some of your customizations live in the plugin's settings rather than in plain files, which is worth knowing if you ever move the site. For a straightforward child theme you want to keep in version control or hand to a developer, the plain file approach stays the cleanest.

Whichever plugin you pick, check that it is actively maintained and well reviewed before installing it, the same care you would give any plugin. Once the child theme is created, you can usually deactivate and even delete the generator plugin, because its job is done the moment the folder and files exist. The child theme keeps working on its own without the plugin present, since a child theme is just files WordPress reads directly. Removing the generator afterward keeps your site lean and means one fewer plugin to update, which is a small win worth taking.

Child Themes for Block Themes

Newer WordPress themes are often block themes, built for the Site Editor with templates written in HTML and settings held in a file called theme.json. Child themes still work with block themes, and the core idea is identical: a folder with a style.css header naming the parent in the Template line. What changes is where your customizations tend to live. With a block theme, a lot of design is controlled through theme.json and the templates in the templates and parts folders.

To customize a block theme through a child, you can add your own theme.json in the child folder to override colors, typography, spacing, and other global settings, and WordPress merges it with the parent's. You can also copy a template or template part from the parent into the child's templates or parts folder and edit it there, and the child version takes over. The enqueue step for the parent stylesheet is often unnecessary with pure block themes, since their styling flows through theme.json rather than a large CSS file, though adding it does no harm if the parent still ships CSS.

If you are moving from a classic theme to a block theme, be aware that the two do not share the same customization files, so a child theme built for a classic parent will not carry over. You would build a new child for the block parent and recreate the customizations in the block way, through theme.json and template files. It is not difficult, but it is real work, so factor it in when you plan a switch rather than assuming the child theme comes along for free.

There is also a lighter path worth knowing. The Site Editor lets you make many changes directly and stores them in the database rather than in theme files. That is convenient, but those changes are not as portable or as easy to review as files in a child theme, and they can be harder to move between sites. For anything you want kept, versioned, and safe from surprises, putting it in a block child theme remains the sturdier choice, especially on sites you maintain over the long run.

Overriding Template Files

Beyond CSS, the real power of a child theme is overriding the parent's template files. WordPress builds each type of page from a template, such as single.php for a single post, page.php for a page, or header.php and footer.php for the top and bottom of every page. When a file with the same name exists in the child theme, WordPress uses the child's copy instead of the parent's. That is how you change structure and markup, not just styling.

The safe way to override a template is to copy the file from the parent into the child, keeping the same name and the same location within the folder, then edit the copy. Never edit the parent's file, because that reintroduces the very problem child themes exist to prevent. Copy single.php from the parent into your child folder, make your changes there, and WordPress serves your version. If you later delete the child's copy, WordPress simply falls back to the parent again, which makes experiments easy to undo.

One frequent job is editing the footer, for example to change or remove the credit line many themes place there. Because the footer usually lives in footer.php, you copy that file into the child and edit the copy. We cover this specific task in detail in our guide on how to edit the footer in WordPress, which walks through both the child theme route and the simpler options for small changes.

There is one nuance worth knowing about how the override works. For most template files, WordPress checks the child folder first and uses the child copy if it finds one. But some files are pulled in by the parent using functions like get_template_part, and those follow the same child first rule as long as you keep the same relative path inside the child folder. If a parent stores a template part in a subfolder, recreate that same subfolder in the child so WordPress finds your version. Matching the parent's structure exactly is the reliable way to make overrides behave as you expect, and it is why copying from the parent, rather than writing from scratch, is the safer starting point.

Resist the urge to override more than you need. Every template you copy into the child is a file you now have to keep in step with the parent as it evolves. If the parent improves its single.php in a later version, your copied version will not get those improvements, because the child's copy is winning. That is a fair trade when you genuinely need a different layout, but it means you should override only the templates you actually change, and periodically compare your copies against the parent so they do not fall too far behind.

Adding Custom CSS and Functions

For most people, the two most common things a child theme holds are custom CSS and small custom functions. Custom CSS goes in the child's style.css, below the header block. Anything you add there loads after the parent styles, so it can adjust colors, spacing, fonts, and layout details without touching the parent. If a rule does not seem to apply, it is usually a matter of the parent's style being more specific, which you resolve with a more specific selector rather than by reaching for the blunt instrument of forcing it.

Custom functions go in the child's functions.php. This is where you add small pieces of behavior, such as registering a menu, tweaking an excerpt, or adding a snippet to the content. Here is a simple, self contained example that appends a short line to the end of every single post. It is deliberately small, which is exactly how child theme functions should be: a few focused additions rather than a rewrite of the parent.

<?php
// A small custom function added in the child theme functions.php
add_filter( 'the_content', 'ttf_child_append_notice' );
function ttf_child_append_notice( $content ) {
    if ( is_single() ) {
        $content .= '<p class="post-notice">Thanks for reading.</p>';
    }
    return $content;
}

A word of caution about functions.php: a single syntax error here can take the whole site down with a blank white screen, because the file loads on every request. Always add functions in small pieces, test after each change, and keep a backup. If you are writing more than a handful of functions, or anything that touches how the site works rather than how it looks, that is the point where custom code becomes real development, and our custom WordPress development service exists precisely for that kind of work.

A useful rule of thumb is to keep design in CSS and behavior in PHP, and to reach for the smallest tool that does the job. If a change can be made with a few CSS rules, do it that way rather than writing a function, because CSS is safer and cannot blank the site. Save the PHP for things CSS cannot do, such as changing what content appears or how a template is assembled. Keeping this separation in mind stops the child theme from turning into a tangle and makes it much easier for someone else, or you in six months, to understand what each piece is doing and why.

A Practical Example, Start to Finish

Let us tie the pieces together with a realistic job: you want to change the color of your buttons and remove the small credit line the theme prints in the footer. This touches CSS and a template, which is exactly the kind of work a child theme is for, and walking through it shows how the parts you have learned fit together in practice.

First, the buttons. You already have a child theme with a working style.css. Open a button on your site in the browser and inspect it to find the class the theme uses, say .wp-block-button__link. In your child's style.css, below the header, you add a rule targeting that class with your new color. Because the child stylesheet loads after the parent, your rule applies. If the parent's own rule is more specific and wins, you make your selector a little more specific to match, rather than forcing it. Save, clear any cache, and the buttons change.

Now the footer credit. This lives in a template, so CSS alone will not remove it cleanly. You find footer.php in the parent theme, copy it into your child folder keeping the same name, and open the copy. Inside, you locate the line of markup that prints the credit, remove or replace it with your own text, and save. Because the child now has its own footer.php, WordPress uses it instead of the parent's, and your footer shows what you want. If you ever want the original back, you delete the child's copy and the parent version returns.

Notice what you did not do. You did not edit the parent theme at all, so when it updates, both changes survive untouched. You made one change in CSS and one in a copied template, each in the smallest way that did the job. That is the whole rhythm of working in a child theme: find where the thing lives, make the change in the child, and leave the parent alone. Repeat that pattern and you can take a stock theme a long way while keeping every update safe.

Manual vs Plugin: Which to Choose

Both routes end with the same thing: a valid child theme that protects your customizations. The choice is really about how comfortable you are with files and how much you want to understand what is happening. Neither is wrong, and you can even use a plugin to create the child and then edit its files by hand afterward, getting the speed of one and the control of the other.

Our general advice is to do it manually once, so you understand the pieces, then use whichever method fits the moment. If you are setting up dozens of sites, a plugin is quicker. If you are building something you will maintain for years or hand to another developer, plain files in the child folder are the cleanest record of what you changed. Either way, the important part is that your customizations are no longer sitting inside a theme that an update can overwrite.

Testing and Maintaining Your Child Theme

Creating the child theme is the start, not the finish. A little discipline around testing and upkeep keeps it working smoothly for years. The first habit is to test after every change, not once at the end. When you add a CSS rule, a function, or a template override, save it and look at the affected page right away. Small, frequent checks catch a mistake while you still remember what you changed, which is far easier than hunting through a dozen edits after something breaks.

Get into the habit of testing on a copy rather than the live site whenever the change is more than trivial. A staging environment gives you a place to try a template override or a new function, confirm it behaves, and only then push it live. This matters most around parent theme updates. Even though a child theme protects your customizations, a big parent update can occasionally change the markup or classes your overrides depend on, so it is wise to update the parent on staging first and confirm your child still lines up before doing it in production.

Keep the child theme under a simple form of version control, even if that just means keeping dated copies of the folder or, better, using a real version control system. Because everything custom lives in one small folder, backing it up and tracking its history is easy, and it means you can always see what changed and roll back a single edit rather than the whole site. This is one of the quiet advantages of putting customizations in files rather than scattering them across plugin settings and the database.

Finally, revisit the child theme now and then to prune what you no longer use. Old CSS rules for elements that no longer exist, or functions tied to features you have removed, add clutter and can cause confusion later. A tidy child theme is easy to read, easy to hand to someone else, and easy to keep working as WordPress and the parent theme move forward. Treating it as a living part of the site, rather than a set and forget file, is what keeps it useful over the long term.

Troubleshooting Common Problems

When a child theme misbehaves, the cause is usually one of a few known things, and each has a calm fix. Here is how to diagnose the problems people run into most, so you can solve them quickly instead of guessing.

The site loads with no styling

If activating the child leaves the site looking plain and unstyled, the parent stylesheet is not loading. Check that your child's functions.php contains the enqueue function and that it points at the parent using get_template_directory_uri(), not the child directory function. Confirm the file is saved in the child folder and that there are no typos in the function. Once the enqueue is correct, clear any caching plugin and refresh, and the design should come back.

The child theme does not appear on the Themes screen

If you cannot see the child theme to activate it, WordPress could not read it as a valid theme. Almost always this is the style.css header, either missing entirely or with a Template line that does not match the parent folder name. Open style.css, confirm the comment block is at the very top, and check the Template value character for character against the actual parent folder name in wp-content/themes. Fix it and the theme appears.

A white screen after editing functions.php

A blank white page usually means a PHP error, most often a missing bracket, semicolon, or an accidental duplicate function name. Because you cannot reach the dashboard, use your file manager or FTP to open the child's functions.php and remove or correct the code you last added. The site should return immediately. This is why adding functions in small pieces and keeping a backup matters, since recovery is then a one line fix rather than a puzzle.

A parent update seemed to break the child

If a parent theme update changed how your customizations look, your CSS or a copied template is probably referencing markup or classes the parent changed. Compare the parent's new template against your copied version and update your copy to match the new structure, or adjust your CSS selectors to the new classes. This is the one case where child themes need a little upkeep, and it is why testing a parent update on a staging copy first is worth the few minutes it takes.

My changes are not showing up

When an edit refuses to appear, caching is the usual culprit. A caching plugin, a host level cache, or your own browser may be serving the old files. Clear the site cache, do a hard refresh in your browser, and if you version your enqueued styles as shown earlier, bump the version so browsers fetch the new copy. If it still does not show, confirm you edited the child theme's file and not a similarly named file in the parent.

Common Pitfalls

Most child theme problems come down to a small number of mistakes, and knowing them in advance saves a lot of confusion. Here are the ones we see most often and how to avoid each.

• Wrong Template value. The Template line in style.css must match the parent folder name exactly, including case. A mismatch means WordPress cannot find the parent, and the child will not activate correctly or the site looks broken. Check it against the actual folder name.
• Missing parent style enqueue. If the site loads with no styling after you activate the child, you almost certainly skipped the enqueue function in functions.php. Add it and the design returns.
• Editing the parent anyway. Creating a child theme but then editing the parent's files defeats the purpose. Always make your changes in the child, including copied template files.
• Copying the whole parent functions.php. The child's functions file adds to the parent's, it does not replace it. Copying the entire file causes duplicate function errors. Add only the functions you need.
• A white screen after editing functions.php. A single typo in PHP can blank the site. Add code in small steps, keep a backup, and if it goes white, remove your last change through the file manager to recover.
• Caching hiding your changes. If edits do not appear, a caching plugin or your browser may be serving old files. Clear the cache and version your styles so updates are picked up.

None of these are hard to fix, and most reveal themselves the moment you activate the theme. If you build on a staging copy and keep a backup, even a mistake that blanks the site is a minor inconvenience rather than an emergency, because you can restore or roll back in minutes.

When to Get Help

A basic child theme is well within reach for anyone willing to touch a couple of files, and doing it yourself is a genuinely useful skill. But there is a point where a child theme stops being a two file exercise and becomes real development: heavy template overrides, custom functions that change how the site behaves, block theme customizations through theme.json, or a design that needs to hold up across updates and future changes. That is the point where having a developer do it saves time and prevents the subtle bugs that come from copied templates drifting out of sync with the parent.

We build and maintain WordPress themes and child themes every day. We can create a properly structured child theme, move your existing customizations into it so future updates stop erasing your work, build the template overrides and functions your design needs, and keep everything current over time. Because we work in code rather than only in plugins, we can go deeper and keep things clean, which matters most on the sites a business actually depends on.

If you want your customizations done the right way, you can get a free quote and we will tell you honestly what your site needs. You can also book a free consultation to talk it through, or read more about our WordPress development services and how we approach theme work. A child theme is a small thing that prevents a lot of pain, and getting it right once means never losing your customizations to an update again.