Genesis CSS Not Updating: The Version Number Your Stylesheet Is Stuck On

Saved on the server, invisible on the site

The pattern is familiar. You change a color or a margin in the child theme's style.css, upload it, reload, and nothing moves. A hard refresh shows the change on your laptop, but your business partner still sees the old color on her phone. Or the change never shows anywhere, and DevTools reveals your new rule sitting there with a line through it. Those are three different problems with three different fixes, and on a Genesis site the first one is by far the most common.

• Nobody sees the change, including you after a hard refresh. Suspect the wrong file, or a cached page pointing at an old stylesheet address.
• You see it, visitors do not. Suspect the version string and the caches between your server and their browser.
• The rule loads but is crossed out. Nothing is cached; something more specific or printed later is winning.

How a Genesis child theme labels its stylesheet

Genesis loads the child theme's style.css by itself; the framework docs say so, and say child themes should supply all their own CSS. What decides whether a browser fetches a fresh copy is the version attached to the address. Child themes written before Genesis 3.0 set that number by hand with a constant in functions.php. Genesis Sample 2.6.0, for example, defines CHILD_THEME_VERSION as 2.6.0 and passes it to its font and script enqueues too.

Genesis 3.0.0 added genesis_get_theme_version(), which reads the Version line from the child theme's style.css header. The changelog describes it as a cache-busting string and notes that a duplicate CHILD_THEME_VERSION constant is no longer needed. There is a bonus: when the SCRIPT_DEBUG constant is true, the function returns the current Unix time instead, so every page load gets a fresh address. Current Genesis Sample uses it for its block stylesheet as well as AMP styles.

Five reasons a Genesis style edit stays hidden

1. The version string never moved

This is the usual one. The file changed; its address did not. Browsers that cached style.css?ver=2.6.0 keep using it, and so does any CDN in front of the site. A block stylesheet versioned from the same header has the same problem. Check: View Source, find your child theme's stylesheet, and compare the ver= number with the Version line in style.css and any CHILD_THEME_VERSION define in functions.php. Whichever one matches is the one to raise.

2. The edit went into Genesis instead of the child theme

Genesis 3.0.0 removed all styles from the framework's own style.css, and the docs warn that the parent file is not meant to be inherited. Edits made there do nothing visible, and the next framework update would overwrite them anyway. Check: confirm the path you edited sits in your child theme's folder, not wp-content/themes/genesis.

3. Inline CSS printed after your file wins

Genesis Sample prints its Customizer color settings as inline CSS attached to the theme stylesheet, and WordPress prints Additional CSS later still. At equal specificity, the later rule wins. Change a link color in style.css while the Customizer holds a different one and your edit loses every time. Check: inspect the element; if your rule is crossed out, change the Customizer setting or write a more specific selector. The general rules of that fight are in CSS changes not showing.

4. A cached page still points at the old address

Raising the version only helps visitors who receive fresh HTML. A page cache holding yesterday's HTML still lists the old stylesheet address. On WP Engine, where many Genesis sites live, the WordPress admin has a WP Engine menu with a Caching tab and a Clear All Caches button, and the User Portal can clear the page cache, network caches (its CDN, powered by Cloudflare) and the object cache separately. Check: view source logged out and confirm the new ver= number appears.

5. The optimizer serves its own copy

Caching plugins that combine and minify CSS write a new file with their own name. Your stylesheet's version matters to that bundle only when the plugin rebuilds it. Check: if the page loads a combined file instead of style.css, clear the plugin's cache before anything else.

Making a stylesheet edit reach every visitor

1. 1

   Confirm the file that loads

   In DevTools, open the Sources or Network panel and check that the stylesheet comes from your child theme's folder. Edit that file, nothing else.

2. 2

   Raise the version

   Increase the Version line in the style.css header, for example from 3.4.3 to 3.4.4. If functions.php defines CHILD_THEME_VERSION, raise that too, because older child themes pass it to every asset.

3. 3

   Clear the optimizer

   Purge the caching plugin's page cache and its combined CSS files so the next build includes your change.

4. 4

   Clear the host cache

   On WP Engine use Clear All Caches; on other managed hosts, use the purge button in their panel or plugin.

5. 5

   Purge the CDN

   If a CDN sits in front of the site, purge it last, after the origin is already serving fresh files.

6. 6

   Test as a stranger

   Open a private window, view source, and confirm the new ver= number. Then check the change on a phone that has visited the site before.

7. 7

   Look for crossed-out rules

   If the new file loads and the change still does not show, inspect the element and find the Customizer or Additional CSS rule that outranks yours.

A cache-busting routine your next developer will thank you for

On staging, define SCRIPT_DEBUG as true in wp-config.php. Genesis then versions theme assets with the current time, so every reload fetches fresh CSS and you stop wondering whether you are looking at a cached copy. Turn it off before anything goes live: it defeats browser caching for those files, and it also makes WordPress load the unminified versions of its own scripts and styles.

On production, make the version bump part of every deploy. Keep the child theme in version control and raise the Version line in the same commit as the CSS change, so nobody can ship one without the other. Some developers go further and set the version from the stylesheet's last-modified time with PHP's filemtime(), which removes the human step; it works, as long as everyone knows the theme does it. And keep a short purge order written down: plugin, host, CDN. Our hosting and maintenance plans include small edits like these, done in that order.

Six copies of a stylesheet is a stack problem

None of this is hard. It is just a lot of steps for one color. A version number in a file header, a constant that might also exist, inline CSS from the Customizer, an optimizer's bundle, a host cache and a CDN, each holding its own copy. Owners learn the ritual or wait for someone who knows it.

Six copies of one stylesheet, and the visitor gets whichever is oldest.

A Next.js production build writes CSS to files whose names change whenever their contents change, and deploys them with the pages that use them, so a stale stylesheet has nowhere to hide. That build costs more up front and needs a developer for design changes. Genesis vs Next.js lays out the trade, Genesis to Next.js covers the move, and Athena CMS is where owners edit content afterward.

Plenty of Genesis sites are worth keeping; our Genesis review says which. The Genesis speed guide covers the child theme's fonts and scripts, and the sibling fixes for layouts, menus and PHP errors sit in the troubleshooting section. If you want it handled, our theme troubleshooting service does it on staging, and the theme repair team takes the bigger breaks.