Hestia CSS Not Updating: Inline Styles, Caches and the Child Theme Version

No file, no cache: Hestia rebuilds its styles on every request

Reading Hestia 3.3.7's code, the CSS behind your Customizer choices, colors, typography, button radius and padding, footer and Very Top Bar, is generated in PHP and attached to the theme's main stylesheet handle, hestia_style, as inline CSS. It is not written to a file and not stored in the database. Every uncached page view gets fresh styles. That is good news for diagnosis: if a freshly generated page shows the new color, Hestia did its job, and the stale copy lives in a cache.

Look for it directly. Open the live page logged out in a private window, view the source and search for hestia_style-inline-css, the id WordPress gives that block. If your new hex code is there, the problem is in the browser or a rule that outranks it. If the old one is there, a server-side copy is being served. Most caching tools skip logged-in users, which is why the Customizer preview and your own admin view agree with you while customers see last week.

Hestia hands every visitor fresh styles. Your caches decide whether they arrive.

Where a Hestia style comes from and what can freeze it

Order matters as much as freshness. On a site without a child theme, the inline Customizer block follows style.min.css. With a child theme, it follows the child's style.css, because that file takes the hestia_style handle. Additional CSS prints later still. So at equal specificity Additional CSS beats the Customizer, and the Customizer beats your child stylesheet, which surprises developers who expect their child theme to have the last word.

Who is holding the old Hestia styles, most likely first

A page cache, host cache or CDN

Because the styles ride inside the HTML, any layer that stores HTML stores your old colors with it. Purge the caching plugin, then the host's cache from its dashboard, then the CDN. Purge everything rather than single files, since the inline block lives in every page.

A CSS optimizer that swallowed the inline block

Optimizers that aggregate inline CSS move Hestia's block into a combined file, which changes only when the optimizer's cache is cleared. Look in the source for stylesheet addresses with hashed names under a cache folder. Clear the optimizer separately, or exclude Hestia's inline block from aggregation if your plugin allows it.

A change that was saved but not published

WordPress's Customizer can Save Draft or Schedule as well as Publish, from the gear beside the button. A drafted change shows in the preview and nowhere else. Reopen the Customizer and check whether it says changes are drafted or scheduled.

Elementor styles taking precedence

Hestia offers to switch off Elementor's default colors and fonts so the theme stays in charge, and loads its own page-builder stylesheet when both are off. If Elementor's defaults are on, or widgets carry fixed colors, Elementor wins on those pages. Clear Elementor's own files under Elementor, Tools, Clear Files & Data after style changes. More in Elementor theme conflicts and our Elementor repair hub.

The child theme quirk: your stylesheet wears Hestia's version number

Hestia does something unusual with child themes. In 3.3.7, when a child theme is active, the theme itself enqueues the child's style.css under its main hestia_style handle, and gives it Hestia's version number, currently 3.3.7. Themeisle's child theme instructions then have the child's functions.php load the parent's style.css separately, under the handle hestia_child_parent, with Bootstrap as a dependency. Edit the child stylesheet and its address does not change. Browsers and CDNs keep the copy they have until Hestia's next release changes the number.

Hestia passes that version through a filter called hestia_version_filter. A two-line function in the child theme can return the child stylesheet's modification time instead, so the address changes every time you save the file. Until that is in place, each edit needs a CDN purge and a hard refresh, and returning visitors may see old styles for days. If the child stylesheet loads but the parent styles vanish entirely, the parent enqueue is missing; that is a loading failure, covered in WordPress theme CSS not loading.

Local fonts hosting and the font that will not change

Font changes often look like CSS failures. Hestia serves Google Fonts from fonts.googleapis.com on the front end unless Local fonts hosting is ticked under Appearance Settings, Typography, and it is off by default. When ticked, Hestia downloads the fonts into a fonts folder inside wp-content/uploads and prints the font rules inline, so a font change follows the same cache path as a color change. The bundled loader also schedules a monthly cleanup that deletes the folder; the files are fetched again the next time a page is built, but a page cached before the cleanup can point at fonts that are briefly gone.

After a migration, copy the uploads folder in full, or the inline rules point at font files that are not there. If the font still will not change after purging, check the Network panel for requests to Google, which mean the local option is off or a plugin queued its own fonts. Our Hestia speed guide explains why the local option is worth turning on anyway.

A clearing sequence for Hestia, server first

1. 1

   Confirm the change was published

   Reopen the Customizer and make sure the value holds and nothing is drafted or scheduled.

2. 2

   Check an uncached copy

   View the source logged out, search hestia_style-inline-css and look for the new value.

3. 3

   Purge the optimizer

   Clear the CSS optimizer's combined files before the page cache, so the page cache does not store pointers to old bundles.

4. 4

   Purge page, host and CDN

   Clear each layer in that order, everything, not single URLs.

5. 5

   Clear Elementor files

   On Elementor sites, Elementor, Tools, Clear Files & Data, then purge the page cache again.

6. 6

   Fix the child version

   If the old rule comes from the child stylesheet, hook hestia_version_filter to return the file's modification time, then purge the CDN.

7. 7

   Check specificity

   If every copy is fresh and the style still loses, inspect the element. Additional CSS and the Customizer block print after the child stylesheet, so they win ties.

Habits for a Hestia site with a child theme

• Fix the child stylesheet version once, with the filter, and stop purging by hand.
• Keep colors and fonts in the Customizer, layout rules in the child theme, and nothing important in Additional CSS that the child theme also sets.
• Run one page cache with purge-on-save switched on.
• Test style changes on staging and check the navbar and Big Title afterward; our Hestia header guide covers what can go missing.
• Hand routine updates and cache rules to our hosting and maintenance plans if nobody owns them.

If an optimizer that broke your styles also broke the phone menu, Hestia mobile menu not working covers the script side. Our Hestia review sets out where the theme stands in 2026, and the general routine for stubborn styles is in CSS changes not showing on a website.

Why a Hestia color change should not take an afternoon

Hestia itself is tidy here: fresh styles on every request, no generated files to rebuild. The trouble is everything in front of it. A child theme with a borrowed version number, an optimizer, a page cache, a host cache, a CDN and the browser can each keep their own copy, and each has its own purge button.

A Next.js build compiles styles into files whose names change with their contents, and a deploy swaps everything at once, so nothing stale survives. It costs more up front and needs a developer for structural changes. Hestia vs Next.js lays out the trade, and Hestia to Next.js explains how a one-page site becomes separate, editable pages. Prefer to keep Hestia? Our theme troubleshooting team untangles stuck styles on staging. Other guides are in the troubleshooting section.