SGEN Naming Conventions
Terms in the SGEN platform follow consistent capitalization, slug, and formatting rules. Using the correct form — in documentation, in support tickets, in internal SOPs — keeps the platform vocabulary legible and searchable. This page is the lookup source for the correct form of every major term.
What is this for?
Naming conventions in SGEN define how product terms are spelled, capitalized, and formatted across three surfaces: the admin interface, the documentation, and the public-facing product pages. Consistency matters because SGEN replaces a fragmented stack where every plugin named the same concept differently. The conventions on this page are the single form the platform, the docs, and the team use.
Read this page when writing documentation, internal SOPs, support articles, or user-facing copy about SGEN. Read this page when the correct capitalization of a term is unclear. Read this page when creating URL slugs, route handles, or short identifiers for SGEN-related content.
Scope
This page covers:
- Product pillar names and the rules for using them.
- The admin interface label convention ("the admin" not "admin panel").
- Area and module naming conventions.
- Slug format rules (kebab-case, lowercase, no trailing hyphens).
- Feature-naming patterns used in release notes and documentation titles.
- Terms that must NOT appear in customer-facing text.
This page does not cover:
- API field naming — see the per-module Reference pages.
- URL routing inside SGEN — see the platform-engineering documentation.
- Brand voice rules beyond terminology — see the Brand Voice guide.
- Icon naming or asset naming — those follow separate conventions documented inside SG-Builder.
Vocabulary
| Term | Correct form | Wrong forms | Notes |
|---|---|---|---|
| The platform | SGEN | Sgen, sgen, S-gen | All caps, no hyphen |
| First pillar | SG-Core | sg-core, SGCore, SG Core | Hyphen, no space, caps on S and C |
| Second pillar | SG-Modules | sg-modules, SGModules | Hyphen, no space, caps on S and M |
| Third pillar | SG-Dashboard | sg-dashboard, SGDashboard | Hyphen, caps on S and D |
| Fourth pillar | SG-Builder | sg-builder, SGBuilder | Hyphen, caps on S and B |
| The admin interface | the admin | admin panel, backend, dashboard, the backend | Lowercase "the admin" — never "admin panel" |
| Site administration | site admin | site-admin, SiteAdmin | Two words, lowercase |
| A site-level URL pattern | {site-domain}.com/sg-admin/ | /wp-admin/, /backend/ | The route prefix for every site's admin |
| An account-level URL | dashboard.sgen.com | admin.sgen.com, account.sgen.com | The account-tier surface URL |
| A URL path segment | kebab-case | camelCase, snake_case, Title-Case | Lowercase, hyphens, no underscores |
| A feature's documentation title | Title Case noun phrase | all lowercase, ALL CAPS | e.g. "Custom Codes", "Blog", "Site Manager" |
Pillar Names
SGEN has four pillars. Each pillar name has a fixed form. The form does not change based on context — it is always spelled the same way in documentation, in the admin interface, and in marketing copy.
SG-Admin is not a pillar. SG-Admin is an internal shorthand for the /sg-admin/ route prefix. It does not appear in customer-facing documentation, support articles, or marketing copy. When customer text refers to the admin interface, use "the admin". When customer text refers to the URL pattern, use {site-domain}.com/sg-admin/.
The Admin Interface
The admin interface is the site-tier management surface inside SGEN. Its canonical label in customer text is "the admin" — two words, lowercase, with the definite article.
| Context | Correct | Wrong |
|---|---|---|
| Directing a user to the admin | "Open the admin." | "Open the admin panel." / "Log in to the backend." |
| Referring to admin navigation | "The admin's left sidebar" | "The admin panel's left menu" / "The back-end sidebar" |
| Referring to the URL | "{site-domain}.com/sg-admin/" | "/wp-admin/" / "the admin URL" without the route |
"Dashboard" in customer text always means SG-Dashboard — the account-tier surface at dashboard.sgen.com. It never means the admin's overview screen. If prose needs to refer to the admin's overview screen, call it "the admin home screen".
Slug Format Rules
URL slugs in SGEN follow three rules without exception.
Rule 1 — Lowercase only. No uppercase letters anywhere in a slug. blog-post-title not Blog-Post-Title.
Rule 2 — Hyphens as separators, no underscores. Word boundaries use -. Underscores do not appear in slugs. custom-codes not custom_codes.
Rule 3 — No leading or trailing hyphens. Slugs start and end with an alphanumeric character. site-manager not -site-manager and not site-manager-.
These rules apply to:
- Page slugs set in the admin.
- Documentation URL slugs.
- Custom route handles.
- Any URL path segment the operator controls.
The admin enforces rule 1 and rule 2 automatically. Rule 3 is advisory — the admin accepts leading/trailing hyphens but the platform's canonical slug behavior trims them.
Area and Module Names
Areas are groupings of related modules inside a pillar. Each area name uses Title Case. Each module name uses Title Case.
| Level | Example | Format |
|---|---|---|
| Pillar | SG-Core | SG- prefix + Title Case word |
| Area | Site Manager | Title Case, two or more words |
| Module | Custom Codes | Title Case, two or more words |
| Module (single word) | Blog | Title Case, single capitalized word |
| Sub-section | Header settings | Sentence case when used inside prose |
Area names do not use the SG- prefix. SG-Blog is wrong. Blog is correct. The SG- prefix belongs only to the four pillar names.
Feature-Naming Patterns
Features named in release notes, What's New entries, and Reference page titles follow a noun-phrase pattern.
| Pattern | Example | Notes |
|---|---|---|
| Noun phrase (single feature) | Custom Codes | Title Case, no verb |
| Noun phrase (module section) | Blog — Scheduled Publishing | Module + em dash + feature area |
| Action capability | Bulk Export | Verb + noun, Title Case, for action-oriented features |
| Setting or option | Auto-redirect on slug change | Sentence case when inside a settings list |
Do not prefix feature names with the pillar name in customer text. "Blog" not "SG-Core Blog". "Custom Codes" not "SG-Core Custom Codes". The pillar prefix only appears in architecture documentation that needs to distinguish the same feature name across pillars — that situation is rare.
Examples
Example 1 — Writing a support article
A support author writes a help article about adding tracking scripts. The correct form: "Open the admin, navigate to Custom Codes, and click Add Code." Not: "Log in to the admin panel, go to SG-Admin → Custom Codes, and click Add Code." The wrong form uses "admin panel" (deprecated) and routes the reader through SG-Admin (internal-only prefix that should not appear in customer text).
Example 2 — Naming a URL slug
An operator creates a landing page and types a custom slug. They want the slug to match the page title "About Our Services". The correct form: about-our-services. Not: About-Our-Services (uppercase), about_our_services (underscores), or about-our-services- (trailing hyphen).
Example 3 — Referring to the four pillars in marketing copy
A marketing author writes a feature overview. "SGEN is organized across four pillars: SG-Core, SG-Modules, SG-Dashboard, and SG-Builder." Not: "SGEN has four components: SGCore, Modules, Dashboard, and the Builder." The wrong form drops the hyphen, drops the SG- prefix on some pillars, and uses the wrong capitalization on others.
Edge cases
"Dashboard" as a common noun. Outside of the pillar name SG-Dashboard, "dashboard" in lowercase may appear in prose to mean a summary screen. "The admin's analytics dashboard" is acceptable when referring to a specific screen inside the admin. When referring to the account-tier pillar, always use "SG-Dashboard" capitalized.
Abbreviating pillar names. In internal documentation or where the full pillar name would be repetitive, abbreviations are acceptable: "Core", "Modules", "Dashboard", "Builder". Abbreviations never appear in customer-facing documentation — always use the full SG-Prefix form.
Multi-word module names in slugs. When a module name becomes a slug, apply the slug rules: lowercase, hyphens. "Custom Codes" becomes custom-codes. "Site Manager" becomes site-manager. "What's New" becomes whats-new (apostrophe removed, no consecutive hyphens).
Referencing historical WordPress terms. Some operators migrating from WordPress will use "posts", "categories", "tags" in their own language. SGEN documentation uses SGEN terminology. When a doc needs to map old terms to new ones, provide the mapping explicitly: "What WordPress calls a 'category', SGEN calls a 'tag group'." Do not adopt WordPress terminology as if it were SGEN terminology.
Where to find it
This page is part of the Shared Concepts Reference section at docs.sgen.com. Navigate to Reference → Shared Concepts → SGEN Naming Conventions.
The admin interface enforces slug rules at field level — the slug input fields in Pages, Blog, and Products display a validation hint if the entered value violates the format.
Related features
- Shared Concepts Overview — the cross-platform vocabulary this naming guide extends.
- How to Read Reference Docs — the naming conventions on this page apply to every Reference page title and cross-reference link.
- 4-Pillar Diagram — the four pillar names in structural context.
- Platform Values — the design decisions behind the naming choices, including why the
SG-prefix exists and why "admin panel" was retired.