How to Fix WordPress CSS Changes Not Showing Up

Two completely different things produce this symptom: the browser is not seeing your new CSS, or it is seeing it and another rule is overriding it. Tell them apart first, because the fixes have nothing in common.

The two-minute diagnosis

Open DevTools (F12), right-click the element and choose Inspect. Look at the Styles panel:

• Your rule is not listed at all → a caching problem. Work through the list below.
• Your rule is listed but struck through → a specificity problem. Something more specific is winning.

That single check saves most of the time people spend on this.

If it is caching: work outward

There are five layers, and they must all be cleared. In order from your browser outwards:

1. Your browser. Hard reload with Ctrl+Shift+R (Cmd+Shift+R on Mac). Better still, test in a private window, which sidesteps the browser cache entirely.
2. Your caching plugin. WP Rocket, W3 Total Cache, LiteSpeed Cache and friends all have a purge-all button. Also purge minified CSS separately — many plugins cache the combined file independently of the page.
3. Server-level cache. Varnish, LiteSpeed, or your host's own page cache. This one catches people out because it is invisible from inside WordPress. Most managed hosts put a purge button in the admin bar or their panel.
4. Your CDN. Cloudflare in particular will serve the old stylesheet for hours. Purge it, and turn on Development Mode while you are actively working.
5. OPcache. Only relevant for PHP changes rather than CSS, but worth knowing about when a PHP edit also seems to do nothing.

If clearing everything works, but the problem returns on the next edit, put the caching plugin into development mode while you work rather than purging after every change.

Cache-busting for a stylesheet you enqueue yourself

If you load CSS from a child theme or plugin, version the URL so the browser is forced to refetch when the file changes:

wp_enqueue_style(
    'child-style',
    get_stylesheet_directory_uri() . '/style.css',
    [],
    filemtime( get_stylesheet_directory() . '/style.css' )
);

Using the file's modification time as the version means every save produces a new URL automatically. This removes the entire class of problem for your own files.

If it is specificity: your rule is losing

CSS applies the most specific rule, not the last one you wrote. A theme rule like .site-header .nav a beats your a. In DevTools you will see yours struck through with the winner above it.

Fix it by being more specific rather than more forceful:

/* Losing */
a { color: red; }

/* Winning, and still maintainable */
.site-header .nav a { color: red; }

!important works but should be a last resort — once you start using it, the next override needs it too, and eventually nothing can be changed without it.

Check you are editing the right file

Surprisingly common. In DevTools, click the file name next to the winning rule; it shows the exact stylesheet and line the browser is using. If that path is not the file you edited, you have your answer — a parent theme instead of the child, or a plugin stylesheet loading later.

The order things load in

Roughly, later wins at equal specificity: parent theme, then child theme, then plugin styles, then Customiser Additional CSS, then inline styles. If your child-theme CSS is being beaten by a plugin, either raise your specificity or move the rule into Additional CSS, which loads late.