Custom CSS basics in SGEN

How to write CSS in SGEN using the Custom CSS surface

SGEN gives you one dedicated place to write site-wide CSS overrides: the Custom CSS surface at /sg-admin/custom_css. This guide covers what it is, when to use it, how to write CSS that works correctly inside SGEN, and how to avoid the common mistakes that cause CSS to apply to the wrong pages or to nothing at all.

Custom CSS in SGEN sits at the site level. CSS you write here applies to every page on your site, across every visitor session. That makes it the right tool for style overrides that should be consistent everywhere — global button radius, typography overrides, link colors, spacing adjustments — and the wrong tool for styles that should apply to only one page.

For a deeper comparison of Custom CSS versus Custom Codes versus SG-Builder additional CSS, see Custom CSS vs Custom Codes vs SG-Builder Additional CSS. This guide focuses on the Custom CSS surface specifically.

What is this for?

This guide is for anyone who needs to adjust site styles beyond what the Theme Editor controls allow. It is useful for: marketing teams who need a button color adjusted site-wide; designers who need to apply a font override the theme does not expose; developers who want to add scoped overrides for a specific page template.

It is also useful as a reference for teams who are using the Custom CSS surface but are not sure whether their CSS is being applied correctly or to the right scope.

You will use the Custom CSS editor in the SGEN dashboard. No external tooling is required. Changes save immediately and apply to the live site on the next page load.

Good use cases

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

• Adjusting the global button style.

Your theme's default button has square corners. Your brand guidelines call for a 4px border radius. The Theme Editor does not expose a border-radius control. Custom CSS is the correct tool: one rule applied once, carrying to every button on the site.

• Setting a global link color.

The theme renders inline links in a blue that clashes with your brand palette. Custom CSS: one color rule, applied once, consistent across all pages. Faster than overriding per page, less fragile than modifying the theme directly.

• Scoping a style override to a specific page.

You built a landing page with SG-Builder and want the hero section on that page to have a slightly different background color than the theme default. SGEN adds a unique body class for every page based on the page ID: body.page_id-N. Use that class to scope the override to that page only. The override does not affect other pages.

• Adjusting typography not exposed in the Theme Editor.

The Theme Editor controls font family and size at a global level. Finer adjustments — line height, letter spacing, font weight on specific elements — are often not exposed as controls. Custom CSS covers these without touching the theme files.

• Overriding third-party widget styles.

A contact form, a chat widget, or an embedded calendar may come with default styles that clash with your site design. Scoped CSS in Custom CSS can override these without affecting the third-party library's functionality.

• Fixing a display issue that appears in production but not in the theme preview.

If a specific element looks wrong on the live site and the Theme Editor does not have a control for it, Custom CSS with a targeted selector is the fastest fix.

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 at /sg-admin/custom_codes. See Custom CSS vs Custom Codes vs SG-Builder Additional CSS for guidance on which surface handles which content.

• Do not use Custom CSS to change the site's primary typography or color palette if the Theme Editor covers it.

The Theme Editor is designed to handle global typography and palette changes without specificity conflicts. If the Theme Editor has a control for what you want to change, use it. Custom CSS runs on top of the Theme Editor's output — adding a CSS override for something the Theme Editor already controls creates a specificity layer that is harder to maintain.

• Do not use a homepage slug class to scope page-specific CSS.

SGEN adds a body.page-<slug> class to pages, but this class is removed when a page is set as the homepage. Always use body.page_id-N for page-specific scoping — the ID does not change.

• Do not write thousands of lines of CSS in the Custom CSS editor.

The Custom CSS surface is for targeted overrides. If you find yourself writing a stylesheet rather than a set of overrides, the correct path is a theme customization or a developer-maintained stylesheet, not an expanding Custom CSS block.

• Do not use !important as a first resort.

If your CSS is not applying, the problem is usually specificity or selector incorrectness. Diagnose with the browser's inspector first. !important should be a last resort, not a default.

How this connects to other features

• Theme customization — The Theme Editor controls the foundational layer of your site's styles:

font family, base sizes, color palette, and button defaults. Custom CSS overrides sit on top of the Theme Editor output. Start with the Theme Editor for any global style change. Use Custom CSS for what the Theme Editor does not expose. See Theme customization.

• SG-Builder — Sections built in SG-Builder have their own style configuration panels.

For section-level styles, use the SG-Builder panel. For site-wide overrides that should apply to all SG-Builder sections of a type, use Custom CSS.

• Custom Codes — Custom Codes is for JavaScript, HTML snippets, and third-party integrations.

Custom CSS is for CSS only. The two surfaces are separate. See Custom CSS vs Custom Codes vs SG-Builder Additional CSS.

• Pages — Page-specific CSS should use the body.page_id-N class to scope.

The page ID is visible in the URL when editing the page in the dashboard (/sg-admin/pages/edit/42 means the page ID is 42).

Before you start

Before writing Custom CSS, have these things ready.

Know what you are trying to change and why the Theme Editor is not covering it. The Theme Editor should be your first stop for any style change. Check whether a control exists for what you need before opening the CSS editor. If the Theme Editor has the control, use it — it is the safer path.

Have the browser inspector open. The browser developer tools (F12 in Chrome or Firefox) let you inspect any element on the page, see what CSS rules are applying, and identify the correct selector and property. Inspect the element you want to style before writing CSS. Copy the selector you see in the inspector rather than guessing.

Know whether the change should be site-wide or page-specific. If it should apply everywhere: write a global rule. If it should apply to one page: scope to body.page_id-N. Decide before you write. Scoping mistakes are the most common source of CSS working in the wrong place.

Have the page ID ready for page-specific overrides. If you are scoping CSS to a specific page, get the page ID first. Go to Pages in the dashboard, click the page you want to target, and look at the URL in your browser's address bar. The number in the path (/sg-admin/pages/edit/42) is the page ID.

Where to go

Go to Custom CSS in the left sidebar of your SGEN dashboard. The Custom CSS editor opens with your existing CSS (if any) in the text field. Write your CSS, click Save, and the changes apply to the live site on the next page load.

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.

/* 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:

/* All inline links, excluding buttons */a:not(.btn):not(.button) {color: #5C3A1E;}

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

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

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

/* 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: #F8F5F0; } 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-<slug>. 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. Click the page you want to target and look at the URL: /sg-admin/pages/edit/42 — 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-<slug>.

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.