Reference → SGEN 4-pillar platform diagram

SGEN platform pillars

SG-Core · SG-Modules · SG-Dashboard · SG-Builder — the relationship map

SGEN is built around four distinct pillars.
Each pillar owns a specific layer of the platform.
They compose — they do not duplicate.
Understanding which pillar owns which feature is the fastest path to knowing where to configure something, where to find its docs, and who to contact when something goes wrong.

What is this for?

Use this page when:

  • You are new to SGEN and need a map of what the platform contains.
  • You are not sure whether a feature belongs to SG-Core or SG-Modules (the line matters for which plan tier activates it).
  • A client asks what SGEN includes and you want a clear answer.
  • You are reading a Reference page and the pillar label is unfamiliar.
  • You are planning a site build and want to know which features require module activation.

Good use cases

Scenario 1: A client asks what the difference is between pages in the admin and pages in SG-Builder.
SG-Core owns the page list — creation, slug management, metadata, status.
SG-Builder is the visual layout editor that attaches to a page.
They are separate pillars with a handoff point: the admin creates the page, SG-Builder edits its layout.

Scenario 2: You are setting up redirects and are unsure which plan tier includes them.
Redirects belong to SG-Modules.
SG-Modules features are optional and plan-gated.
Check your plan's module entitlements in SG-Dashboard → Billing.

Scenario 3: You are onboarding a content editor who will only post blog articles.
Their entire workflow lives in SG-Core (blog management, categories, tags, media).
They do not need SG-Builder access unless they are building custom page layouts.

Scenario 4: Your client wants a real-time traffic overview.
That lives in SG-Dashboard → Analytics.
SG-Dashboard is the account-level portal, not the site-level admin.
The traffic data is aggregated there, not in the site's admin.

Scenario 5: You are writing a custom automation and need to know where the trigger configuration lives.
Automations span SG-Core (content events) and SG-Modules (integration-triggered actions).
The trigger configuration for site-level events is in the admin under Tools or Automations, depending on type.
Integration-driven automation uses the SG-Modules webhook and integration surfaces.

What NOT to use this for

This page describes the logical model.
It does not list every individual feature — each pillar has its own Reference page for that.
Do not use this page to look up a specific configuration setting.
Use it to identify which pillar to look in, then navigate to that pillar's Reference page.

This page does not describe plan tiers.
Which features are included in which plan is documented in the Billing section of SG-Dashboard and in the pricing documentation.
The pillar map tells you where something lives, not whether your plan includes it.

How this connects to other features

  • SG-Core Reference — the full surface map of the base platform. See SG-Core.
  • SG-Modules Overview — lists every available module and its activation state. See SG-Modules Overview.
  • SG-Dashboard — the account-level portal for subscription, billing, analytics, and site management. See SG-Dashboard.
  • SG-Builder Overview — the visual page editor. See SG-Builder Overview.
  • Governance Overview — how changes to the platform are released, including pillar-level breaking changes. See Governance Overview.

Before you start

No setup required.
This is a conceptual reference.
The four pillars are always active; they do not require configuration.
Individual features within each pillar may require activation (SG-Modules) or a specific plan tier (SG-Dashboard features).

Where to find it

docs.sgen.com → Reference → Platform Overview → SGEN 4-Pillar Platform Diagram.

Reference shape — the four pillars

1. SG-Core

SG-Core is the base platform.
It ships with every SGEN site.
No activation required.
No plan tier gates it.

SG-Core owns:

  • Blog — blog posts, categories, tags, RSS, related posts, sitemap inclusion.
  • Pages — page creation, slug management, meta, status, revision history.
  • Media Library — file upload, optimization, attachment management.
  • Custom Objects — define custom content types beyond pages and posts.
  • Custom Fields — attach typed fields to any Custom Object or post type.
  • Menus — navigation structure, menu items, menu placement.
  • Popups — popup creation, targeting rules, display triggers.
  • Users — user accounts, roles, access management at the site level.
  • Templates — reusable page and post templates.
SG-Core does not own: module-gated features (SEO, redirects, tracking consent, ecommerce), the account portal, or the visual editor.

The SG-Core admin surface is /sg-admin/ on any SGEN site.

Reference: SG-Core.

2. SG-Modules

SG-Modules is the optional feature layer.
Modules extend SG-Core with capabilities that not every site needs.
Each module is activated independently.
Plan tier determines which modules are available.

Active SG-Modules features include:

  • SEO Module — sitemap generation, meta tag controls, Open Graph, structured data, per-page SEO settings.
  • Redirects Module — 301/302 redirects, bulk import, regex matching, 404 monitor.
  • Tracking Consent Module — cookie consent banner, category-gated script loading, GDPR/CCPA compliance configuration.
  • Ecommerce Module — product catalog, orders, checkout, payment gateway integration, coupons.
  • Forms Module — form builder, submissions inbox, integrations, export.
  • Analytics Module — visitor tracking, event logs, traffic reports (site-level, not account-level).
  • Attributions Module — source tracking, UTM capture, first-touch attribution.
SG-Modules features appear in the admin sidebar only when the module is active for that site.A module that is not active for a site produces no admin menu item and no public-side output.

Reference: SG-Modules Overview.

3. SG-Dashboard

SG-Dashboard is the account-level portal.
It is distinct from the site-level admin.
Every SGEN account has one SG-Dashboard instance.
Site-level admins (/sg-admin/) are accessed from SG-Dashboard; SG-Dashboard is not accessed from a site's admin.

SG-Dashboard owns:

  • Site Manager — list of all sites under the account, status, staging/live toggle.
  • Client Manager — client accounts, access grants, white-label settings.
  • Billing — subscription management, plan tiers, module entitlements, invoices.
  • Analytics — account-level traffic aggregation across all sites (distinct from site-level analytics).
  • Advanced Settings — account-wide configuration, domain management, API keys.
SG-Dashboard is the right place to:
  • Create or delete a site.
  • Grant a client access to their site.
  • Upgrade a plan or add a module entitlement.
  • Check aggregate traffic across a portfolio.
SG-Dashboard is the wrong place to:
  • Configure a specific site's SEO settings (that is in the site admin, SG-Modules → SEO).
  • Manage blog posts or pages (that is in the site admin, SG-Core).
  • Edit a page layout (that is SG-Builder).
Reference: SG-Dashboard.

4. SG-Builder

SG-Builder is the visual page editor.
It edits the layout of a page or post after that page has been created in SG-Core.
It does not own content metadata (slug, status, publish date) — SG-Core owns those.
It owns the visual structure: sections, columns, components, styles.

SG-Builder owns:

  • Builder Workspace — the visual canvas, layer manager, component palette.
  • Component Library — Basic Blocks, Posts Blocks, Ecommerce Blocks, Extra Blocks.
  • Styles Panel — per-component and global style controls.
  • Responsive Preview — breakpoint switching for mobile, tablet, desktop.
  • Publish — pushing a built layout live to a page.
SG-Builder does not own:
  • The page's URL slug (SG-Core).
  • The page's SEO meta (SG-Modules → SEO).
  • The site's global navigation (SG-Core → Menus).
  • The site's global CSS (SG-Core → Custom CSS or Custom Codes).
SG-Builder is launched from the page or post detail view in the admin, via the "Open in SG-Builder" button.

Reference: SG-Builder Overview.

Steps

1. Identify the feature you are working with

Name the specific feature: "redirects," "blog categories," "visual page layout," "account billing."

2. Map it to a pillar

Use the table below.

If the feature is...It belongs to
Content creation, media, menus, users, custom fields, custom objects, popups, templatesSG-Core
SEO, redirects, consent, ecommerce, forms, analytics (site-level), attributionsSG-Modules
Site management, client management, billing, account-level analytics, domain managementSG-Dashboard
Visual page layout, component editing, responsive styles, SG-Builder canvasSG-Builder
If the feature does not fit any of the above, it is likely a core admin utility (Tools, Configuration, Custom Codes) — those sit under SG-Core's admin surface.

3. Navigate to the pillar's Reference or admin surface

Use the links in this page's "How this connects" section to reach the Reference page for the relevant pillar.
Or navigate in the admin: SG-Core features are in /sg-admin/; SG-Modules features are in /sg-admin/ (when active); SG-Dashboard is a separate login.

4. Confirm the feature is active

SG-Core features are always available.
SG-Modules features require activation.
Check the admin sidebar — if the module's menu item is absent, the module is not active.
Activate it via SG-Dashboard → Billing or contact your account manager.

Verification

After reading this page, you should be able to:

  • Name the four pillars without looking at this page.
  • Assign any of the listed features to the correct pillar.
  • Explain why a feature appearing in one pillar cannot be configured via another pillar's admin surface.
  • Know where to find the admin entry point for each pillar.

Technical details — how pillars compose

The four pillars are not independent codebases.
They compose at defined handoff points.

SG-Core → SG-Builder handoff: a page or post in SG-Core can have a layout built in SG-Builder.
The SG-Core admin stores the page's metadata.
SG-Builder stores the page's layout data.
When SG-Builder publishes, it writes layout HTML into the SG-Core page record.

SG-Core → SG-Modules handoff: SG-Modules features read from SG-Core entities.
The SEO Module reads the page slug from SG-Core to generate sitemap entries.
The Redirects Module intercepts the request router that SG-Core uses for URL resolution.

SG-Dashboard → SG-Core handoff: SG-Dashboard provisions sites and controls access.
When a site is created in SG-Dashboard, it instantiates a SG-Core instance.
Access grants in SG-Dashboard determine who can log in to the site's admin.

SG-Dashboard → SG-Modules handoff: module entitlements are set in SG-Dashboard at the account level.
The site's admin enforces those entitlements — it shows or hides modules based on what SG-Dashboard has authorized.

Notes

Note: "SG-Admin" is internal terminology.
"SG-Admin" is a code-level name for the administrative interface owned by SG-Core.
Customer-facing docs say "the admin" or "the SGEN admin."

Note: modules do not add new admin sections for every site.
Modules add admin surfaces only for the sites that have them active.
A portfolio of 10 sites can have different modules active on different sites.
The Reference docs describe all modules; the admin shows only what is active.

Note: SG-Dashboard is not "the admin."
The admin is site-level: /sg-admin/.
SG-Dashboard is account-level: a separate domain or subdomain depending on deployment.
The two are linked but not the same surface.

On this page