How to understand what SGEN is

SGEN is a CMS platform. Built as a WordPress alternative for teams that have outgrown what WordPress + Elementor + a plugin pile can give them safely.

It's documented as one operating system with distinct surfaces, not as a bundle of disconnected tools. Three product pillars: SG-Core (the essentials), SG-Modules (first-party modules that replace your plugin stack), SG-Dashboard (multi-site deploy, monitor, manage). Plus SG-Admin (single-site operations) and SG-Builder (visual page composition). Module count grows quarterly — see the changelog for the current shipped list.

What is this for?

This page defines the platform. It's the first thing you should read after landing in the docs. Everything else assumes you know the basic shape of what SGEN is and what each surface is responsible for.

The page does not explain how to use any specific feature. For that, open the relevant section landing and feature page. This page tells you the platform exists and how it's organized.

The five-surface model on this page becomes the backbone of every other doc. When SG-Builder → Component Library says "this component renders into the SG-Core page record," you'll already know what those two surfaces own. When SG-Dashboard → Live Analytics references SG-Modules events, the boundaries are familiar.

Good use cases

• You're evaluating SGEN and need a one-page summary of what it is.
• You're new to the platform and want the conceptual model before you start clicking around.
• You've been using SGEN for a while and want to refresh on which surface owns what.
• You're explaining SGEN to a teammate and need a clear definition to send them.
• You're hitting a behavior and want to know which product pillar it lives in.
• You're writing internal documentation that references SGEN and need a stable definition to link to.
• You're onboarding a new team member and want them to read one page before deeper docs.

When NOT to use this

• For sales narrative or competitive positioning — that's at sgen.com.
• For step-by-step setup — that's in How to Create a New Site in SGEN and the surrounding how-to articles.
• For specific feature documentation — open the relevant section landing first, then the feature page.
• For migration guides from WordPress, Squarespace, or Webflow — those live under Operations → Migration & Import.
• For pricing comparisons — those live at sgen.com/pricing and in the comparison pages under marketing.
• For roadmap and what's next — those live under Changes → Roadmap and What's New.

How this connects to other features

This page is the entry point. Every other page in SGEN Docs assumes you've read this one (or the equivalent).

• Why SGEN Exists — the problem statement that explains why the platform was built.
• How This Documentation Works — the reading order and content classes used in these docs.
• Documentation Map — the full IA so you know where every page lives.
• SG-Core, SG-Modules, SG-Dashboard, SG-Admin, SG-Builder — the five product surfaces this page introduces.

Who SGEN is for

The platform is built for operators who run sites — agencies, in-house teams, founder-operators, designers and developers who ship and maintain. The shape of the platform reflects what those operators do all day.

• Single-site owners. Founder-operators running one site as the front of their business. SG-Admin is your daily surface; SG-Dashboard is for billing and account view.
• Agencies and freelancers. Multi-client portfolios. SG-Dashboard is your daily landing; you move into SG-Admin for per-client work.
• In-house marketing teams. Brand site plus campaign landing pages plus content site. Centralized SG-Dashboard with role-bound team access through SG-Core Members.
• Designers and developers. SG-Builder for visual layout, Custom Codes for everything the builder doesn't cover, Theme Editor for templates.

If you're not yet operating a site on SGEN — for example, you're evaluating, comparing, or doing diligence — the marketing surface at sgen.com is a better starting point. The docs assume operating context.

Who SGEN is NOT optimized for

Honest scoping helps everyone:

• High-volume static-content publishers that need pure CDN-edge delivery without a CMS layer. SGEN is integrated; pure headless static-site setups have different ergonomics.
• Single-purpose web apps unrelated to content publishing. SGEN is a content platform first; building a custom SaaS product on top of it is possible (Custom Codes, custom objects) but isn't the primary path.
• Workflows that depend on a specific WordPress plugin that has no first-party SGEN equivalent yet. Check the SG-Modules current shipped list and the roadmap before assuming parity.

Reading time

This page takes about 5 minutes end to end. The downstream reads from here:

• Why SGEN Exists — 7 minutes.
• How This Documentation Works — 5 minutes.
• Documentation Map — 10 minutes (skim then return).
• Each section landing — 3 to 5 minutes.

Before you start

Two things to keep in mind while reading.

• SGEN replaces a stack, not a single tool. Coming from WordPress, you're used to picking a CMS, then adding a builder, then adding plugins. SGEN replaces all three layers. The docs sometimes assume that framing — re-read sections that confuse you with that lens.
• The platform is governed. Released changes go through a defined publish workflow. Planned work is tracked in Roadmap, not assumed in feature pages. The docs separate platform truth from intent — pay attention to which kind of page you're reading.
• Surface names are stable. SG-Core, SG-Modules, SG-Dashboard, SG-Admin, SG-Builder are the platform's product names. They're capitalized exactly that way across every customer surface. If you see a different spelling in older third-party content, the canonical names here are the source of truth.
• The five surfaces share data. Pages, users, settings, and media all live in one logical layer. Different surfaces give you different views and different tools, but they're operating on the same underlying state.

The five product surfaces

SG-Core

The foundation. Every SGEN site runs on SG-Core regardless of which modules are activated.

SG-Core owns the structural objects of the platform: user accounts and access rules, menus and navigation structures, the media library, pages and posts, reusable templates, custom objects (your own structured content schema), popups, blogs, and custom fields. These are the building blocks every other surface composes on top of.

Coming from WordPress, SG-Core is what you'd recognize as "WordPress core" — but consolidated, governed, and free of the plugin-extension model. Adding capability happens through SG-Modules, not by bolting third-party code into the core.

For a section-by-section walk, read SG-Core overview.

SG-Modules

The capability layer. First-party modules that replace the typical WordPress plugin stack.

Currently shipped modules cover forms, attributions, page builder, SEO, phone taps, ecommerce, redirects, tracking consent, discussions, events, locations, and more. Each module is built into the platform — installed, updated, and supported as a first-party feature, not as a third-party dependency. There's no plugin marketplace and no plugin-conflict failure mode.

When you need a capability that isn't in a module yet, the path is either Custom Codes (for behavior) or a feature request (which routes into the roadmap). Module count grows quarterly — see the changelog for the current shipped list.

Read SG-Modules overview.

SG-Dashboard

Multi-site command view. The surface where you see and control every site in your account.

SG-Dashboard owns portfolio rollup, the per-site control panel (Site Manager), live analytics aggregated across sites, billing, generated reports, the support widget, and the onboarding guides. If your account holds more than one site — agency, multi-brand operator, freelancer with five clients — SG-Dashboard is your daily landing page.

Customers running a single site can still use SG-Dashboard for billing and account-level views, but day-to-day work usually happens inside that site's SG-Admin.

Read SG-Dashboard overview.

SG-Admin

Single-site operating shell. Where day-to-day site work happens.

SG-Admin sits inside each site. From here you publish content, manage settings, access the staging and live environments, run backups, configure modules, and reach SG-Builder. It's the consolidated equivalent of WP-Admin — but governed, with cleaner boundaries between content, configuration, and environment.

If you've spent years in WP-Admin, SG-Admin will feel familiar in shape but quieter. Less plugin chrome, fewer competing dashboards, no notice strip stacking up.

Read SG-Admin overview.

SG-Builder

Visual page composition. Drag-and-drop layout with publish-ready output.

SG-Builder is the visual editor for pages, posts, and templates. It ships with native components (sections, columns, text blocks, images, forms, ecommerce blocks, posts blocks), six standard responsive breakpoints (1920 / 1199 / 991 / 767 / 575 / 480), and reusable patterns. The output is clean, semantic markup — no shortcode wrapper soup, no plugin-injected DOM.

Designers get the visual ease they came for. Developers get markup they can read and extend through Custom Codes.

Read SG-Builder overview.

Common confusion

A few concept boundaries that trip up new users.

"Is SG-Admin the same as SG-Dashboard?"

No. SG-Dashboard is account-level (every site in your account). SG-Admin is site-level (one specific site). The same person uses both — but on different surfaces, for different work. Multi-site operators move between them constantly.

"Where does the page builder live?"

SG-Builder is the visual editor. It's a surface inside SG-Admin (you reach it from the page or post you're editing). The component catalog and breakpoint sweep belong to SG-Builder. The page record itself is owned by SG-Core.

"Are forms part of SG-Core?"

No. Forms are a module — part of SG-Modules. SG-Core owns the page or post a form is embedded into; SG-Modules owns the form itself. This separation matters when you're looking for documentation: forms documentation lives under SG-Modules, not SG-Core.

"Why is ecommerce listed under both Operations and SG-Modules?"

Ecommerce is a module (capability surface) and an operating surface (daily ops view). The module documentation explains the feature; the Operations group documents the workflow of running a store. Same product, two angles.

"What happens when I add a custom domain?"

The domain is configured in SG-Admin under Settings, but the routing is handled by the platform layer. You configure the connection; the platform routes traffic. There's no DNS-plugin to install.

What it replaces

SGEN is positioned as an alternative to the WordPress + builder + plugin model. It keeps the familiar site-management patterns — pages, posts, menus, media, templates, themes — while removing the dependency sprawl, the update fragility, and the structural performance overhead that make legacy stacks harder to operate over time.

In concrete terms:

• WordPress core → SG-Core
• Elementor or other page builders → SG-Builder
• Plugin pile (forms, SEO, attribution, popups, etc.) → SG-Modules (first-party modules; current list in the changelog)
• Multi-site management plugins → SG-Dashboard (native)
• WP-Admin → SG-Admin (consolidated, governed)

That's not a feature comparison — it's the structural mapping. Read Why SGEN Exists for the operational reasoning.

Coming from a closed builder (Squarespace, Wix, Webflow)

The mapping is different but the spirit is the same. SGEN replaces:

• The visual editor (you keep the visual ease, gain code access through Custom Codes / Custom CSS / Custom Fonts).
• The single-site limit (SG-Dashboard scales account-level multi-site).
• The export ceiling (the .sgen backup format exports full site state; you own what's on the platform).
• The plugin equivalent (everything you'd reach for an integration to do is built in or available as a module).

Closed-builder users usually adapt fastest to SG-Builder and SG-Admin. SG-Modules feels new but is conceptually the simplest layer — modules are features, not extensions.

Coming from a headless setup

SGEN is not a headless CMS. The publishing model is integrated — content, layout, and rendering flow through the same surfaces. If headless was your previous model and you want to keep API-first delivery for some surfaces, the developer reference (under construction) covers what's exposed.

Steps

To understand SGEN at a system level, work through these reads in order.

1. Read this page (you're here).

You now know the five product surfaces and what each one owns.

2. Read Why SGEN Exists.

Names the operational pain the platform was built to fix. The architectural choices later in the docs make sense once you know the why.

3. Read How This Documentation Works.

Tells you the difference between guides, reference, changelog, what's new, roadmap, status. Saves you from looking in the wrong stream when you need a specific kind of answer.

4. Read Documentation Map.

Maps the full IA. After this, you can find any page. Bookmark it if you switch sections often.

5. Open the section landing that matches your role or task.

• Building pages → SG-Builder
• Operating sites → SG-Admin or SG-Dashboard
• Managing content structure → SG-Core
• Adding capability → SG-Modules

6. Walk one feature page end to end.

Pick a feature you use regularly. Read its page top to bottom. The shape of a feature page is consistent — once you've read one, the rest are faster.

7. Open the Architecture group.

For the architectural reasoning behind the platform's shape, Architecture → Zero Plugins and Architecture → No-Plugin Architecture explain the core structural choice.

What this page does NOT cover

To keep the page focused, the following are intentionally out of scope:

• Pricing and tier breakdowns. Live at sgen.com/pricing. The docs reference SG-Core tiers (Launch / Grow / Scale) where relevant but don't quote prices.
• Specific feature behavior. Open the feature page. This page only names the surface that owns the feature.
• Migration walkthroughs. The migration tooling has its own section under Operations → Migration & Import.
• API and developer reference. Under construction at /docs/reference/.
• Internal architecture. SGEN's internal infrastructure stays internal. Customer-facing docs describe behavior, not implementation.

What success looks like

You've understood "what SGEN is" when you can answer these without checking:

• Which product surface owns user accounts (SG-Core).
• Which product surface owns multi-site management (SG-Dashboard).
• Which product surface owns visual page composition (SG-Builder).
• Which product surface owns day-to-day operations on one site (SG-Admin).
• Which product surface owns plugin-replacement capability (SG-Modules).
• Why SGEN exists as an alternative (it replaces a stack, not a tool).

A second test: when a feature comes up in a teammate conversation ("does SGEN have X?"), you can name the likely surface in one breath. SEO → SG-Modules. Backups → SG-Dashboard. Pages → SG-Core. Layout → SG-Builder.

What to do if it does not work

• The five-pillar model still feels abstract. Open SG-Dashboard or SG-Admin in your account and walk through the actual UI. The docs make more sense once you've seen the corresponding screens.
• A feature you expected to find isn't here. It may live in a different surface than you'd guess (e.g. forms is in SG-Modules, not SG-Core). Use Documentation Map or search.
• A behavior contradicts this page. The platform evolves. Pages marked (stub) or pending may be ahead of the doc. Open a support ticket if it's blocking you.
• You're not sure which surface owns a problem. Pick the surface where you experienced the behavior. The section landing for that surface will redirect you if the underlying owner is different.
• The surface boundary feels wrong. It usually isn't — but if a real boundary case comes up, the team revisits the IA. Tell us through the page-level feedback affordance.

How the surfaces interact

SGEN's surfaces aren't siloed — they share the same data layer and route around it.

• A page lives in SG-Core. SG-Builder edits its layout. SG-Admin publishes it. SG-Dashboard sees its analytics. The same page record passes through all four surfaces.
• A user account lives in SG-Core. SG-Admin invites them into a site. SG-Dashboard rolls them up into account-level Members. SG-Modules lets them submit forms.
• A backup archive (.sgen format) is created in SG-Dashboard, restores into SG-Admin, and replaces the SG-Core records on the target site.

This is why no single surface is "the platform." The platform is the way they cooperate.

Boundary

This page defines the platform at a system level. It does not document specific features, exact feature behavior, or implementation truth. For that, open the relevant feature page or reference record. Treating this page as feature truth will mislead you.

The page also doesn't substitute for evaluation. If you're trying to decide whether SGEN fits a specific build, the marketing surface (sgen.com) and the section landings together give you the operational sense. The docs assume you've already chosen to evaluate or operate.

A one-paragraph summary

If someone needs the elevator definition: SGEN is a CMS platform built around five product surfaces — SG-Core (foundation), SG-Modules (capability layer that replaces typical plugins), SG-Dashboard (multi-site command view), SG-Admin (single-site operating shell), and SG-Builder (visual page composition). It's positioned as a WordPress alternative for teams that have outgrown the plugin-stack workflow. Module count grows quarterly; current shipped list is in the changelog.

How surfaces map to common operator tasks

A quick lookup for common questions:

The lookup is a starting point — for full feature documentation, open the relevant section landing.

What's coming next

The platform evolves on a regular release cadence. Two ways to track what's coming:

• Changes → Roadmap — planned and in-progress work that's been approved for public visibility. State labels (planned, active, shipped) make commitment level explicit.
• What's New — editorial highlights from notable launches and improvements. Hand-curated; not every changelog entry appears here.

If you've evaluated SGEN before and are returning, Changelog is the fastest read of what's changed since your last visit.

Where to find it

• The platform — operating surfaces live at dashboard.sgen.com (SG-Dashboard) and inside each site (SG-Admin / SG-Builder).
• The docs — docs.sgen.com (this surface).
• The marketing site — sgen.com for the buyer-facing positioning and pricing.
• The status surface — /docs/changes/status for the current operational condition.

Related reading

• Why SGEN Exists — Problem statement.
• How This Documentation Works — Reading model.
• Documentation Map — Full IA.
• SG-Core — Platform foundation.
• SG-Modules — Capability layer.
• SG-Dashboard — Multi-site command view.
• SG-Admin — Single-site operating shell.
• SG-Builder — Visual page composition.
• Architecture → Zero Plugins — Why SGEN replaces the plugin model.
• Architecture → No-Plugin Architecture — Deeper architectural reasoning.
• Operations → SEO & Performance — Practical operating surface.
• Changes → Changelog — What shipped recently, including current SG-Modules list.