Custom CSS basics in SGEN

Custom CSS editor surface (Dashboard > Custom CSS) — the code editor area and Save button where site-wide/page overrides are written

⏱ Answer below · full page ≈ 6 min · skim the bold lead-ins to move faster.
In short. SGEN's Custom CSS surface (Dashboard → Custom CSS) lets you add site-wide or page-specific style overrides without touching theme files. Write standard CSS, save, and changes apply on the next page load. Use it for what the Theme Editor does not expose. Always scope page-specific rules with body.page_id-N — never body.page- — and identify the correct selector with the browser inspector before writing any rule.

On this page: Good use cases · What NOT to use this for · Before you start · Steps · Troubleshooting · Tips

How to write CSS in SGEN using the Custom CSS surface

Custom CSS in SGEN sits at the site level. CSS you write here applies to every page on your site — making it the right tool for global overrides (button radius, typography, link colors) and the right tool for page-specific overrides when you scope them with body.page_id-N.

Full comparison of Custom CSS vs Custom Codes vs SG-Builder additional CSS: Custom CSS vs Custom Codes vs SG-Builder Additional CSS.

Good use cases

Custom CSS is the right tool in each of these situations.

  • Adjusting the global button style. The Theme Editor does not expose a border-radius control? One rule in Custom CSS applies the correct radius to every button on the site.
  • Setting a global link color. One color rule, applied once, consistent across all pages — faster and less fragile than modifying the theme directly.
  • Scoping a style override to a specific page. SGEN adds a unique body class per page based on the page ID: body.page_id-N. Use that class to scope the override so it only affects the intended page.
  • Adjusting typography not exposed in the Theme Editor. Line height, letter spacing, font weight on specific elements — Custom CSS covers these without touching theme files.
  • Overriding third-party widget styles. A form, chat widget, or embedded calendar with clashing default styles can be overridden with scoped CSS without breaking the widget's functionality.
  • Fixing a display issue that only appears on the live site. If the Theme Editor has no control for it, Custom CSS with a targeted selector is the fastest path.

What NOT to use this for

  • Do not use Custom CSS to add scripts, tracking pixels, or HTML. Custom CSS accepts CSS only. For JavaScript, tracking codes, or HTML snippets, use the Custom Codes surface. Full detail: Custom CSS vs Custom Codes vs SG-Builder Additional CSS.
  • Do not use Custom CSS for what the Theme Editor already covers. The Theme Editor handles global typography and palette changes without specificity conflicts. If a control exists for what you need, use it — layering CSS on top of Theme Editor output creates specificity debt.
  • Do not scope page-specific CSS with body.page-. That class is removed when the page is set as the homepage. Always use body.page_id-N — the ID never changes.
  • Do not turn Custom CSS into a full stylesheet. It is for targeted overrides. If you are writing hundreds of lines in a session, a theme customization or a developer-maintained file is the correct path.
  • Do not reach for !important first. If a rule is not applying, the problem is almost always specificity or a selector error. Diagnose with the browser inspector before adding !important.

Before you start

Check the Theme Editor first. If it has a control for what you need, use it — it is the safer path with no specificity conflicts.

Open the browser inspector (F12). Identify the element, its classes or ID, and the specificity of the rules currently applying. Copy the selector from the inspector rather than guessing. For page-specific overrides, get the page ID from the address bar while editing that page in the dashboard — it appears at the end of the edit URL (for example, a page whose edit URL ends in /42 has the ID 42) — and use body.page_id-42 as the scope prefix.

Decide global or page-specific before writing. Scoping mistakes — rules applying where they should not — are the most common source of Custom CSS problems.

Steps — Write and apply Custom CSS in SGEN

These steps take you from identifying the style you want to change to verifying it is working on the live site.

1. Identify the element and selector using the browser inspector

Before writing any CSS, open the live version of your site in a browser (not the admin dashboard) and open the developer tools (F12).

Click the Elements or Inspector panel. Use the element picker (the cursor icon at the top of the developer tools panel) to click the element you want to style on the page. The developer tools will show you the HTML for that element and, on the right side, the CSS rules currently applying to it.

Look at the element's classes, ID, and the specificity of the rules applying to it. The selector you write in Custom CSS needs to be at least as specific as the rule you are trying to override.

Copy the selector from the inspector or write a variation of it. Test the selector in the browser console if you want to confirm it matches: document.querySelectorAll('.your-selector') should return the elements you expect.

2. Open Custom CSS in the dashboard

Go to Custom CSS in the left sidebar. The editor opens with any CSS you have already written. Existing CSS remains active — do not delete previous rules unless you intend to remove their effect.

Scroll to the bottom of the editor to add new rules. Add a comment above each rule or block explaining what it does and why. Comments in CSS use the / comment / format. They do not affect the applied styles.

``css / Adjust global button border radius to match brand guidelines / / Added 2026-05-27 — design spec v2.3 / button, .btn, .button { border-radius: 4px; } ``

3. Write the CSS rule

Write the rule with the selector you identified in step 1. Follow standard CSS syntax: selector, opening brace, property, value, semicolon, closing brace.

For a global rule applying to all instances of an element:

``css / All inline links, excluding buttons / a:not(.btn):not(.button) { color: #af0200; } ``

For a page-specific rule scoped to one page by ID:

``css / Wholesale Inquiry page (ID 42) — hero background override / body.page_id-42.hero-section { background-color: #fff6f6; } ``

For a responsive rule applying only at a specific viewport width:

``css / Reduce hero headline size on mobile / @media (max-width: 640px) { .hero-section h1 { font-size: 2rem; line-height: 1.25; } } ``

4. Save and verify on the live site

Click Save in the Custom CSS editor. The CSS is saved and applies to the live site on the next page load — you do not need to publish or deploy separately.

Open the live site in a private browser window (not the admin session). Navigate to the page or element you styled. Verify that the style is applying correctly.

If the style is not applying:

  • Open the browser inspector on the element.
  • Check whether your rule appears in the CSS panel.

If it appears but is crossed out (overridden), the specificity of your selector is lower than the rule it is trying to override. Increase the specificity of your selector — add a parent class or use a more specific selector path.

  • If your rule does not appear at all, check for a syntax error in the CSS.

A missing semicolon, an unclosed brace, or an invalid value will prevent the rule from applying. The browser inspector usually shows a warning in the console.

5. Test for unintended side effects

After verifying the intended change, check that your CSS is not affecting elements you did not mean to style.

For a global rule: open two or three other pages on the site and confirm the affected element looks correct on those pages too — not broken by the new rule.

For a page-scoped rule: open a different page and confirm the scoped styles are absent there. If body.page_id-42.hero-section { background-color: #fff6f6; } is appearing on a different page, the scope is not working — check that you are using page_id-N and that the ID matches the correct page.

What success looks like

When Custom CSS is working correctly, these things are true.

  • The styled element on the target page shows the correct style in a private browser window.
  • The browser inspector shows your CSS rule in the applied styles panel, not crossed out.
  • Other pages that should not be affected are visually unchanged.
  • Page-scoped rules are absent from pages they should not apply to.
  • The Custom CSS editor shows your saved CSS without truncation or error.

What to do if it does not work

  • The CSS is saved but nothing changed on the live site.

Try a hard refresh in the private browser window (Shift + reload or Ctrl + Shift + R). If the change still is not visible, open the inspector and check whether your rule appears in the applied styles for the element. If it appears crossed out, increase the selector specificity. If it does not appear, check for a syntax error in the CSS.

  • The CSS is applying to pages it should not be applying to.

Confirm you used body.page_id-N for page-specific scoping, not body.page-. If you wrote a global rule (no page scope) when you intended a scoped rule, add the body.page_id-N prefix to each rule.

  • The CSS was working, then stopped after a theme update.

Theme updates can change class names or add new specificity layers. Open the inspector on the affected element after the update, find the new rules applying, and adjust your selector to match the updated theme output.

  • The CSS is applying site-wide when I only want it on one page.

Add the body.page_id-N scope prefix to each rule. Without a scope prefix, CSS in the Custom CSS editor applies globally.

  • I do not know the correct page ID for a page-specific override.

Go to Pages in the dashboard. Open the page you want to target and look at the address bar: the number at the end of the edit URL is the page ID (for example, an edit URL ending in /42 means the ID is 42). Use body.page_id-42 as your scope prefix.

Tips for clean Custom CSS

  • Always add a comment explaining each rule or block.

Custom CSS accumulates over time. A comment explaining what a rule does and when it was added makes it possible to safely remove or update rules later.

  • Use page_id-N for page-specific overrides, never page-.

The slug class is removed when a page is set as the homepage. The page ID is permanent.

  • Inspect before you write.

Guessing selectors wastes time. The browser inspector shows you the exact selector, property, and specificity you are dealing with. Inspect the element first. Write the override second.

  • Keep Custom CSS lean.

The Custom CSS surface is for targeted overrides, not a full stylesheet. If you find yourself writing more than one hundred lines of CSS in a session, consider whether a theme adjustment or a developer-maintained file is a better long-term solution.

  • Test in a private browser window after every save.

Your admin session may cache CSS differently from a visitor session. A private browser window shows the result a visitor sees.