Skip to content
Themes

WordPress Child Theme Styles Not Loading

Your child theme's style.css is not loading because WordPress does not enqueue it for you. The child theme's stylesheet has to be registered by hand in the

Published

Your child theme’s style.css is not loading because WordPress does not enqueue it for you. The child theme’s stylesheet has to be registered by hand in the child theme’s functions.php, and that enqueue almost always has one of two bugs: it isn’t there at all, or it loads without declaring the parent stylesheet as a dependency, so your rules land in the wrong place in the cascade and get overridden. Fix the enqueue and the styles come back. The old @import trick you probably copied from a 2013 tutorial is the wrong fix.

Why it happens

A classic child theme is two required files: a style.css with a header block naming the parent, and a functions.php. The header’s Template: line tells WordPress which parent to inherit templates from. That is the only thing WordPress does automatically. It reads the header, wires up template fallback, and stops. It never enqueues your child style.css on the front end.

The parent theme, meanwhile, enqueues its stylesheet from its functions.php, hooked to wp_enqueue_scripts. Your child functions.php runs first, then the parent’s, then everything on that hook fires. If your child never calls wp_enqueue_style for its own file, the browser never requests it. The page looks like the raw parent theme because that is exactly what it is.

The second failure is subtler. You enqueue the child stylesheet, it loads, but your overrides do nothing. That is a load-order problem. When two rules have equal specificity, the one that loads last wins. If your child CSS loads before the parent’s, the parent wins every tie. The dependency array on wp_enqueue_style is what forces order.

One more thing people get wrong: get_template_directory_uri() points at the parent theme folder, and get_stylesheet_directory_uri() points at the active (child) theme folder. Swap them and you enqueue the parent’s style.css a second time and never touch the child’s.

The fix, in order

First, confirm what’s actually loading. Open the broken page, view source, and search for your child theme folder name. WordPress renders enqueued styles as <link id="handle-css" href="..."> — the id is your handle plus -css. If your child style.css isn’t in the <head> at all, the enqueue isn’t running. If it is there but styles don’t apply, it’s a dependency/order problem. This one check tells you which of the two bugs you have.

Second, find the parent’s real handle. Most modern themes (Astra, GeneratePress, the Twenty-* themes) already enqueue their own stylesheet under a specific handle — astra-theme-css, generate-style-css, twenty-twenty-four-style, and so on. You need that exact string. Grep the parent theme, or read it off the <link id="...-css"> in view source (drop the trailing -css).

Third, write the enqueue. For the common case where the parent already loads its own stylesheet, you do not re-enqueue the parent. You only enqueue the child, and list the parent’s handle as a dependency so yours loads after it:

<?php
add_action( 'wp_enqueue_scripts', 'child_enqueue_styles', 20 );

function child_enqueue_styles() {
    wp_enqueue_style(
        'child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array( 'astra-theme-css' ), // <-- the parent's REAL handle
        wp_get_theme()->get( 'Version' )
    );
}

If the parent theme does not enqueue its own stylesheet (some older or minimal themes rely on @import), then enqueue both, and make the child depend on the parent:

<?php
add_action( 'wp_enqueue_scripts', 'child_enqueue_styles' );

function child_enqueue_styles() {
    wp_enqueue_style(
        'parent-style',
        get_template_directory_uri() . '/style.css'
    );
    wp_enqueue_style(
        'child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array( 'parent-style' ),
        wp_get_theme()->get( 'Version' )
    );
}

The wp_get_theme()->get('Version') argument is your cache-buster. Bump the Version: line in the child’s style.css header and browsers refetch. Skip it and you’ll edit CSS and swear nothing is changing when it’s just cached.

If functions.php has a syntax error, the whole file dies silently and none of your enqueues run — that presents exactly like “styles not loading.” Turn on WP_DEBUG, or paste your debug.log into our WordPress error log decoder to spot the fatal fast.

What not to do

Don’t use @import. The Codex-era advice was to put @import url("../parenttheme/style.css"); at the top of the child style.css. It works, but it’s slow — the browser can’t start downloading the parent CSS until it has parsed the child CSS, so the two requests run in series instead of parallel. WordPress’s own handbook has recommended against it for years. If your tutorial told you to do this, that tutorial is why your styles are janky.

Don’t hardcode the handle 'parent-style' and enqueue the parent file blind. The famous Codex snippet does exactly this, and it’s wrong for any theme that already registers its stylesheet under a different handle. You end up loading the parent CSS twice and your dependency points at a handle that may not exist.

Don’t call wp_enqueue_style at the top level of functions.php. It has to run inside a function hooked to wp_enqueue_scripts. Called too early, it does nothing.

Don’t copy the parent’s whole functions.php into the child. They both load; the child’s runs first. Copying it causes duplicate function declarations and a fatal error.

One caveat: this is all about classic (PHP-template) themes. If your parent is a block theme, styling flows mostly through theme.json and the Site Editor, and style.css overrides behave differently — I’d trust that less and test it directly rather than assume this enqueue is the fix.

Still stuck?

Confirm the child’s style.css header Template: line exactly matches the parent’s folder name, case-sensitive — not the parent’s display name. Then re-check view source: handle present, loading after the parent, version query string bumped. If the <link> is there, loading last, and the CSS still doesn’t apply, it’s no longer an enqueue problem — it’s specificity, and the fix moves into the rules themselves.