WordPress CSS: Fixing Theme, Plugin and Builder Styles

Where WordPress CSS comes from

Before changing anything, it helps to know the usual suspects. On a classic or block theme site you will typically find these:

WordPress prints each enqueued stylesheet with an id made of its handle plus -css. A tag with id="contact-form-7-css" has the handle contact-form-7, which is the name you need to control it from code.

The CSS Checker lists your stylesheets with their sizes, flags render-blocking and unused CSS, and reports validation errors. On WordPress, that list is really a list of plugins, theme parts and builder files, so the first job is to put a name against each one.

Finding which plugin or theme adds each stylesheet

From the page source

Open a page, view source and search for stylesheet. The folder in each address tells you the owner: /themes/, /plugins/plugin-name/ or /uploads/ for builder files. Note the handle from each id. Repeat on a few templates, because some plugins only load on certain page types.

With Query Monitor

The free Query Monitor plugin adds a Styles panel to the admin bar that lists every enqueued stylesheet on the current page with its handle, source file, dependencies and version. It also shows which component registered it. Install it on a staging copy if you prefer not to run debugging tools on the live site.

In developer tools

The Network panel, filtered to CSS, shows each file's size and whether it arrived before first paint. The Coverage panel in Chrome shows how much of each file matched on the page. A contact form plugin stylesheet that is completely unused on your home page is an easy win.

Child themes: where your CSS belongs

Editing the parent theme's style.css works until the next theme update, which replaces the file and wipes your changes. A child theme is a small theme that inherits everything from the parent and holds only your changes, so updates leave it alone.

The minimum child theme

Create a folder such as /wp-content/themes/harbourview-child/ with a style.css that names the parent folder in its Template line:

/*
Theme Name: Harbourview Child
Template: harbourview
Version: 1.0.0
*/

.site-header { border-bottom: 1px solid #e5e7eb; }

Then add a functions.php that loads the child stylesheet after the parent, with a version taken from the file's modification time so browsers fetch the new copy whenever you save:

<?php
add_action( 'wp_enqueue_scripts', function () {
    wp_enqueue_style(
        'harbourview-child',
        get_stylesheet_uri(),
        array( 'harbourview-style' ),
        filemtime( get_stylesheet_directory() . '/style.css' )
    );
}, 20 );

Replace harbourview-style with the parent's real handle, which you found in the page source. Listing it as a dependency guarantees your file loads after the parent's, so equal-strength selectors in your file win. Some parent themes do not enqueue their own style.css and expect the child to do it; check the parent's documentation, and avoid enqueueing the same file twice.

Block themes

In block themes, much of the design lives in theme.json and the Site Editor's Styles panel rather than in a stylesheet. A child block theme can include its own theme.json that overrides colours, typography and spacing from the parent. Use that first for design tokens; use a child stylesheet for anything theme.json cannot express.

Additional CSS: fine for small things

The Additional CSS box in the Customizer or Site Editor is convenient, but its contents are printed inline in the head of every page and are tied to the active theme. A few lines are fine. Hundreds of lines belong in a child theme file, where they are cached by the browser and kept under version control.

The fix, step by step

Stopping plugin CSS loading on every page

Many plugins enqueue their stylesheet on every front-end page because they cannot know in advance where you will use them. A form plugin used only on the contact page, a slider used only on the home page, and a gallery used on two posts can together add several files to every page on the site.

Check for a built-in option first

Some plugins let you turn off their CSS or load it only where their shortcode or block appears. Contact Form 7, for example, supports a wpcf7_load_css filter to switch its stylesheet off completely, which is useful if you style forms yourself. Built-in options survive plugin updates better than your own code.

Dequeue conditionally from the child theme

<?php
add_action( 'wp_enqueue_scripts', function () {
    // Contact form styles: only on the contact page
    if ( ! is_page( 'contact' ) ) {
        wp_dequeue_style( 'contact-form-7' );
    }

    // WooCommerce styles: only on shop-related pages
    if ( function_exists( 'is_woocommerce' )
        && ! ( is_woocommerce() || is_cart() || is_checkout() || is_account_page() ) ) {
        wp_dequeue_style( 'woocommerce-general' );
        wp_dequeue_style( 'woocommerce-layout' );
        wp_dequeue_style( 'woocommerce-smallscreen' );
    }
}, 100 );

The late priority of 100 makes this run after plugins have enqueued their files. Use the handles you found on your own site; plugins change them occasionally, so recheck after major updates.

Plugins that manage this for you

Asset management plugins offer a per-page screen where you can unload stylesheets and scripts with checkboxes. They are a reasonable choice if you are not comfortable editing functions.php. Record what you unload, because those settings are easy to forget when something breaks months later.

Block editor, page builders and optimisation plugins

Block editor styles

Block themes load styles only for the blocks present on each page by default. Classic themes historically loaded the whole block library stylesheet on every page. You can change that in the child theme:

<?php
add_filter( 'should_load_separate_core_block_assets', '__return_true' );

If your site uses no blocks at all on the front end, for example it is built entirely with a page builder, you may be tempted to dequeue wp-block-library altogether. Check first that no widget areas, reusable content or plugin output use blocks, because they will lose their styling.

Page builders

Page builders generate CSS for each page from the settings you choose in their editors. The main options to review are whether that CSS is printed inline in each page or written to cached files, whether widget styles load only when those widgets are used, and whether the builder loads its own icon fonts and animation libraries on pages that do not need them. After a site-wide design change, run the builder's regenerate CSS tool, or pages can keep old generated styles.

Optimisation plugins

Caching and performance plugins can minify and combine CSS, inline critical CSS and generate trimmed per-page stylesheets. They are effective, and they are also the most common reason a WordPress CSS change "does not show", because the old optimised copy is still being served. Use one plugin for CSS optimisation, clear its cache after design changes, and test logged-in and logged-out views separately, since many of these features are disabled for logged-in users. For a deeper look at trimming, see Fixing unused CSS.

When a CSS change will not show up

Work through these in order; it is almost always one of them:

1. Browser cache. Check in a private window. If you use a filemtime version on your child stylesheet, this stops being a problem.
2. Optimisation plugin cache. Combined and minified files are rebuilt only when the cache is cleared.
3. Server or host cache. Many managed hosts cache whole pages; clear it from the hosting panel.
4. CDN. Purge the stylesheet or the whole zone.
5. Load order. Your file loads before the rule it is meant to override. Add the right dependency handle to your enqueue call.
6. Specificity. The theme or builder rule has a stronger selector or an inline style. Inspect the element; see Fixing CSS specificity conflicts.
7. A syntax error above your rule. A missing brace in Additional CSS can disable everything after it. Paste the block into a validator.