Getting Started with SGEN
Orient quickly, then move into the first productive actions.
Getting started with SGEN should not take days. The first objective is straightforward: understand the operating model, find the core controls, and complete the actions that create real momentum on the new site.
This guide is the orientation read for operators who signed up. It pairs with Getting Started with the SGEN Admin for the operator-surface tour and How to Build First Site in SGEN for the build sequence.What is this for?
Read this page on your first day with SGEN, before you open the editor for serious work. It establishes the operating model, names the core areas, and sets the standards that make the rest of the work go faster.
Good use cases
- You signed up for SGEN and want to know what to do first.
- You are evaluating SGEN against another platform and want to understand how it expects to be used.
- You are onboarding a teammate to SGEN after handling the early decisions yourself.
- You hit a question like "What should I be paying attention to in the admin before I start building?"
What NOT to use this for
- Step-by-step build instructions — open How to Build First Site in SGEN.
- Admin-surface walkthrough — open Getting Started with the SGEN Admin.
- Migration from a specific platform — open the migration guide for that platform if one exists.
Before you start
You should have:
- An SGEN account with a site provisioned.
- Your business name, primary email, and a short description of what the business does.
- A rough idea of what you want the site to accomplish in its first version.
How this connects to other features
- Getting Started with the SGEN Admin — operator-surface tour.
- How to Build First Site in SGEN — build sequence after orientation.
- How SGEN Replaces Your Traditional WordPress Stack — context for operators arriving from WordPress.
- Pages — the engine surface most early work targets.
Where to go
Open the admin Dashboard. From there, walk through Settings, Pages, Forms, and Analytics in order. The walk takes 10-15 minutes and gives you the orientation the rest of this guide assumes.
How to get started — the first hour
Steps — Orient and complete the first setup pass
1. Understand the operating model
SGEN is built around control rather than around plugins. Where older platforms treat the site as a base WordPress install plus dozens of plugins that each fix one thing, SGEN treats the site as one coherent system: structure, design, content, analytics, forms, and publishing all live in the same admin under the same operating model.
That choice matters because it changes how operators should think about the work. There is no "find a plugin for that" instinct in SGEN; the platform either covers the workflow natively or directs you to the right module. Most workflows are covered natively.
The practical consequence: your first pass should focus on structure, settings, and publish discipline before exploring design detours or speculative customization. The operating model rewards the discipline of getting the basics right early.2. Complete the first setup pass
Open Settings and confirm site identity before you build anything. That means: site title, primary email, homepage choice, time zone, and any global SEO defaults that should not be left vague. The first setup pass is where the values you set ripple through the rest of the site.
Site identity is the one piece operators most often skip on first day and most often regret later. The site title shows up in browser tabs, email-from headers, sitemap entries, social-share previews. Setting it once early is cheaper than fixing every downstream surface later.
After site identity, walk the core admin: Dashboard, Pages, Forms, Analytics, Settings. Open each at least once so you know where the core workflows sit. The walk takes 10-15 minutes and pays back across every later session.3. Build only what supports the business
Start with pages and flows that carry weight: the homepage, the main service or offer pages, the contact path, and any location or support pages that materially affect discoverability or conversion.
Do not pad the site with speculative pages because they "feel like every site has them." A smaller complete system is stronger than a larger unfinished system. Visitors read finished work as confident; they read half-done work as effort-without-substance.
The build sequence is in How to Build First Site in SGEN. This guide gets you to the moment of opening that build sequence; the build itself is the next read.
4. Set the standard early
Use drafts when the work is not ready. Review site structure before you publish. Keep copy, navigation, and calls to action aligned so the site feels deliberate from the start.
Treat the first version as the standard that future work will follow. Loose setup decisions multiply later — inconsistent heading sizes, ad-hoc CTA language, divergent navigation patterns — each of which costs time to fix every time it matters.
The discipline of "set the standard early" pays off most when the team grows. Standards encoded into the first version stay; standards introduced later have to be retrofitted across whatever shipped before them.
5. Confirm publish discipline
Before publishing the first version, walk through:
- The homepage on desktop and mobile.
- The conversion path (homepage → offer page → contact form or scheduling link) on desktop and mobile.
- Settings (site title, email, homepage choice, time zone) match what you intended.
- The navigation reflects the actual site (no broken links, no missing primary pages).
What success looks like
A successful first hour with SGEN looks like:
- The Settings page is configured with site title, email, homepage, time zone, and SEO defaults.
- The Dashboard, Pages, Forms, Analytics, and Settings pages have all been opened at least once.
- A page list for the first build is written down (six to ten pages for most small businesses).
- The team has a shared understanding of the operating model — control-first, plugin-skeptical, native-coverage-first.
- The next step is clear: open How to Build First Site in SGEN and start the build sequence.
What to do if it does not work
The admin feels overwhelming. Usually a sign of trying to absorb every module at once. Walk only the five core surfaces (Dashboard, Pages, Forms, Analytics, Settings); ignore everything else for the first session. The platform is large; orientation does not require knowing every module.
Settings choices feel premature. Sometimes operators delay site identity decisions because the business is still being shaped. Set the values to honest first-pass answers; the values are easy to update later. The cost of leaving them blank exceeds the cost of revising them.
The page list keeps changing. Page-list churn usually reflects unresolved decisions about what the site is for. Resolve those off-platform — write a short statement of who the site serves and what action it should drive — then return to the page list. The list usually stabilizes once the upstream decision is made.
Habits from older platforms slow the work. Operators arriving from WordPress sometimes look for plugins for workflows SGEN covers natively. The shortcut: when you find yourself thinking "I need a plugin for X," check the SGEN admin first. The native coverage is broader than older platforms and usually cleaner.
Best practices
- Keep the initial build lean and intentional.
- Use internal links between admin areas so the operator experience never feels like a dead end.
- Build around outcomes: publish cleanly, collect leads cleanly, maintain control as the site grows.
- Set Settings early; revise as needed; don't leave them blank.
- Move from this orientation guide directly into the build sequence — orientation followed by action keeps momentum.
Common questions
How long should orientation take? First hour for the basics. First day for orientation plus the first build pass. Operators arriving with content ready can have a first version published in a single working day.
Do I need to read every doc before I start? No. Read this guide, the SGEN Admin orientation, and the first-site build guide. That covers the orientation. Other docs are reference material to consult as questions come up.
What if I came from WordPress? Read How SGEN Replaces Your Traditional WordPress Stack. It addresses the most common adjustments WordPress operators make.
What if I came from another modern site builder? The operating model is similar in shape but different in detail. Walk the five core admin surfaces; the differences will become visible quickly.
How much can I customize on day one? Anything is technically possible. Whether anything should be customized on day one is a separate question — usually no. Start with platform defaults, ship the first version, customize where the gap is real after the launch.
A walk through the five core admin surfaces
The five surfaces every operator should open during the first setup pass, in order, with what to look for.
Dashboard. Open first. The Dashboard is where high-level signal lives — recent activity, system status, quick navigation to common workflows. On a brand-new site it is mostly empty; the value is knowing where the surface lives so you can return to it as the site fills up.
Pages. The page-list surface. New sites start with one or two stub pages depending on how the account was provisioned. Open Pages, see what is there, look at the per-page status pill (Draft / Published / Scheduled). The Add New button is the entry point to creating new pages; the per-row Edit affordance opens a page in SG-Builder.
Forms. The form-management surface. New sites start without any forms. The Forms surface is where forms are created, edited, and where submissions land. Most sites add at least one form (contact) early; complex sites add several.
Analytics. The analytics surface. New sites have no traffic yet, so the surface is mostly empty on the first day. The value of opening it on day one is knowing the navigation — Event Logs vs Reports, the time-range picker, the per-page breakdown affordances. Once traffic arrives, the surface is the operator's primary feedback loop.
Settings. The site-identity surface. This is the surface to spend the most time on during the first setup pass. Site title, primary email, homepage, time zone, global SEO defaults, social links. Each value flows into multiple downstream surfaces; getting them right early avoids per-surface fixes later.
What you can skip on day one
Beyond the five core surfaces, the SGEN admin includes Templates, Custom Fields, Custom Objects, Popups, Redirects, Phone Taps, Tracking Consent, Locations, Events, Media Library, and several others. Most of these can be ignored during the first setup pass; they become relevant as the site grows.
A useful heuristic: if you don't yet need the surface, skip it. The platform doesn't punish operators for ignoring surfaces they aren't using; the surfaces stay quiet until invoked.
The two exceptions are SEO defaults (set them in Settings on day one) and Tracking Consent (configure it before the site goes live, because GDPR compliance matters from the first visit). Both are quick to set; the cost of setting them is small, the cost of forgetting them can be larger.
Common terminology you'll encounter
A handful of terms recur across the SGEN admin and across this documentation. Knowing them upfront speeds up later reading.
Operator — anyone with admin access to the site. This documentation uses "operator" for the role rather than "user," because "user" gets used for visitors and authenticated end-users in other contexts.
Record — a stored content item. Pages, posts, products, form submissions, custom-object instances are all records. The platform treats them with the same underlying storage and integration surface; the differences are operator-facing.
Module — a self-contained area of the SGEN admin. Pages, Forms, Analytics, Settings, Templates, and the others are each modules. Modules compose; they don't usually overlap.
Surface — an area of the admin where operators interact. Each module has one or more surfaces (Pages has the list surface and the editor surface, for example).
Render — the act of producing the page a visitor sees. Records render through templates; templates compose components; the rendered result is what visitors load.
Publish — moving a record from draft state to live, visible state. Publishing is a deliberate action; nothing on SGEN goes live without an explicit publish.
The terms are not unique to SGEN, but the meanings are specific to how SGEN uses them. Operators arriving from other platforms occasionally bring different definitions; the definitions above are what this documentation assumes.Working with a team
If more than one person will be using SGEN, the orientation arc applies to each of them. The first hour for the team's first operator is the orientation read above; the first hour for additional operators is mostly understanding what the first operator already configured and where the team's standards live.
A practical pattern for teams: the first operator completes the first setup pass, writes a short internal note about the choices made (Settings values, naming conventions, navigation patterns), then onboards the next operator with the note and the standard documentation together.
The platform handles multi-operator workflows natively.
Multiple operators can edit the same site without stepping on each other.
Revisions track who changed what.
The admin remembers per-operator preferences across sessions.
None of that requires per-team configuration; it works out of the box.
For teams larger than a few operators, the platform's role-and-permission system limits which operators can publish, which can edit, and which only have read access — useful when contributors should not have full publishing rights.
Day one to day seven
A useful mental model for the first week of using SGEN.
Day one — orientation, first setup pass, first build pass. Goal: a publishable first version of the site.
Day two — refine the priority pages based on day one's review. Add the contact form. Configure SEO frontmatter for the priority pages. Verify navigation is tight.
Day three — secondary pages (About, location, support). Connect any third-party tools that need configuration (email-sending domain, analytics integrations, payment gateway if applicable).
Day four — first publish. Walk the site one more time on desktop and mobile. Verify the conversion path. Hit publish.
Day five through seven — observe. Visitor behavior reveals what content needs to be sharper, what pages are missing, what navigation entries should change. The first week of real traffic teaches more than any amount of pre-launch second-guessing.
The week pattern is a default rather than a target. Some operators move faster (a brochure site can launch in a single day); some take longer (sites with complex content need more time on the priority pages). The shape — orient, build, publish, observe — applies regardless of pace.
What to ignore in the first week
The temptation to optimize before launching is the most common first-week trap. Site speed tuning, advanced SEO configuration, custom analytics events, design-system polish — all of these belong in week two or later.
The first week's goal is a published site that gets real visitors. The second week's goal is using what those visitors did to inform what to work on next. Optimizing before having visitor data optimizes the wrong things.
What changes after the first hour
Once the orientation is done and the first setup pass is complete, the work shape changes. The first hour is mostly absorbing the platform; the next hour is mostly using it.
Building pages. With Settings configured and a page list written, opening Pages and adding records is the natural next step. Each page picks up the Settings defaults (site title, social links, SEO frontmatter) automatically.
Adding a contact form. Most sites add at least one form on day one. The Forms module lets you create the form, configure where submissions go, and embed the form on a page through SG-Builder. Submissions land in the Forms admin and (where configured) flow to email.
Configuring analytics. Analytics works out of the box; the configuration step is mostly choosing what events to track and what reports to monitor. The platform-default events cover most needs (page views, form submissions, popup engagement); operators add custom events when the standard set doesn't cover a specific workflow.
First publish. Publishing the first version is a deliberate action. The platform doesn't auto-publish anything; the operator clicks Publish on each record when ready. The site is private until at least one page is published.
What stays the same
The operating model is consistent across the first hour and every subsequent session. The discipline that pays off in the first hour (control-first, native-coverage-first, set the standard early) keeps paying off as the site grows.
Operators who absorb the model early have an easier time scaling the site; operators who continue thinking in plugin-stack terms run into friction when they encounter SGEN modules that don't fit the plugin metaphor.
Habits worth building
A handful of habits compound over time and are worth establishing during the first hour.
Always preview before publishing. SG-Builder previews are faithful to the rendered site. The 30 seconds spent previewing a page on desktop and mobile before publishing catches most last-minute issues.
Use drafts liberally. Drafts cost nothing and let work accumulate before going live. Publishing a partial state in production is rarely the right move.
Set Settings before building. The values in Settings flow into every page header, every email, every social-share preview. Setting them early is cheaper than fixing them later.
Check Analytics weekly. Once the site is live, Analytics is the feedback loop. Operators who check it weekly notice problems and opportunities early; operators who don't tend to discover both late.
Keep the navigation tight. Every primary page should be reachable in one click from the homepage. As the site grows, the navigation should grow proportionally — not faster.
About the operating model
The SGEN operating model is the underlying assumption that the platform should cover the workflows a site needs natively rather than through layered plugins. Operators who absorb the operating model early find the rest of SGEN easier to learn; operators who continue thinking in plugin-stack terms run into friction at every workflow boundary.
Two practical signs the operating model has clicked:
- You stop searching for plugins for workflows you need.
- You read the SGEN admin's surface labels and recognize them as the workflows themselves rather than as gatekeepers to plugin configuration.
About core workflows
The core workflows on SGEN are: build pages, capture form submissions, track analytics, manage SEO, publish changes, manage media. Each has its own admin surface; each is documented in its own reference page.
Core workflows compose naturally — a page captures a form submission which triggers an analytics event which surfaces in a report which informs the next round of content work. Operators who learn the core workflows in order (pages first, forms second, analytics third) find the composition easier to use than operators who learn them in random order.
About site identity
Site identity is what makes the site look like one coherent thing rather than a collection of pages with the same domain. The Settings page is where identity is configured; the values from Settings flow into every page header, every email-from, every social-share preview, every sitemap entry.
Setting site identity well early is one of the highest-payoff actions in the first hour. The cost is low (a few minutes); the downstream effect is across every visitor-facing surface.
Reading order
Read this guide first. Then Getting Started with the SGEN Admin. Then How to Build First Site in SGEN. The three guides compose into a complete first-day arc: orient → tour → build.
If you arrive from WordPress, add How SGEN Replaces Your Traditional WordPress Stack to the read list — it covers the adjustments WordPress operators most often make.