Add CSS in WordPress the right way

What the Additional CSS panel actually does

Since WordPress 4.7, Appearance then Customise opens an Additional CSS panel: an editor, a live preview, no file handling. It is the shortest path, and it fits exactly what it was designed for — a short, targeted fix whose effect you want to see at once.

Two implementation details decide what follows. The content is stored as an option of the active theme: it stops applying the day the site changes theme, without being erased, which produces disappearances that are hard to explain. And it is inlined in the head of every page rather than served as a stylesheet, so it is never cached separately and it goes back on the network on every view.

There is also no history, no review, and no search: the panel is a text field. As long as the sheet stays a short fix you could still explain later, that is harmless. Beyond that, the maintenance cost exceeds the comfort of the start.

• A short sheet, not a long one.
• Fixes you could find and justify later.
• Nothing that must survive a theme change.

The child theme, the only place that survives updates

A child theme is a folder that declares the existing theme as parent. It inherits all of its behaviour and holds only the intended differences. Because parent updates never touch that folder, it is the only place where CSS written today will still be there after the next theme version.

Two files are enough. The first declares the child theme, the second loads its stylesheet after the parent, which guarantees priority order without tricks.

From there, CSS lives in a file: it goes through version control, is reviewed, searched, commented, and cached by the browser like any static asset.

/*
Theme Name: Mon thème enfant
Template: nom-du-theme-parent
Version: 1.0.0
*/

/* Les écarts voulus, et seulement eux. */

add_action( 'wp_enqueue_scripts', function () {
    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 three places not to write

Editing the parent theme stylesheet directly works until the first update, which overwrites the whole folder. The work then disappears without warning, and usually at the worst moment: when a security fix is applied.

The built-in file editor in administration presents the same risk, worsened by the lack of undo: a forgotten brace in a PHP file is enough to make the site unreachable, including the administration from which you had just written.

Finally, stacking custom-CSS extensions multiplies sources of truth. After a few of them, nobody knows which rule comes from where, every page loads competing styles, and diagnosing a simple offset takes a working session.

• Never edit the parent theme: the update will overwrite it.
• Disable the administration file editor on a production site.
• One source for the site CSS, not competing extensions.

Write CSS that does not need !important

Repeated use of a priority declaration is almost always the symptom of an order or specificity problem, not a limit of the language. Two rules that target the same element are settled first by specificity, and at equal specificity by load order.

The first reflex is therefore to check when the sheet is loaded: a dependency declared when the style is added is enough to place it after the theme, and the priority question disappears. The second is to aim precisely rather than hard — a selector anchored on a component class rather than a chain of nested elements.

A priority declaration remains legitimate to neutralise an inline style set by a third-party extension you do not control. It then deserves a comment explaining what it bypasses: that comment is what will let you remove it the day the extension changes.

/* Fragile : dépend de la structure du thème. */
.site-main .content article .entry-header h2 a { color: #8e66f1; }

/* Stable : dépend du composant. */
.entry-title__link { color: #8e66f1; }

When Additional CSS becomes a symptom

A growing sheet of fixes tells something about the site. A short sheet adjusts a theme; a long one signals that the chosen theme does not match what the site must do, and that every page now pays for its catch-up.

The clearest signal is repetition: the same correction rewritten for every new template, the same values copied with slight gaps, selectors growing longer. At that stage, setting reusable design decisions — type scale, spacing, colour — costs less than the next round of fixes. That is the work of a brand identity applied to code rather than to a document.

Weight counts too: inlined in every page, this CSS is transferred on every view and blocks display until it is parsed, which weighs directly on the performance signals measured by engines — a point treated in SEO on the same footing as content. When the debt exceeds the fix, the question is no longer where to write CSS but which foundation to take up, which is what website design scopes. An estimate gives a first order of magnitude before discussing it.