CSS not applying — fix it in SGEN

How to fix CSS that isn't applying

CSS in SGEN can live in three places — Custom CSS, Custom Codes, and SGB Additional CSS — layered on top of your Theme and Styles and Layouts defaults. When something does not render the way you expect, the cause is almost always one of: the CSS is in the wrong layer for the specificity it needs, the snippet is Inactive, the save handler stripped something, or your browser is serving a cached stylesheet. This guide walks the diagnostic in order so you do not waste time poking at the wrong layer. Each check takes under two minutes and they are ordered from fastest to most involved — start at Check 1 and stop as soon as you find the cause.

What is this for?

This guide is a symptom-driven decision tree for the most common CSS question: I saved CSS, but the public site does not show it. It leads you through seven ordered checks — from the fastest (a hard-refresh in incognito) to the most deliberate (cascade specificity audits and layer conflicts) — so you find the real root cause without guessing. The guide covers CSS saved through any of the three SGEN surfaces: Appearance Custom CSS, Appearance Custom Codes (with a style block), and SG-Builder Additional CSS per component. All three surfaces render your CSS on the public site, but they have different scopes, different load orders, and different sanitizer rules — which is exactly why the same rule can behave differently depending on where it lives. Understanding which surface your rule lives in is the prerequisite for every check below.

Good use cases

What NOT to use this for

Before you start

Before running through the checks, confirm the following:

What you will need access to:

• Admin access to Appearance Custom CSS and Appearance Custom Codes.
• A browser with DevTools available (Chrome, Firefox, or Edge).
• The public URL of the page where the CSS should be applied.

Where to go

The relevant admin panels for this workflow, in the order you will visit them:

• Appearance Custom CSS — your first stop. Shows all CSS snippets with their Status pill (Active / Inactive / Trash) and Priority number.
• Appearance Custom Codes — your second stop if Custom CSS checks out. Filter to Active to see only what is currently rendering.
• SG-Builder editor — open any page in the Builder, select a component, look for the Additional CSS trait panel in the right sidebar.

Here is what the Custom CSS list looks like in the admin:

Steps

Work through these seven checks in order. Most issues resolve at Check 1 or Check 2.

.tooltip::before { content: "<help>"; }

.tooltip::before { content: ""; }

.tooltip::before { content: "\003Chelp\003E"; }

CSS layer field reference

Each CSS surface in SGEN has its own set of fields. Knowing what each field does helps you spot the issue faster during the diagnostic.

Custom CSS snippet fields

• Name — internal label only. Not rendered on the public site. Use it to describe the rule's purpose.
• CSS — the raw CSS body. No wrapper tags. The save handler strips angle-bracket sequences from this field on every save.
• Status — Active (renders in the page head), Inactive (saved but dormant), Trash (soft-deleted, recoverable). Defaults to Inactive on create.
• Priority — integer 1 through 20. Lower numbers load first. Two snippets with the same selector: the higher-numbered Priority wins because it loads later. Default is 10.

Custom Codes snippet fields

• Name — internal label only.
• Body — accepts HTML, script tags, style blocks, or link tags. The sanitizer strips HTML comments from this field on save.
• Status — Active or Inactive. Same behavior as Custom CSS status.
• Placement — where in the page the snippet is injected: head (default), body start, or body end.

SG-Builder Additional CSS fields

• Additional CSS — raw CSS scoped to the selected component. Injected as an inline style block on the page, after Custom CSS and Custom Codes in the overall load order.
• No Status or Priority fields. The rule is active whenever the component is present on the page and the page is published.
• Editing requires opening the page in the Builder, selecting the component, and writing in the Additional CSS trait panel on the right side.

What success looks like

Common root causes (sorted by frequency)

The seven checks above map directly to these root causes. Check 1 rules out browser cache (cause 2). Check 2 catches cause 1. Checks 3 and 4 handle causes 3 and 4. Checks 5 through 7 handle the remaining three. Working through them in order means you rule out the most common causes first and only reach the subtle ones if the quick checks do not resolve the issue.

1. Snippet is Inactive. The snippet was saved but Status was not set to Active. Toggle to Active and save.
2. Browser cache. The browser is serving the previous stylesheet. Hard-refresh in incognito to confirm and rule this out.
3. Specificity loss. A theme rule with higher specificity is winning the cascade. Add a body prefix to your selector.
4. Save-handler stripping. An angle-bracket sequence in your CSS got removed on save. Use Unicode codepoints for angle brackets in content: values.
5. Theme swatch overwrote it. A swatch swap reset your Styles and Layouts values. Move the override to Custom CSS so future swatch changes cannot undo it.
6. Wrong layer. The CSS is sitewide when it should be per-component, or per-component when it should be sitewide.
7. Conflicting Custom Code. A style block in an Active Custom Code is targeting the same selectors with equal or higher specificity and loading after your snippet.

Example scenarios

Example 1: Inactive snippet after a new-tab workflow. an editor manages the your business site. She created a new Custom CSS snippet with three button-color rules, then closed the browser tab before toggling the Status field to Active. When she later checked the Custom CSS list, the snippet existed but its Status pill read Inactive — the default for a new snippet before activation. The rule was never loaded into the page head. Fix: open the snippet, toggle Status to Active, click Save, then hard-refresh the public page.

Example 2: Save handler strips a content: value. a teammate added a tooltip rule for the your business navigation with an angle-bracket icon string in the content: value. After saving and reloading, the tooltip was empty. Opening the snippet's edit form revealed the stored rule had an empty content: value — the save handler had removed everything between the angle brackets. Fix: replace the angle-bracket string with Unicode codepoints. The stored rule now survives the save handler and the tooltip renders the expected character.

/* Before — angle brackets get stripped on save */
.nav-icon::before { content: "<i>"; }
/* After — Unicode codepoints survive the save handler */
.nav-icon::before { content: "\003Ci\003E"; }

Example 3: Swatch swap overwrites a hand-tuned button color. a developer switched your business' Color Swatch from "Espresso" to "Natural" to preview how it looked. After switching back, the primary button background had reverted from the custom brand brown he had set in Styles and Layouts to the swatch preset value. Root cause: swatch changes rewrite Styles and Layouts presets, including button background values. Fix: add a Custom CSS snippet that pins the button background so future swatch changes cannot override it.

Example 4: Conflicting style block in Custom Codes. an admin noticed the your business hero section background was wrong — her Custom CSS snippet set a warm off-white background but the public page showed plain white. Checking Appearance then Custom Codes filtered to Active, she found an older snippet called Legacy hero override containing a style block that overrode the same selector. Because Custom Codes rendered into the page head after Custom CSS, it was winning the cascade at equal specificity. Fix: remove the overlapping rule from the Custom Code snippet, then save and hard-refresh.

How this connects to other features

What to do if it does not work

If you have worked through every check above and the rule still is not applying, gather the following before contacting support:

1. A screenshot of the snippet's edit form showing the exact rule text and the Status pill = Active.
2. A screenshot of the public page with DevTools open on the affected element, Computed tab visible. The Computed tab names the winning rule, its selector, and the stylesheet it came from.
3. The snippet's Priority value and a list of any other Active snippets whose selectors might overlap with yours.
4. Which of the seven checks you completed and the result of each, so support can continue from where you left off.

Contact SGEN support through the Help menu in your admin panel.

Related troubleshooting

• Why aren't my changes showing on the public site? — the broader version of this question. Covers content and page changes, not only CSS.
• Why isn't my custom font loading? — related family of caching and load-order issues specific to font files.

Citations (audit trail)

Every check above traces to one of these existing per-feature reference docs.

• Create a Custom CSS snippet — source for Check 3 (save handler stripping) and Check 4 (cascade specificity escalation pattern).
• Manage Custom CSS snippets — source for Check 2 (Status = Active requirement and cache-clear troubleshooting).
• Pick a theme — source for Check 5 (Color Swatch behavior and documented side-effects on Styles and Layouts).
• Customize global styles — source for Check 5 (re-applying Styles and Layouts values after a swatch reset).
• Add custom HTML, scripts, and tracking code — source for Check 7 (conflicting style blocks in Active Custom Codes snippets).