WordPress Child Theme Checklist: Every File You May Need to Override

Overview

A WordPress child theme lets you customize the behavior and presentation of a parent theme without editing the parent theme directly. That matters because direct parent theme edits are usually overwritten the next time the parent updates. A child theme gives you a safer place to store your changes.

That said, not every customization belongs in a copied template file. One of the most common sources of maintenance trouble is overriding too much. If you copy large template files into a child theme for small design tweaks, you increase the chance that future parent theme improvements, bug fixes, or compatibility changes will not reach your site.

Use this rule of thumb before you start:

• Use CSS when you only need visual changes.
• Use functions.php when you can change behavior with hooks, filters, script loading, image sizes, or theme support options.
• Override template files only when markup or template structure truly needs to change.
• Use a custom plugin instead for functionality that should survive a theme switch, such as custom post types, shortcodes, or business rules.

At minimum, most child themes start with these files:

• style.css
• functions.php
• screenshot.png (optional but helpful for admin clarity)

A very simple style.css needs the child theme header and the correct parent theme reference:

/*
Theme Name: My Child Theme
Template: parent-theme-folder
*/

Your functions.php is usually where you enqueue child styles and add lightweight customizations:

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

    wp_enqueue_style(
        'child-style',
        get_stylesheet_uri(),
        array('parent-style'),
        wp_get_theme()->get('Version')
    );
});

Important detail: a child theme functions.php does not replace the parent version. It loads in addition to it. Template files are different: when you copy a supported template file into the child theme using the same relative path and filename, the child version usually takes precedence.

If you are still deciding whether a child theme is the right approach, see Child Theme vs Custom Theme: Which WordPress Approach Makes Sense in 2026?.

Checklist by scenario

This section is the working checklist. Return to it when starting a project or troubleshooting a broken override.

1. Basic design tweaks only

Files you may need:

• style.css
• Optionally a small functions.php for enqueued assets

Checklist:

• Confirm the parent theme is active-ready and supports child themes normally.
• Create style.css with the proper theme header.
• Check that the Template value exactly matches the parent theme folder name.
• Enqueue styles in functions.php if needed.
• Use the browser inspector before copying any template file.
• Prefer CSS overrides over HTML or PHP template duplication.

Common use cases: spacing changes, typography adjustments, color updates, button styles, mobile layout fixes, and header or footer styling that does not require markup changes.

2. Adding scripts, removing parent styles, or changing theme behavior

Files you may need:

• functions.php

Checklist:

• Add custom actions and filters in the child theme functions.php.
• Check whether the parent theme already provides hooks for your change.
• Use a hook or filter before overriding a whole template.
• Enqueue JavaScript and CSS properly rather than hardcoding tags into templates.
• Keep code grouped by purpose and comment each customization.

Typical tasks:

• Registering menus or widget areas
• Changing excerpt length
• Removing unwanted scripts
• Adding custom body classes
• Modifying WooCommerce hooks
• Adjusting image sizes or support flags

If you need help identifying hook-based alternatives, see WordPress Hooks and Filters Reference for Theme and Plugin Customization.

3. Overriding header, footer, or sidebar layout

Files you may need:

• header.php
• footer.php
• sidebar.php
• Sometimes partials such as template-parts/header/*.php

Checklist:

• Check whether the parent theme uses classic template files or block theme parts.
• Inspect the parent theme structure before copying files.
• Copy only the exact file you need to change.
• Preserve essential WordPress hooks such as wp_head() and wp_footer().
• Do not remove accessibility markup, navigation hooks, or schema-related output unless you understand the impact.

Watch for: analytics code, menu walker classes, mobile menu triggers, search overlays, and hook locations that scripts rely on.

4. Overriding page templates or single post layouts

Files you may need:

• page.php
• single.php
• archive.php
• index.php
• home.php
• front-page.php
• search.php
• 404.php

Checklist:

• Confirm where the requested content fits in the WordPress template hierarchy.
• Check whether a more specific template already exists in the parent theme.
• Copy the smallest relevant file instead of changing a broad fallback file.
• Retain core loop logic unless you intentionally want different query output.
• Test blog posts, pages, archives, search results, and error pages separately.

Good example: if you only want to change blog post markup, override single.php or a post content partial rather than copying index.php and changing everything there.

5. Working with template parts

Files you may need:

• template-parts/content.php
• template-parts/content-single.php
• template-parts/content-page.php
• Theme-specific partials in subfolders

Checklist:

• Find out whether the parent theme uses get_template_part().
• Locate the exact partial rendering the content you want to change.
• Copy the same folder structure into the child theme.
• Preserve required classes and wrapper elements used by CSS or JavaScript.
• Re-test related layouts after changing a shared partial.

Why this matters: template parts are often the safest override target because they are narrower than full-page templates. If your parent theme is modular, changing one partial may be cleaner than overriding an entire layout file.

6. WooCommerce template overrides

Files you may need:

• woocommerce/archive-product.php
• woocommerce/single-product.php
• woocommerce/cart/cart.php
• woocommerce/checkout/*.php
• woocommerce/myaccount/*.php

Checklist:

• Place WooCommerce overrides in a woocommerce folder inside the child theme.
• Copy the correct template path from the plugin or parent theme integration layer.
• Check WooCommerce template version notices after plugin updates.
• Use hooks where possible before overriding full commerce templates.
• Test cart, checkout, account pages, taxes, coupons, and mobile behavior.

Caution: WooCommerce templates change over time, so they deserve extra maintenance attention. Small checkout edits often age badly if they depend on copied templates.

7. Custom page templates

Files you may need:

• A new file such as page-landing.php
• Optional matching CSS and JS assets

Checklist:

• Create a custom page template with a proper template header if needed.
• Use this approach when you want a special layout without overriding global templates.
• Keep the file purpose-specific and avoid duplicating all parent theme logic unless necessary.
• Assign the template to a test page before using it on production content.

This is often cleaner than modifying page.php when you only need one landing page or one content format.

8. Screenshots, assets, and organization

Files you may need:

• screenshot.png
• /assets/css/
• /assets/js/
• /assets/images/

Checklist:

• Add a recognizable screenshot so the child theme is easy to identify in admin.
• Store custom assets in organized folders.
• Enqueue assets with versioning to reduce caching confusion.
• Document which files are overrides and which are net-new additions.

Even on small projects, clean file organization makes future updates far easier.

9. Block themes and full site editing

Files you may need:

• theme.json
• templates/*.html
• parts/*.html
• Optional patterns or stylesheets

Checklist:

• Confirm that you are working with a block theme, not a classic theme.
• Look for templates and parts directories instead of classic PHP templates.
• Use child-theme overrides carefully because structure differs from classic theming.
• Check whether your changes belong in theme.json, the Site Editor, or an HTML template override.

If your workflow mixes classic assumptions with block theme files, troubleshooting gets confusing fast. Identify the theme type first.

What to double-check

Before you consider a child theme complete, run through this short audit. It will prevent many of the issues that surface later after updates or redesign work.

• Folder paths match exactly. For template overrides to work, the child theme file path usually needs to mirror the parent path.
• The parent folder name is correct in style.css. A wrong Template value breaks the child theme setup.
• You kept essential hooks. Missing wp_head(), wp_footer(), or commerce hooks can break scripts, styles, and plugin behavior.
• You did not override more than needed. If one hook or partial solves the issue, remove unnecessary copied files.
• Comments explain why the override exists. A note at the top of each copied file saves time months later.
• Responsive behavior still works. Test desktop, tablet, and mobile layouts after each override.
• Template hierarchy still makes sense. Make sure your intended template is actually the one loading.
• Plugin integrations still render correctly. Membership, SEO, forms, multilingual, and commerce plugins often rely on predictable markup or hooks.
• Performance has not regressed. Avoid loading duplicate CSS, duplicate JS, or large assets that the parent theme already handles more efficiently.

For visual-heavy sites, performance checks matter just as much as layout checks. If your customization introduces new images, scripts, or front-end effects, a practical companion read is High-Quality Product Imagery and 3D on WordPress Without Killing Page Speed.

Common mistakes

Most child theme problems come from a handful of repeatable mistakes. If an override is not behaving as expected, start here.

Copying entire templates for tiny changes

This is the biggest maintenance trap. If you only need to move one element or add one class, check for hooks, filters, CSS, or a narrower template part first.

Editing the parent theme anyway

Sometimes teams create a child theme and then still make “quick fixes” in the parent. That defeats the point. Keep all intended customizations in the child theme or in a site-specific plugin.

Forgetting that functions.php behaves differently from templates

A child theme template file overrides the parent version, but the child functions.php is loaded alongside the parent file. Treat it as an extension point, not a replacement.

Removing critical markup or hooks

Header and footer files often contain code that plugins and the WordPress admin bar expect. Removing it can cause subtle failures rather than obvious errors.

Ignoring parent theme updates

Once you override a file, you are partly responsible for maintaining that file. If the parent theme later updates the same template to fix compatibility or accessibility issues, your child copy will not inherit that automatically.

Using a child theme for site-wide functionality

If the logic should remain even after a theme change, it probably belongs in a custom plugin. This includes business logic, API integrations, reusable shortcodes, and content-related features.

Not testing edge cases

A single layout can behave differently for logged-in users, empty search results, password-protected posts, product variations, or long titles. Test more than the happy path.

When to revisit

This checklist is most useful when you return to it at predictable points in your workflow. Revisit your child theme overrides:

• Before parent theme updates to compare overridden files with the latest parent versions.
• After major plugin updates, especially WooCommerce or builder-related updates.
• Before redesign cycles to remove old overrides that are no longer needed.
• When switching development tools or workflows so asset loading and file organization stay clear.
• When troubleshooting layout issues after updates, because an old copied template is often the cause.
• During routine maintenance reviews to document why each override still exists.

A practical maintenance habit is to keep a simple override log with three columns: file name, reason for override, and last reviewed date. That turns a child theme from a pile of copied files into a maintainable system.

Before you start your next customization project, use this action list:

1. Identify the exact change you want.
2. Ask whether CSS alone can handle it.
3. If not, check for hooks and filters.
4. If hooks are not enough, find the smallest template or partial responsible.
5. Copy only that file into the child theme with the same path.
6. Comment the reason for the override.
7. Test on staging across key pages and devices.
8. Review the override again after the next parent update.

That process keeps your WordPress child theme setup lean, easier to debug, and far less fragile over time. And if your project is growing beyond selective overrides, it may be time to review whether a child theme is still the right long-term architecture.