SGEN multi site architecture overview
⏱ 60-second answer below · full page ≈ 10 min · skim the bold lead-ins to move faster.
The 60-second answer. Under one SGEN account you can run multiple fully isolated sites. Each site has its own content, settings, media library, member list, and audit trail — nothing bleeds between sites. Switch between them without logging out: open SG-Dashboard (your account home), click any site name in the list. Roles are per-site — the same person can be Admin on one site and Editor on another. Inviting someone to Site A gives them no access to Site B; each invitation is site-specific. Account-level things shared across all sites: your login credentials, billing plan, and the SG-Dashboard site list itself. That's the gist — everything below is the same idea in depth.
On this page: The site as the unit of isolation · Per-site isolation: what stays separate · Role behavior across multiple sites · Good use cases · Examples · Common questions
The site as the unit of isolation
In SGEN, a site is the complete, self-contained publishing environment for one domain. It has:
- Its own content: pages, blog posts, custom objects, forms, media
- Its own settings: site name, primary URL, timezone, SEO defaults, integrations
- Its own brand configuration: theme, colors, fonts, navigation
- Its own member list: the people who have dashboard access to this site and their roles
- Its own audit trail: every action on this site, attributed to the member who took it
One SGEN account can hold multiple sites. From the admin's perspective, each site is a separate workspace — different content, different settings, different team. Moving between them does not mix anything; the isolation is enforced at every layer.
Account: Your Store├── Site 1: yoursite.com (12 members · 34 pages · 71 posts · 412 media)├── Site 2: wholesale.yoursite.com (3 members · 8 pages · 0 posts · 64 media)└── Site 3: staging.yoursite.com (2 members · 34 pages · 71 posts · 412 media)This is the structure that makes the site the right unit for isolation. An error on wholesale.yoursite.com — a deleted page, a misconfigured redirect, a bad media upload — does not touch yoursite.com. The two sites share an account; they do not share content, settings, or state.
The SG-Dashboard site switcher
The SG-Dashboard is the account-level home. It shows every site under your account in one list — site name, domain, member count, status, and when it was last active. From here you can:
- Switch into any site's admin by clicking the site name
- See the health and activity of every site at a glance
- Add a new site to the account
- Access account-level settings that apply across all sites
Switching sites does not require logging out. When you click a site name in the dashboard, the admin reloads in the context of that site. The top bar shows the current site name so you always know which site you are working in. If you manage several sites, the site name in the top bar is the fast confirmation that you are in the right place before making changes.
Per-site isolation: what stays separate
The following are fully per-site. A change to any of these on one site has no effect on any other site under the account.
| Area | What is per-site | Notes |
|---|---|---|
| Content | Pages, blog posts, custom objects, form records, events | No cross-site content sharing by default |
| Media | The media library | Each site has its own asset library |
| Settings | Site name, URL, timezone, SEO defaults, integrations | Including email service and analytics connections |
| Brand | Theme, colors, fonts, navigation, header/footer config | Each site has independent brand settings |
| Members | Who has access and at what role | A member of Site A is not automatically a member of Site B |
| Roles | The role each member holds | The same person can hold different roles on different sites |
| Audit trail | Every action on this site | Filterable per site |
| Custom objects | Object type definitions and records | Schema and data are per-site |
| Custom CSS / Custom Codes | CSS overrides and code snippets | Not shared across sites |
| Redirects | URL redirect rules | Per-site domain context |
| Forms | Form definitions and submission history | Submissions are per-site |
The principle: anything that would differ between a retail store's main site and their wholesale portal should be per-site. SGEN applies that principle to every layer.
Shared account-level elements
A smaller set of things lives at the account level and applies across all sites:
| Area | What is shared | Notes |
|---|---|---|
| Account credentials | Login email and password | One login covers all sites under the account |
| Billing | Plan, payment method, invoice history | Billing is account-level, not per-site |
| Account profile | Name, contact email, notification preferences | Account-level; not per-site |
| SG-Dashboard access | The ability to see the site list | All account members with dashboard access see the switcher |
Check with your SGEN contact: the exact scope of account-level settings — and whether your plan supports a specific number of sites — may vary by plan tier. If you are unsure, your account representative has the authoritative answer.
Examples
Example 1: Agency portfolio. An agency runs eight client sites from one SGEN account. Each client's editor only sees their own site. The agency account owner sees all eight in the SG-Dashboard and can switch into any one without logging out.
Account: Agency Account├── Site: ClientA.com → Agency admin (Owner) + ClientA editor (Editor)├── Site: ClientB.com → Agency admin (Owner) + ClientB editor (Editor)└── ... (6 more sites)ClientA editor logs in → sees only ClientA.com.Agency admin logs in → sees all 8 sites.Example 2: Brand portfolio. A main brand site and a regional site share the same account but have separate content, navigation, and SEO settings. The marketing team holds Editor access on both; the regional team holds Editor access on the regional site only. One click in the SG-Dashboard switches context — changes to the regional site's SEO defaults do not affect the main site.
Example 3: Staging alongside production. A staging site is a full, isolated SGEN site — its own media, members, and settings. Drafting and reviewing content there carries zero risk to the live site. Moving approved content to production is a deliberate manual action; nothing transfers automatically.
1. Switch into staging.yoursite.com via SG-Dashboard2. Draft and review3. Recreate approved content on yoursite.com (manual)4. Publish on productionRole behavior across multiple sites
Roles in SGEN are per-site. The same person can hold different roles on different sites, and those roles operate independently. A teammate who is Administrator on Site A and Editor on Site B has full settings access on Site A and content-only access on Site B.
| Scenario | What it means |
|---|---|
| Member of one site only | Can access and work in that site. Cannot see or access any other site under the account. |
| Member of multiple sites | Sees all their sites in the SG-Dashboard. Switches between them by clicking the site name. |
| Different roles across sites | Role capabilities are site-specific. Administrator on Site A ≠ Administrator on Site B. |
| Removed from one site | Access to that site is revoked. Access to other sites is unchanged. |
| Account owner | Can always see all sites in the SG-Dashboard. Account owner status does not automatically grant admin access inside a site. |
The two-layer permission gate — "is this person a member of this site?" then "does their role allow this action?" — applies independently for each site. A rejected action on Site A does not affect Site B. For the full permission model, see the Permissions and Roles Overview.
| Role on this site | Can switch to another site? | Can see another site's content? |
|---|---|---|
| Owner | Yes, if also a member of that site | Only the sites they are a member of |
| Administrator | Yes, if also a member of that site | Only the sites they are a member of |
| Editor | Yes, if also a member of that site | Only the sites they are a member of |
| Contributor / Viewer | Yes, if also a member of that site | Only the sites they are a member of |
| No membership | No | No — that site does not appear in their dashboard |
Per-site settings reference
The following settings are configured independently per site. Changing them on one site has no effect on any other site.
| Setting area | What it controls | Where it lives |
|---|---|---|
| General | Site name, primary URL, timezone, language | Settings > General |
| SEO defaults | Meta title pattern, meta description fallback, sitemap config | Settings > SEO |
| Email settings | From-name, from-address, SMTP configuration | Settings > Email |
| Brand / appearance | Theme, Globals (colors, fonts), header, footer, navigation | Appearance |
| Integrations | Analytics, email service provider, CRM, and other third-party connections | Settings > Integrations |
| Custom CSS | Site-scoped style overrides | Custom CSS |
| Custom Codes | Code snippets and script injections | Custom Codes |
| Redirects | URL redirect rules, relative to this site's domain | Redirects |
| Users / Members | Who has access and at what role | Users |
Where this lives
The multi-site surfaces in the admin are in two places:
The SG-Dashboard (account level). This is the site-switcher home. Navigate to the top-level dashboard URL for your account — the URL provided in your account confirmation email. From here you can see all sites, switch into any site, and access account-level settings. The site list shows site name, domain, member count, current status, and last activity.
The top bar (per-site admin). Once you are inside a specific site's admin, the top bar shows the current site name. An account menu in the top bar provides access to account-level settings and the site-switcher list without navigating away from the current site. Look for the site name or account avatar in the top right.
Users section (per-site). Within any site's admin, the Users section (visible to Owners and Administrators) shows who has access to this site, their role, and when they last logged in. Invitations, role changes, and removals happen here and affect only this site.
Invitations are site-specific. When you invite a member to Site A, they receive access to Site A only. They will not see Site B in their dashboard unless you invite them to Site B separately. This is deliberate — it keeps each site's access list clean and auditable.
Good use cases
Reach for multi-site when you have:
- Genuinely separate domains or brands that need different content, different settings, and different teams. A main brand site and a regional site. A product site and a wholesale portal.
- A staging environment you want to keep isolated from production. The staging site is a full SGEN site with its own content and settings; it does not bleed into the live site.
- An SGEN portfolio for an agency where each client is a separate site under the agency account. Client editors only see their own site; the agency admin sees all of them. This is the most common way to manage multiple sites SGEN operators run at scale.
- A second site you are building while the first one is live. Build, test, and iterate on the new site without touching the active one.
What NOT to use this for
Multi-site is not the right tool for:
- Sections of the same site. If the content is part of the same brand, the same navigation, and the same domain, it belongs inside one site — not as a separate site. Use pages, a blog category, or a custom object instead.
- A/B testing different versions of the same content. SGEN's multi-site is isolation for separate properties, not a split-testing environment. For A/B testing, use an integration or a separate testing tool.
- Solving a permissions problem within one site. If the issue is "I don't want this person to see the blog but I want them to edit pages," the answer is a custom role within the site, not a second site. See Permissions and Roles.
- Replacing staging with a second production site. Running the same site on two production domains is a content management and SEO problem, not a multi-site architecture. Use the proper staging environment pattern instead.
See also
This concept doc sits in the architecture cluster. The siblings cover the surrounding ground:
- Data Model Overview — what pages, posts, custom objects, and fields look like inside each site.
- Permissions and Roles Overview — the two-layer permission gate and how it applies per-site.
- Branding Governance Overview — how brand settings (colors, fonts, navigation) are managed per-site and what tools exist to keep brand consistent across a portfolio.
- Backup and Restore Overview — how backups work per-site, and how a restore affects only the site it targets.
- Extensibility Overview — custom objects, integrations, and automations, all of which are per-site.
- SGEN Glossary — definitions for
site,account,membership,role, and other terms used on this page.
Common questions
I invited a teammate to Site A. Why can they not see Site B?
Invitations in SGEN are site-specific. Your teammate has access to Site A because you invited them there. Site B is a separate site — they need a separate invitation to access it. This is intentional: it keeps each site's access list controlled and auditable.
I changed the SEO settings on the staging site. Did that affect the production site?
No. Settings are per-site. Changes to staging.yoursite.com's SEO settings have no effect on yoursite.com's SEO settings. The two sites are isolated.
My teammate can see Site A and Site B in their dashboard. How?
They were invited to both sites separately. Each site showed up in their SG-Dashboard when they accepted each invitation. The dashboard shows every site a user is a member of.
Can two sites share the same media library?
No. Each site has its own media library. An image uploaded to Site A is not available in Site B's media picker. If you need the same image on both sites, upload it to each site's media library. This is consistent with the broader isolation model — one site's media changes (deletions, edits) do not affect another site.
Check with your SGEN contact: if your use case requires sharing assets across multiple sites at scale — for a large brand portfolio, for example — ask your account representative whether there are options available on your plan tier.