Astra CSS Not Updating: Where the Old Styles Are Hiding

The color changed in the Customizer and nowhere else

The symptoms vary, but they share one feature: the setting is saved and the visitor sees something older. You might see the new style when logged in and the old one in a private window. Desktop may update while phones lag. One page may be right and the rest wrong. A child theme edit may show up on your laptop and not on a client's. Each pattern hints at which copy is stale.

• Logged in correct, logged out wrong: a page cache. Most caching plugins skip logged-in users, so you never see what visitors see.
• Some pages right, others wrong: pages cached at different times, or Astra Pro's per-page CSS files out of step.
• Your browser wrong, other browsers right: your own browser cache, usually holding a stylesheet with an unchanged version number.
• Everything wrong everywhere, even fresh: the save never happened, or another stylesheet overrides Astra's rule.

If the Customizer spins forever or settings revert after saving, you have a different problem, covered in Astra Customizer not saving. This page assumes the save went through.

Inline by default, files with Pro: how Astra ships its styles

Astra keeps a fixed main stylesheet in the theme folder and generates a second layer of CSS from your Customizer choices: colors, typography, container widths, header builder settings. In the free 4.14.0 code, that dynamic CSS is attached to the theme's main stylesheet with WordPress's inline style function, so it lands inside the page's HTML on every request. There is no generated file to refresh in the free theme. A freshly built page always carries your latest settings.

Astra Pro changes that. Its File Generation option, found in the File Generation section of the Astra dashboard's Settings tab, writes the dynamic CSS to separate files under wp-content/uploads so browsers can cache them between pages. The vendor's documentation says a Refresh button there regenerates those files, and Astra Pro 4.12.2, per the vendor, changed file generation to refresh only the edited page's CSS on post updates instead of clearing everything. Faster, and one more place for an old copy to sit.

In free Astra, stale CSS means stale HTML. Find the cache that is keeping the page.

The hiding spots for yesterday's Astra stylesheet

Work through these from the server outward, because a purge in your browser is useless while the server keeps handing back the old page. On most Astra sites the first two account for the bulk of cases.

Optimizers deserve a closer look. Plugins that aggregate inline CSS capture Astra's dynamic block into a combined file, and that file is only rebuilt when the optimizer's cache is cleared. Your Customizer change is then correct in the database, correct in uncached HTML and wrong in the one file visitors actually download.

When it is not a cache at all

Sometimes every layer is clean and the old look persists. Then the question is not where the copy is stored but which rule wins. Astra's inline block prints right after its main stylesheet, Additional CSS from the Customizer prints late in the head, and builder stylesheets arrive with their own specificity. A rule in Elementor's global style settings, a Spectra block's own CSS or a snippet plugin can quietly beat the Customizer.

• Builder CSS files. Elementor writes its own CSS files and has a regenerate tool under Elementor > Tools. Spectra also produces block CSS. Clear those after style changes, separately from Astra.
• Child theme versioning. If your child theme enqueues style.css with a fixed version number, browsers keep the old file until that number changes. Bump it on each edit.
• Scheduled changes. Astra 4.13.12 fixed scheduled Customizer changes that failed to publish with a fatal error when applied by WP-Cron or WP-CLI. If you schedule changes, update first.
• Settings changed by AI tools. Since 4.13.0, Astra exposes an Abilities API and MCP settings. The theme's own code notes those writes skip the Customizer's save routines, so refresh Pro's files and purge caches by hand afterward.
• CSS scattered in four places. Additional CSS, child theme, builder custom CSS and a snippets plugin can all target the same element. The last one loaded wins.

To see which rule wins, right-click the element, choose Inspect, and read the crossed-out rules in the Styles panel. The surviving rule names its source file, which names the culprit. The cross-theme version of this hunt is in WordPress theme CSS not loading.

Purging old Astra styles, server first

1. 1

   Confirm the save

   Reopen the Customizer and check the setting holds its new value. If not, fix saving first.

2. 2

   View an uncached copy

   Load the page in a private window with a throwaway query string such as ?v=2. If the new style shows, the save is fine and a cache is the problem.

3. 3

   Refresh Astra Pro's files

   If you run Astra Pro with File Generation enabled, click Refresh in that section of the Astra dashboard's Settings tab.

4. 4

   Clear the optimizer and page cache

   Clear the CSS combine and minify cache, then purge the page cache plugin.

5. 5

   Purge the host and CDN

   Use the host's purge tool, then purge the CDN. Do these after the plugin, or the CDN can refill from a stale origin.

6. 6

   Clear builder CSS

   Regenerate Elementor's CSS files or the equivalent in your builder if the stale rule lives there.

7. 7

   Test logged out on two devices

   Check a phone and a desktop browser in private mode. If one still differs, a device-specific cache remains.

A purge routine your team can actually follow

Stale CSS returns whenever someone edits styles without knowing how many caches the site has. The fix is a written routine, one paragraph long, taped to the inside of the admin: what to purge, in what order, after which kind of change. Our WordPress CSS changes not showing guide has a general version you can adapt.

• Make style edits on staging, then push and purge once, instead of tweaking live.
• Keep custom CSS in one place, ideally the child theme, with a version number you bump.
• Exclude Astra's inline CSS from aggregation if your optimizer allows it, and measure whether combining helps at all.
• After each Astra or Astra Pro update, purge everything; with Pro installed the theme clears its generated files, but never your plugin's cache or your host's.

If the site is slow as well as stubborn, the same layers are usually involved. The Astra speed guide weighs inline CSS against Pro's files, and Astra fonts not loading covers the font files, which have a cache of their own.

Five caches for one color change

Count the layers in the table above. Changing a button color on a typical Astra site touches the database, the theme's generated CSS, an optimizer, a page cache, a host cache and a CDN. Each layer exists for a good reason, and each one is a place for yesterday's design to hide. That is the WordPress trade: speed bolted on in layers, with a purge button for each. Our Astra review explains why the theme itself is not the heavy part.

A Next.js build handles it differently. Styles are compiled into versioned files at build time, the filename changes when the content changes, and a deploy replaces everything at once, so there is no stale copy to chase. It costs more up front and structural changes need a developer. Astra vs Next.js compares the two honestly, and moving from Astra to Next.js shows what a move involves, with Athena CMS for editing. If you are staying, our theme troubleshooting team can map your cache layers, and the Astra repair hub and the wider troubleshooting section cover the rest.