How to start with SGEN Docs

You're in the right place if you want to know what SGEN does, how the platform is structured, or where the exact answer to your question lives.

These docs are organized so the work is fast: orientation first, product surfaces next, deeper reference when you need it. Nothing buried. No hunting through plugin docs that don't quite apply. The structure follows the platform.

What is this for?

SGEN Docs is the official documentation surface for the SGEN platform. It covers the product (SG-Core, SG-Modules, SG-Dashboard, SG-Builder), the operational surfaces (analytics, security, ecommerce, SEO and performance), the architecture (zero plugins, no-plugin architecture, performance, stability), and the change streams (changelog, roadmap, status, what's new).

You read these docs to operate SGEN — not to evaluate a CMS. If you're still in evaluation mode, sgen.com is the better starting point. If you're inside the platform and you need to do something, you're in the right place.

Good use cases

• You signed up recently and want to know what to do first.
• You need to understand the difference between SG-Core, SG-Modules, SG-Dashboard, SG-Admin, and SG-Builder.
• You're looking for a specific feature and want the page that explains how to use it.
• You shipped something and need to know what changed in the latest release.
• You're hitting an issue and want to know if it's a known status event.
• You're planning a build and want to see what's on the roadmap.

When NOT to use this

• For the marketing pitch — that's at sgen.com.
• For pricing and plans — that's at sgen.com/pricing.
• For internal SGEN operations or platform admin — those live in private internal docs, not here.
• For external developer SDK reference — that's the separate /docs/reference/ surface (under construction).

How this connects to other features

Every page in SGEN Docs sits inside one of seven groups. Knowing the group helps you find the page faster.

• Start Here — orientation (this group). What SGEN is. Why it exists. How to read these docs.
• Platform — the product surfaces themselves: SG-Core, SG-Modules, SG-Dashboard, SG-Builder, plus Workflows and Integrations.
• Operations — practical operating surfaces that span the platform: ecommerce, UX, analytics, SEO and performance, security, tools.
• Architecture — the platform position: zero plugins, no-plugin architecture, updates and stability, performance and reliability, infrastructure overview.
• Changes — released changelog, planned roadmap, current status. Three separate streams.
• What's New — editorial highlights from launches and notable updates.
• Reference — structured per-feature reference (under construction).

The left sidebar shows the full hierarchy. The top nav switches groups. Search cuts across everything.

Before you start

A couple of things to know before going deeper.

• There's a difference between staging and live. Most SGEN sites have both. Staging is where you work. Live is what the public sees. Several pages in these docs assume you understand that distinction.
• SGEN replaces a stack, not only a CMS. If you're coming from WordPress + Elementor + the typical plugin stack, the operating model here is different. The docs explain the differences as they come up. Lean on the Why SGEN Exists page for the framing.
• The docs evolve with the product. Pages marked (stub) or pending are placeholders. Use search to find the most current version of a page, not the older corpus link.
• Authentication is optional for reading. The public surface answers the public question. Some pages have additional content visible after authentication — internal links, deeper operational notes — but the public version is canonical for what customers need.
• The platform has multiple touch surfaces. SG-Dashboard at dashboard.sgen.com for multi-site control. SG-Admin inside each site for day-to-day work. SG-Builder for visual composition. The docs name which surface a given task lives on.

Where to go

The fastest path depends on what you're doing right now.

If you're new to SGEN

1. Read What is SGEN for the platform definition.
2. Read Why SGEN Exists for the problem the platform solves.
3. Open Documentation Map to choose your section.

If you're operating an existing SGEN site

• Open SG-Dashboard if you're managing more than one site.
• Open SG-Admin if you're working inside one specific site.
• Open SG-Builder if you're composing pages.

If you're shipping or releasing

• Changelog for what released recently.
• Roadmap for what's planned.
• Status for current operational state.
• What's New for editorial highlights.

If you're hitting a problem

• Search first.
• If search doesn't find it, open the section landing for the relevant surface and check related pages.
• If it's still missing, the docs may not cover it yet — open a support ticket.

Routes by entry point

How you got here changes which page is the right next click. The four common entry points:

If you got here from sgen.com

You came in through the homepage or a marketing page and clicked through to learn the operating reality. The fastest read order:

1. What is SGEN — five product surfaces, one paragraph each.
2. Why SGEN Exists — the problem the platform answers.
3. SG-Core overview — the foundation every site runs on.

After those three, you understand the shape of the platform. The rest of the docs make sense.

If you got here from a search engine

You searched for a specific question and landed on a deep page. Two things help:

• The page you landed on has a section landing above it in the breadcrumb. Open that landing first if the page feels disconnected from context. The landing tells you what's around the page.
• Use the left sidebar to see the section's full contents. Adjacent pages often answer the next question you'll have.

If the page you landed on is marked (stub) or pending, open a support ticket — that surface exists in the platform, but the doc isn't ready yet.

If you got here from a customer link or teammate

Someone sent you a direct URL. Read the page they sent first. Then check the breadcrumb to see where it lives. If the topic is new to you, jump back to What is SGEN for one paragraph of context, then return to the page.

If you're returning

You've used SGEN Docs before and know roughly where things live. The fastest paths:

• Search bar for known feature names.
• Documentation Map if you forgot which group a surface lives in.
• Changelog if you're checking what's new since your last visit.
• Status if something feels off in your account.

Routes by audience segment

SGEN serves different operator profiles. Pick the one that matches and follow the path.

Single-site owner

You run one site. You're the founder, operator, or owner-builder. You came from WordPress, Squarespace, or Wix.

1. What is SGEN — platform definition.
2. SG-Admin overview — single-site operating shell where day-to-day work happens.
3. SG-Core overview — content, users, menus, media — the foundation.
4. SG-Builder overview — visual page composition.

You'll mostly live in the admin and SG-Builder. SG-Dashboard becomes relevant if you add a second site.

Agency operator

You run client sites. Five, fifteen, fifty. Multi-site is your daily reality.

1. What is SGEN — platform definition.
2. SG-Dashboard overview — multi-site command view.
3. SG-Dashboard → Site Manager — per-site control.
4. SG-Dashboard → Live Analytics — cross-site reporting.

Bookmark Changelog and Status for daily reference. Site Manager and Stage & Live become daily-driver tabs.

WordPress users moving to SGEN

You're moving off WordPress. You want the same flexibility without dependency on third-party plugins.

1. Why SGEN Exists — the operational pain that named the project.
2. What is SGEN — what replaces what.
3. Architecture → Zero Plugins — the structural answer.
4. Migration & Import — the path off WordPress.

The plugin-equivalence map under SG-Modules overview tells you which native module replaces which WordPress plugin category.

Squarespace, Wix, or Webflow users moving to SGEN

You're moving off a closed builder. You want code access and ownership without losing the visual ease.

1. What is SGEN — platform definition.
2. SG-Builder overview — the visual editor.
3. Custom Codes — direct code access for what the builder doesn't cover.
4. Theme Editor — full control of templates.

The .sgen backup format means your site state is portable. Export any time.

Returning user (paused or trial)

You started SGEN, paused, and came back. Two reads orient you fast:

1. Changelog — what shipped while you were away.
2. What's New — the editorial highlights.

Then return to whichever section you were last working in.

Steps

To get the most out of SGEN Docs, work through them in this order on your first session.

1. Read What is SGEN.

Five minutes. Defines the platform at a system level so the rest makes sense. Pay attention to the five product surfaces and what each one owns.

2. Read Why SGEN Exists.

Names the operational pain SGEN was built to fix. If you've lived through the WordPress plugin stack, you'll recognize the framing. If you're new to that pain, the page still gives you the architectural reasoning behind the platform's shape.

3. Read How This Documentation Works.

Tells you the difference between guides, reference, changelog, what's new, roadmap, and status. Saves you from reading the wrong type of page when you need a different one. After this, you stop conflating "what's new" with "what changed."

4. Read Documentation Map.

Maps the full IA. After this, you know where every page lives. Bookmark this page if you switch between sections often.

5. Open the section landing for the work you're doing.

Don't go directly to a feature page. Read the section landing first — it tells you what's in the section and what relates to what. The landing also names the prerequisites you should have read first.

6. Bookmark the streams you'll return to.

Most operators bookmark Site Manager, Stage & Live, Changelog, and Status. Designers bookmark SG-Builder Component Library and Site Settings.

7. Use Search across all classes.

Search returns matches from Guides, Reference, Changelog, What's New, and Roadmap together. Narrow by class with the filter chips when you need only one stream.

What success looks like

You're using SGEN Docs well when:

• You can find a feature page in under 30 seconds.
• You know whether a question belongs in Changelog, Roadmap, or Status without thinking about it.
• You read the section landing before the deep page (and notice when you skipped that step).
• You bookmark sections you return to often instead of re-navigating from the homepage.
• You stop using outdated bookmarks and let the canonical IA be the source of truth.

A second test: when a teammate asks you a question, you can paste a direct URL to the answering page rather than "go look in the docs." If you can do that consistently, you've internalized the IA.

What to do if it does not work

A few common things.

• A link is broken. The docs realigned the IA recently (2026-04-30). Old /guides/ and /docs/start/ URLs are superseded — use /docs/start-here/* and the canonical paths shown in the sidebar.
• A page says stub-pending-content. That surface exists in the platform but the doc isn't written yet. Open a support ticket if you need it urgently.
• Search returns nothing useful. Try the section landing for the relevant surface. The keyword may be tagged differently than you expect.
• You can't tell which surface a feature belongs to. Use Documentation Map. It groups every surface by category.
• The page describes behavior you don't see in your account. Check the page's last_updated date. The platform evolves; the doc may have caught up before your account got the change. Open a ticket if it's blocking.
• A page conflicts with another page. Reference is most precise. Guides are most readable. Changelog and Status are most current. The most recent stream usually wins.

If something contradicts what you see in the actual SGEN UI, the UI wins. Capture the discrepancy and open a support ticket — the docs may need to update.

How feedback gets back into the docs

Every page has a feedback affordance. Use it when:

• A step doesn't match what you see in the UI.
• A claim looks outdated since the platform shipped a change.
• A linked page returns 404 or stub content.
• A code example or shortcode doesn't behave as documented.

Feedback routes to the docs team. Substantive corrections roll into the next docs release. Critical errors (broken security guidance, wrong default in a destructive action) ship as same-day patches.

Reading time budget

Rough estimates so you can pace yourself:

• What is SGEN — 5 minutes.
• Why SGEN Exists — 7 minutes (longer because of the pain framing).
• How This Documentation Works — 5 minutes.
• Documentation Map — 10 minutes (reference-heavy; skim first, return to detail).
• Section landings — 3 to 5 minutes each.
• Feature pages — 5 to 15 minutes each, depending on depth.

A first-pass orientation (the four start-here pages plus one section landing) takes about 30 to 35 minutes. After that, you read feature pages on demand.

What you should NOT do on day one

• Don't try to read every section landing in one sitting. Pick the section that matches what you're doing today.
• Don't deep-link to feature pages from the search results without reading the section landing first. The landing is the orientation.
• Don't expect Reference to be complete on day one — it's under construction. Use Guides for the readable narrative.
• Don't memorize URLs. The IA realigned in 2026-04-30 and will continue to evolve. Use the sidebar and search.

Related reading

• What is SGEN — Platform definition.
• Why SGEN Exists — Problem statement.
• How This Documentation Works — Reading model.
• Documentation Map — Full IA.
• SG-Core — Foundation.
• SG-Dashboard — Multi-site command view.
• SG-Admin — Single-site operating shell.
• SG-Builder — Visual page composition.
• SG-Modules — Capability layer.
• Architecture → Zero Plugins — Structural answer to plugin dependency.
• Changes → Changelog — Released history.
• Changes → Status — Current operational state.

Related reading

Topic
Documentation Map
Welcome to SGEN Docs
How This Documentation Works
SGEN in 90 seconds
What is SGEN
Why SGEN Exists
In this guide
---
What is this for?
Good use cases
When NOT to use this
How this connects to other features
Before you start
Where to go
Routes by entry point
Routes by audience segment
Steps
What success looks like
Property	Value
---	---
title	Welcome to SGEN Docs
description	SGEN Docs — start here. The documentation home for understanding what SGEN is, h
audience	public
classification	PUBLIC
audit_at	2026-05-14