WordPress Child Theme Not Working? Fix CSS Not Loading

TL;DR: WordPress never enqueues a child theme’s style.css automatically — it only reads the Template: line for template fallback and stops. You have to call wp_enqueue_style() yourself inside a function hooked to wp_enqueue_scripts in the child’s functions.php. If the stylesheet loads but your rules still lose, pass the parent theme’s real stylesheet handle as a dependency so the child file loads after it in the cascade. Skip @import — it’s slower and isn’t how the current enqueue is documented.

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 — this isn’t a WordPress quirk, it’s the CSS cascade spec itself: W3C’s Cascade and Inheritance spec states plainly that “the last declaration in document order wins” once origin, importance and specificity are tied. 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 already enqueue their own stylesheet under a specific handle. You need that exact string — grep the parent theme, or read it off the <link id="...-css"> in view source (drop the trailing -css). The handles named in this guide are the ones referenced in each theme’s own public source; if your parent isn’t on this short list, view source is the reliable way to get the real string rather than guessing:

Parent theme	Stylesheet handle to use as the dependency
Astra	astra-theme-css
GeneratePress	generate-style (not generate-style-css — a common guess that doesn’t match the real handle)
Twenty Twenty-Four	twenty-twenty-four-style
Any other theme	Read it from <link id="...-css"> in view source — drop the trailing -css

Note the table itself is proof of the problem: three well-known themes use three different handle strings for the same job. There’s no universal 'parent-style' handle to hardcode — that’s exactly the Codex-era mistake covered below.

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. The current WordPress Developer Handbook page on child themes doesn’t even mention @import; every one of its own examples enqueues with wp_enqueue_style() instead. If your tutorial told you to use @import, 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. The WordPress Developer Handbook’s own child-theme page says loading style.css is “often not needed for block themes because their style handling is generally done via” theme.json, and its walkthrough uses Twenty Twenty-Four as an example of a theme that “doesn’t load a stylesheet at all” — so if your child theme’s CSS isn’t loading and the parent is a block theme, check whether there’s anything to enqueue before chasing the dependency-order fix above. The same page also notes block themes add extra layers on top of the parent/child split — WordPress’s own default theme.json, the parent theme’s, the child theme’s, and the site editor’s user customizations, which it says “can override theme.json, templates, and patterns” and are stored in the database rather than the filesystem. I’d still trust this less than the classic-theme fix above and test it directly on your own site rather than assume it’s the whole answer.

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.

To be upfront about what this screenshot does and doesn’t prove: it’s a real test of a wrong Template: line, which is a different, smaller bug than this guide’s main topic (a missing or mis-ordered enqueue). We don’t have a real before/after screenshot of the enqueue fix itself — showing that honestly rather than staging one. The fastest way to check your own case for free is the view-source step above: search the page source for your child theme’s folder name and confirm whether its <link id="...-css"> is present and loads after the parent’s.

Sources

• WordPress Developer Resources: Child Themes — Advanced Topics
• W3C: CSS Cascading and Inheritance Level 4 — Cascade Sorting Order