How to Create a WordPress Child Theme, Step by Step

What Is a Child Theme

A WordPress child theme is a theme that depends on another theme, called the parent, for most of its design and function. The child theme sits in its own folder with just a few files, and it borrows everything else from the parent. When a page loads, WordPress checks the child theme first for each file, then falls back to the parent when the child does not have its own version. That simple rule is the whole idea behind child themes.

Think of it as a thin layer on top of an existing theme. The parent supplies the templates, the layout, and the base styles. The child supplies your changes. You might add a few lines of CSS, swap out one template, or register a custom function. Everything you do not touch stays exactly as the parent author built it, and everything you do touch lives safely in the child.

The relationship is defined in one file. Your child theme style.css includes a special header that names the parent through a Template line. That single line tells WordPress which theme to treat as the parent, and from there the inheritance takes over. Without it, WordPress would not know the two themes are connected.

A quick analogy

Imagine renting a furnished apartment. The furniture, the paint, and the appliances come with the place, and that is the parent theme. You bring a few of your own things, a rug, some art, a lamp, and those are your child theme changes. When the landlord repaints or replaces the couch during a renewal, your own items are untouched because they were never part of the original fittings. A child theme gives your site that same separation between what came with the theme and what you added.

What lives in a child theme

A child theme can be as small as two files or as large as a full custom design. At minimum it holds a style.css with the theme header and a functions.php that loads the styles. From there you add only what you want to change. Some sites keep a child theme with nothing more than a handful of CSS rules and one or two functions. Others build up copied templates, custom template parts, extra stylesheets, and JavaScript files over time. The point is that the child theme grows to fit your needs while the parent stays untouched underneath it.

How inheritance actually behaves

The inheritance is not a copy. WordPress does not duplicate the parent files into the child. Instead, at the moment a page loads, WordPress decides which file to use for each part of the page. For templates, it looks in the child folder first and uses the parent only when the child has no matching file. For styles, both stylesheets load, and the child loads last so its rules can win. For functions, both functions.php files run. Understanding these three behaviors, template fallback, style order, and function loading, explains almost everything a child theme does.

Why Use a Child Theme

The main reason is safe updates. Themes get updated to fix bugs, patch security holes, and add features. When you edit a parent theme directly and then run an update, WordPress replaces the theme files with the new version and your edits are gone. People discover this the hard way, usually the morning after an update, when a customization they spent hours on has vanished. A child theme keeps your work in a separate folder that updates never overwrite.

The second reason is organization. All of your custom code lives in one predictable place. Six months from now, when you or another developer needs to find a change, it is in the child theme rather than buried in a parent file among thousands of lines you did not write. That clarity saves time and prevents mistakes.

The third reason is confidence. Because your changes are isolated, you can experiment freely. If a customization goes wrong, you switch back to the parent theme, fix the child, and switch again. You are never one bad edit away from breaking a theme you cannot easily restore.

There is a fourth reason that matters for teams and agencies: handover. When a site uses a child theme, a new developer can open one folder and see every custom decision that was made. There is no need to hunt through a large parent theme for a modified line. This makes maintenance faster and cheaper, and it lowers the risk that someone misses a change when they update the site. On sites we take over from other builders, the presence of a clean child theme is one of the first things that tells us the site was set up with care.

What you can safely put in a child theme

Almost any custom code belongs in the child theme rather than the parent. Custom CSS goes in the child style.css. Custom PHP, such as registering a menu, adding an image size, or adjusting an excerpt length, goes in the child functions.php. Template changes go in copied template files inside the child. Even small assets like a custom font or an extra script can live in the child folder and be loaded from functions.php. If it is your change and not the theme author's, it belongs in the child.

Editing the parent directly versus using a child theme

The table below compares the two approaches so the trade off is clear.

The small setup effort of a child theme pays for itself the first time the parent theme updates. If you plan to keep a site for more than a season, a child theme is the sensible default. Want this set up correctly on your site? You can get a free quote and we will handle it.

Before You Start

A child theme is not hard to build, but a little preparation makes the process smooth. Gather a few things and confirm a couple of facts before you write any code.

Know your parent theme folder name

Every theme lives in a folder inside wp-content/themes. You need the exact folder name of the parent, not its display name. For example, the Twenty Twenty-Five theme uses the folder name twentytwentyfive. This folder name is the value you will put in the Template line of your child theme header, and it must match exactly, including lowercase letters and no spaces.

Decide how you will add files

You have a few ways to create the child theme folder and files. Pick whichever suits your access and comfort.

• SFTP or FTP: connect to your host and create the folder and files directly on the server. This is the classic method and works everywhere.
• Hosting file manager: many hosts include a file manager in their control panel that lets you create folders and edit files in the browser.
• Local development: build the theme on your computer with a local WordPress install, then upload it. This is the safest option for larger changes.
• Child theme plugin: a plugin can generate the files for you if you prefer not to create them by hand.

Back up first

Before changing anything on a live site, take a full backup of files and the database, or work on a staging copy. Creating a child theme is low risk, but activating a new theme is a good moment to have a safety net. Good backups are part of ongoing care, which we cover in our WordPress maintenance services guide.

Have a code editor ready

You will write a small amount of CSS and PHP. Any plain text editor works, but a proper code editor with syntax highlighting makes the header comments and PHP easier to read and reduces typos. Avoid word processors, which can add hidden formatting that breaks code.

Confirm the parent theme stays installed

One rule people forget: a child theme needs its parent theme to remain installed on the site. The child borrows the parent files, so if you delete the parent, the child theme breaks. You do not activate the parent, you just leave it installed alongside the child. When the parent releases an update, you update it as normal, and your child theme keeps working on top of the new version. Keeping both themes present is what makes the whole arrangement work.

Create a Child Theme Step by Step

Here is the full process for a classic theme. It comes down to a folder, a stylesheet with a special header, a functions file that loads the styles, an optional screenshot, and activation. Follow the steps in order.

Step 1: Create the child theme folder

Inside wp-content/themes, create a new folder for your child theme. A clear convention is to name it after the parent with a child suffix. If the parent folder is twentytwentyfive, name the child folder twentytwentyfive-child. Use lowercase letters and hyphens, and avoid spaces.

The folder path will look like this: wp-content/themes/twentytwentyfive-child. This empty folder is your child theme home. Everything you add from here lives inside it.

Step 2: Add the style.css header

Create a file named style.css inside the child theme folder. At the top of that file, add a comment block that tells WordPress this is a theme and which parent it belongs to. The most important line is Template, which must match the parent folder name exactly.

/*
Theme Name:   Twenty Twenty-Five Child
Theme URI:    https://example.com/twentytwentyfive-child
Description:  A child theme of Twenty Twenty-Five for safe customizations.
Author:       Your Name
Author URI:   https://example.com
Template:     twentytwentyfive
Version:      1.0.0
Text Domain:  twentytwentyfive-child
*/

/* Add your custom CSS below this line */

A few notes on these fields. Theme Name is the display name you will see in the WordPress themes screen. Template is the parent folder name and is the one line you cannot get wrong. Version is your child theme version and is useful for cache busting later. The rest are informational. If the Template line does not match the parent folder name, WordPress will show an error and refuse to activate the child theme, so double check it.

Step 3: Enqueue the parent and child styles in functions.php

In the past, people used an @import line in style.css to load the parent stylesheet. That method is slow and no longer recommended. The correct approach is to load styles with functions.php using the WordPress enqueue system. Create a file named functions.php in your child theme folder and add the following.

<?php
/**
 * Load parent and child theme stylesheets.
 */
add_action( 'wp_enqueue_scripts', 'wpd_child_enqueue_styles' );

function wpd_child_enqueue_styles() {

    // Load the parent theme stylesheet.
    wp_enqueue_style(
        'parent-style',
        get_template_directory_uri() . '/style.css'
    );

    // Load the child theme stylesheet, after the parent.
    wp_enqueue_style(
        'child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array( 'parent-style' ),
        wp_get_theme()->get( 'Version' )
    );
}

This code hooks into wp_enqueue_scripts, the correct action for loading front end styles. It loads the parent stylesheet first, then the child stylesheet with the parent set as a dependency through the array( 'parent-style' ) argument. That dependency guarantees the child styles load after the parent, so your rules can override the parent rules. The version value pulled from wp_get_theme helps browsers pick up new styles when you change the version number.

Understanding the two directory functions

The two functions in that code are easy to mix up, and getting them right matters.

• get_template_directory_uri() points to the parent theme folder. Use it to load parent assets such as the parent stylesheet.
• get_stylesheet_directory_uri() points to the active theme folder, which is the child when a child theme is active. Use it to load your own child theme assets.

A simple way to remember it: template means parent, stylesheet means child. When you want something from your own child folder, reach for the stylesheet function.

Step 4: Add a screenshot

Add an image named screenshot.png to the child theme folder. WordPress shows this image as the theme thumbnail on the Appearance themes screen. A common size is 1200 by 900 pixels. This step is optional and does not affect how the site works, but it makes the child theme easy to spot in the admin, which is helpful when a site has several themes installed.

Step 5: Activate the child theme

In the WordPress admin, go to Appearance, then Themes. You should see your child theme with the name from the header. Hover over it and click Activate. Because the child inherits the parent design, the front end should look the same as before. Open your site in a new tab and confirm nothing changed. If it looks identical, the child theme is working correctly and you are ready to customize.

Step 6: Test with a small change

Prove the setup works by adding one visible style rule to the child style.css, below the header comment.

/* Add your custom CSS below this line */

body {
    background-color: #f7f7fb;
}

a {
    text-decoration: underline;
}

Save the file and reload the site. If the background color and link style change, your child stylesheet is loading and overriding the parent as expected. You now have a working child theme and a safe place for every future change. The files you have created are summarized below.

Override Parent Template Files

Styles handle appearance, but sometimes you need to change structure or markup, and that means editing a template file. This is where the child theme really shows its value. You never edit the parent template. Instead, you copy the file you want to change into the child theme and edit the copy.

How template overrides work

WordPress builds each page using a template file, such as single.php for a single post or page.php for a page. When rendering, WordPress looks in the active theme, which is the child, for that template. If it finds the file in the child theme, it uses that version and ignores the parent version. If it does not find the file in the child, it uses the parent file. That fallback is what lets you override only the templates you care about while leaving the rest to the parent.

Steps to override a template

• Find the template file in the parent theme folder, for example wp-content/themes/twentytwentyfive/single.php.
• Copy that file into your child theme folder at the same relative path, so it becomes wp-content/themes/twentytwentyfive-child/single.php.
• Edit the copy in the child theme to make your change.
• Reload the matching page and confirm your change appears.

Keep the same file name and folder structure in the child as the parent uses. If a parent template sits inside a subfolder such as template-parts, recreate that subfolder in the child and place your copy there. WordPress matches templates by path, so the structure has to line up.

Copy only what you need

Resist the urge to copy the whole parent theme into the child. Copy just the files you plan to edit. Every template you copy becomes a file you now maintain. If the parent later improves that template, your copy will not get the improvement automatically, so fewer copied files means less to review after updates. When you only need small tweaks, prefer CSS in style.css or a function in functions.php over copying a template.

A note on functions.php overrides

The functions.php file behaves differently from templates. A child template replaces the parent template, but a child functions.php does not replace the parent functions.php. WordPress loads both files, and it loads the child one first. This means you add functions in the child without losing the parent functions. To change how a parent function behaves, use WordPress hooks, filters, and actions rather than trying to redefine the parent code. This keeps your changes clean and update safe.

A practical override example

Suppose the parent theme shows the full post content on the blog listing and you want a short excerpt instead. Rather than copy the whole index template, you can often change the length of the excerpt with a small filter in the child functions.php.

<?php
/**
 * Shorten the automatic excerpt length.
 */
add_filter( 'excerpt_length', 'wpd_child_excerpt_length' );

function wpd_child_excerpt_length( $length ) {
    return 30; // words
}

This is a good illustration of the general rule. The change is small, it targets one behavior, and it lives in the child theme where an update cannot erase it. Only when a hook or filter cannot reach what you need should you fall back to copying the template itself.

Loading extra scripts and styles from the child

If a customization needs its own stylesheet or a small script, keep those files in the child folder and load them from functions.php with the enqueue system. Use get_stylesheet_directory_uri to point at the child folder. For example, you might add a file at assets/custom.css in the child theme and enqueue it after the main child style so its rules apply last. Keeping assets inside the child theme means they move with the theme and stay under version control, rather than being scattered around the site.

Safe Customization Practices

A child theme gives you a safe place to work, but good habits keep it that way. These practices come from maintaining many WordPress sites over the years, and they prevent the small problems that turn into big ones.

Prefer hooks over copying templates

Many changes that seem to need a template edit can be done with an action or filter hook in functions.php. Hooks let you add or change output without copying and maintaining a whole template. Because a hook targets one specific point, it survives parent updates far better than a full template copy. Reach for a template override only when a hook cannot do the job.

Comment your code

Add a short comment above each customization explaining what it does and why. Future you, or the next developer, will thank you. A one line note turns a mysterious block of code into a clear, intentional change. This is especially valuable in functions.php where several unrelated snippets often gather over time.

Use the version number for cache busting

When you change your child theme styles, bump the Version number in the style.css header. Because the enqueue code pulls that version into the stylesheet URL, browsers and caches see a new file and load your latest CSS. Without this, visitors can keep seeing old styles from their cache after you make a change.

Test on staging before going live

Make changes on a staging copy of the site first, confirm they work, then move them to live. This is the single best way to avoid breaking a site people rely on. A good host makes staging easy. If yours does not, a local copy works too. Careful testing is a core part of keeping a site healthy, alongside performance work and regular updates.

Keep changes small and focused

Make one change at a time and check the result before moving on. If something breaks, you know exactly which change caused it. Large batches of edits are hard to debug because any one of them could be the problem. Small steps keep you in control.

Do not use the built in theme editor for real work

The Appearance code editor inside WordPress lets you edit theme files in the browser, but it saves directly to the live site with no undo and no backup. A syntax error there can take the whole site down. Edit files through SFTP or a local editor instead, where a mistake is easy to reverse. If you want a safer, managed setup, our team can put proper workflows in place, and you can get a free quote to start.

Keep the child theme under version control

If you are comfortable with it, put the child theme in a version control system such as Git. This gives you a full history of every change, the ability to roll back a single edit, and a clear record of who changed what and when. For a small site this may be more than you need, but for a business site with ongoing work it turns your child theme into a well documented, recoverable asset. Even a simple approach, committing after each meaningful change, is a big step up from editing files with no history at all.

Name and group your customizations

As functions.php grows, group related snippets together and give each group a clear comment heading. Prefix your function names with something specific to the site, as the example code does with the wpd underscore prefix, so they never clash with a parent or plugin function of the same name. These small naming habits prevent the kind of silent conflicts that are hard to track down later.

Common Child Theme Mistakes

Most child theme problems come from a handful of avoidable errors. Knowing them ahead of time saves a lot of confusion.

Wrong Template name in the header

The Template line in style.css must match the parent folder name exactly, character for character. A capital letter where there should be a lowercase one, or the display name instead of the folder name, will stop the child theme from activating. When WordPress complains that the parent theme is missing, this line is almost always the cause. Open the parent folder, copy its exact name, and paste it into the Template line.

Forgetting to enqueue the parent styles

If your site loads with no styling after you activate the child theme, the parent stylesheet is probably not being loaded. Check that functions.php exists in the child theme, that the enqueue code is present, and that there are no typos in the function names. Remember that the parent style must load, either through your enqueue code or because the parent theme enqueues its own styles internally, which some modern themes do.

Using @import instead of enqueue

Older tutorials tell you to load the parent stylesheet with @import in style.css. This works but is slow because the browser has to download one stylesheet before it even discovers the next. Use the functions.php enqueue method shown earlier instead. It is faster and is the current standard.

Copying the entire parent theme

Duplicating every parent file into the child defeats the purpose. You end up maintaining a full second copy of the theme, and parent updates no longer reach the files you copied. Copy only the specific templates you need to change, and nothing more.

Editing the parent theme by habit

After setting up a child theme, it is easy to forget and edit a parent file out of habit, especially through the admin code editor. Make a rule for yourself and your team: all changes go in the child theme. If you catch a change in a parent file, move it to the child before the next update erases it.

Not checking after a parent update

Templates you copied into the child can drift from the parent over time. After a major parent update, open your copied templates and compare them against the new parent versions. If the parent added an important fix or field to a template you copied, bring that change into your copy. This small review keeps overridden templates from falling behind.

Ignoring caching after changes

If a change does not appear after you save, a cache is often the reason. Bump the child theme version, clear any caching plugin, and clear your browser cache. Many support tickets that begin with my change is not showing end with a simple cache clear.

Placing the closing PHP tag in functions.php

A subtle mistake is adding a closing PHP tag at the end of functions.php. If any blank line or space follows that closing tag, WordPress can throw a headers already sent warning. The safe convention is to leave the closing tag off entirely in PHP only files. Start the file with the opening tag and simply end after your last line of code. This avoids a whole class of confusing errors.

Assuming the parent will always enqueue its own styles

Some modern themes load their own stylesheet internally, so a child theme may not need to enqueue the parent style at all. Others expect the child to load it. If you copy enqueue code from a tutorial without checking, you can end up loading the parent stylesheet twice or not at all. When you set up the child theme, load the front end, view the page source, and confirm the parent and child stylesheets each appear exactly once. A minute of checking here prevents styling bugs that are otherwise hard to explain.

Block Themes vs Classic Themes

WordPress now has two broad kinds of themes, and the child theme approach differs a little between them. Understanding which type you have tells you how much of a child theme you actually need.

Classic themes

Classic themes use PHP template files such as header.php, single.php, and page.php, along with the Customizer for settings. This is the model the steps above are built for. If your theme relies on PHP templates and the Customizer, follow the classic child theme process: style.css header, functions.php enqueue, and template copies as needed.

Block themes

Block themes, also called full site editing themes, use HTML template files and a theme.json file instead of PHP templates for much of the layout. You edit them through the Site Editor in the WordPress admin, and many of your changes, such as colors, typography, and template edits, are stored in the database rather than in theme files. Because of that, a lot of what once required a child theme can now be done in the editor and kept safely without one.

When a block theme still needs a child

You still want a child theme for a block theme in several cases. If you need custom PHP functions, a child functions.php is the right home. If you want version controlled template or template part files rather than database edits, a child theme lets you ship them as files. If you need to override theme.json settings in a way that survives parent updates, a child theme with its own theme.json does the job. The style.css header and Template line work the same way for block themes as for classic ones.

How to tell which you have

A quick way to check is the WordPress admin. If you see a full Site Editor under Appearance with the ability to edit templates visually, you are on a block theme. If you see a Customizer and Widgets instead, you are on a classic theme. Some themes sit in between, so when in doubt, look at whether the theme uses a templates folder with HTML files, which signals a block theme.

Overriding theme.json in a block child theme

Block themes centralize colors, fonts, spacing, and layout in a theme.json file. When you want to change these values in a way that survives updates, add your own theme.json to the child theme. WordPress merges the child theme.json on top of the parent one, so you only need to include the settings you are changing rather than the entire file. This is the block theme equivalent of adding a few CSS rules to a classic child theme, and it keeps your design decisions in a versioned file rather than only in the database. Template and template part HTML files work the same way, living in templates and parts folders inside the child theme.

Mixing editor changes and child theme files

On a block theme you will often use both approaches together. Everyday design tweaks happen in the Site Editor and save to the database, which is quick and needs no child theme. Structural or code level changes, and anything you want tracked as a file, go into the child theme. Knowing where each kind of change belongs keeps the site tidy and makes it clear where to look when something needs adjusting later.

Which approach is right for you

The decision comes down to what you need to change and how permanent it must be. Design tweaks on a block theme often need no child theme at all. Custom code, file based templates, and update safe overrides still point to a child theme on either type. If you are planning a new site, our guide to making a WordPress website walks through choosing a theme, and our services cover the build if you want a hand.

A child theme is one of those small habits that pays off for the entire life of a site. It costs a few minutes to set up and it protects every customization you make from that point on. Whether you run a classic theme or a modern block theme, giving your changes a safe home is worth the effort. If you would like us to set up a child theme, migrate your existing edits into it, or take over ongoing care of your site, we are ready to help. Get a free quote and we will make sure your customizations are safe for the long run.