How to Build First Site in SGEN
Get the structure right first, then scale from a clean base.
When you build first site in SGEN, the work goes best as a sequence: structure first, weighted pages second, clear content third, simple visuals fourth, review fifth. Each step builds on the one before it. Skipping ahead — designing pages before the site map exists, decorating before the offer is clear — creates cleanup work that rarely fits the time budget operators have.
What is this for?
Read this guide when you are starting a new SGEN site and want to ship the first useful version without false starts. The shape of the guide is sequential — each step has prerequisites in the step before it, and the order matters more than any single step.
Good use cases
- You signed up for SGEN and want to know where to start.
- You are migrating a small business site from another platform and need a build sequence that won't sprawl.
- You are scoping a new site for a client and want to align on what the first version covers.
- You hit a question like "Should I work on the homepage first or the contact form?"
What NOT to use this for
- Multi-site portfolio architecture — that conversation belongs in How SGEN Replaces Your Traditional WordPress Stack.
- Deep design-system work — start here for shape, then iterate on visual treatment after the structure holds.
- Per-feature reference — open the relevant module reference (Pages, Forms, Templates, etc.) for surface-level details.
Before you start
You should have:
- An SGEN account with a site provisioned.
- A short written description of what the business does and who it serves. One paragraph is plenty.
- A list of the pages a visitor would expect to find on the site — written before opening the editor.
- A few representative pieces of content (existing copy, a hero image, the business contact details).
How this connects to other features
- Getting Started with SGEN — the platform-orientation read that pairs with this build sequence.
- Getting Started with the SGEN Admin — the operator-surface tour for the admin module set.
- Pages — the engine surface the build produces records on.
- Templates — the layout layer that governs how built pages render.
Where to go
Open the admin Pages module to start adding pages. Open SG-Builder when ready to compose layouts. Open Site Settings when ready to configure header, footer, and global styles.
How to build your first site
Steps — Build the first version
1. Define the core structure
Start with the minimum complete set of pages a visitor needs to evaluate the business and take a next action. For most small businesses that means: a homepage, two to four primary pages that explain the offer, an About page that explains who is behind the business, and a Contact path the visitor can reach without searching.
Add location pages, support pages, blog posts, and any other content the business needs to serve real workflows — not pages that "feel like every site has them." Speculative pages create maintenance work without serving anyone; the audit happens later, the cleanup happens at twice the cost of having gotten it right the first time.
A useful exercise: list every page on the site, then mark each as "explains the offer," "supports search," "establishes trust," or "drives action." Pages that don't fit any of those are usually pages that don't need to exist yet.2. Prioritize the pages that carry weight
Not every page deserves the same effort. The pages that explain the offer, support search visibility, establish credibility, and drive conversion deserve material work. Secondary pages can be functional and brief.
Specifically: the homepage, the primary offer pages (services, products, or whatever the business sells), and the contact path should land before anything else gets attention. These are the pages visitors use to make decisions; finishing them first means the site is useful to visitors as soon as it goes live, even if other pages are still placeholder-quality.
When the weighted pages are materially stronger than the secondary pages, the site reads as intentional even if the long tail isn't fully built out. The opposite — every page at the same middling quality level — reads as unfinished everywhere.3. Build content that does a job
Each page should answer four questions quickly: what is this page about, who is it for, what should the visitor do next, and why is the business credible. If a page doesn't answer all four within the first viewable section, the page is doing less work than it could.
More text is not the same as better content. A short page that answers the four questions clearly outperforms a long page that buries the answers under context. The economics of attention are not sympathetic; visitors are not reading carefully, and copy that respects that fact converts better than copy that doesn't.
A practical pattern: write each page's first viewable section as a single declarative summary plus a single primary action. Everything below that is supporting detail for visitors who want it, but the visitor who skims gets what the page is for in the first three seconds.
4. Keep the first version clean
The first build does not need to be elaborate. It needs to be coherent, navigable, and ready to scale.
Use consistent headings (one heading style for primary headings, one for secondary, no per-page typographic experiments). Direct calls to action ("Schedule a call" beats "Click here to learn more about scheduling a call." every time). Simple navigation that doesn't force visitors to wander — if the path from homepage to contact takes more than two clicks, the navigation is doing too much work.
Operators often resist "keep it clean" because clean feels under-designed. The truth is the opposite: clean reads as confident, and confidence converts. Sites that visibly try too hard signal effort over substance.
5. Review before you expand
Before adding more pages or more design treatment, check the foundation:
- Page naming is consistent across the navigation, the URL, and the page title.
- Navigation reflects the actual site (every primary page is reachable in one click).
- The path to contact or conversion is obvious from the homepage and from any primary offer page.
- Content reads correctly across desktop, tablet, and mobile viewports.
If any of the checks surface problems — inconsistent naming, missing nav entries, awkward conversion paths — fix them before expanding. The cost of fixing structural issues grows with every page added on top of them.
When to involve a designer
A first site does not require a designer. The platform-default templates and components produce a clean rendered site without design effort. Operators who can write clear copy and pick reasonable colors can build a presentable first version on their own.
A designer's input becomes valuable when:
- The brand identity is already established, and the site needs to honor specific colors, fonts, and patterns.
- The site competes in a category where visual quality is part of the offer (luxury goods, design services, premium consumer brands).
- The team has the budget and time to iterate on visual treatment after the first build is functional.
Templates and the first site
The first site doesn't usually need custom templates. The platform-default Page and Post templates cover the priority pages cleanly; secondary pages can use the same defaults. Operators who reach for custom templates in the first version often spend time on layout work that produces less visitor benefit than spending the same time on content quality.
When a site genuinely needs a custom template — a distinct hero treatment for landing pages, a per-product layout for ecommerce — the right time to add it is after the platform defaults have rendered for a few real visits and the gap is observable. Building a custom template against an imagined need usually produces a template that gets retired before it earns its keep.
The exception is sites that arrive with a pre-existing design system. Operators who already have a set of layout patterns and components from a prior site can carry those into the first SGEN build.
The build sequence above still applies; the templates are the layer the priority pages render through.
When pre-existing design systems are carried in, operators usually save time during the build but pay it back later if the design system was tied to a different platform's render shape. The carry-over works best when the design system is documented as patterns rather than as platform-specific implementations.
For first builds without an existing design system, the platform defaults are the right starting place.
Custom templates are easier to add to a working site than to subtract from a broken one.
The same applies to custom CSS, custom code blocks, and any other non-default extension. Default first; extend when the gap is real.
A first launch built entirely on platform defaults is not a compromise — it is the fastest path to a site that works.
The polish comes from honest content, consistent navigation, and clear conversion paths. Visitors do not notice when a site uses platform defaults; they notice when a site is hard to use.
Site speed at first launch
The platform's defaults are tuned for site speed. The first site's load times depend mostly on:
- The hero image weight on the homepage. Large unoptimized hero images dominate first-paint timing.
- The font choices in site settings. System fonts load instantly; custom web fonts add a few hundred milliseconds.
- The component density of the priority pages. Simpler compositions render faster.
The Media Library handles image optimization automatically when images are uploaded through it; sites that use Media Library uploads avoid the most common image-weight issue without operator action.
Glossary for first site setup
A handful of terms recur through the build sequence and across SGEN documentation. Knowing what each means makes the rest of the workflow clearer.
Site structure — the page list and the navigation that ties the pages together. Site structure decisions matter more than any other build decision because they shape every later choice. Get site structure right early; revisit it before every expansion.
Minimum complete version — the smallest set of pages that lets a visitor evaluate the business and take a next action. The minimum complete version is the launch target for a first build, not a long-term ceiling. Every site grows past the minimum complete version; the question is whether that growth happens after the minimum complete version is solid or before.
Launch readiness — the state where every priority page reads as intentional, navigation reflects the actual site, and the conversion path is obvious. Launch readiness is checked before publishing; if any of the three signs are weak, the site needs more work, not more pages.
Priority pages — the pages a visitor uses to make a decision. For a small business: homepage, primary offers, contact. The priority pages should be visibly stronger than secondary pages.
Secondary pages — the pages that round out the site without driving the primary decision. About, location, support, blog. Secondary pages can be functional at lower polish without hurting the launch.
Four-question test — the test each page passes if its first viewable section answers what the page is about, who it is for, what to do next, and why the business is credible. The four-question test is the practical bar for "did this page do its job?"
Why this glossary matters
Operators come to SGEN from different platforms and team backgrounds. A few teams call the priority-pages step something else; a few call the four-question test by another name. The terms above are the terms used across SGEN documentation, so anchoring them here prevents confusion later.
The glossary stays compact deliberately. Adding more terms tends to introduce vocabulary that only some teams use; the few terms above are the ones every team needs.
A worked example — small consulting firm
To make the sequence concrete, here is what the build looks like for a hypothetical small consulting firm — your business Strategy — opening their first site.
Day 1 morning, structure (Step 1). your business writes their page list before opening the editor: Home, Services, Industries, About, Case Studies, Contact. Six pages — the minimum complete set for a consulting offer. The list takes 20 minutes; the discussion that produces it takes longer than the typing.
Day 1 afternoon, weighted pages (Step 2). your business spends the afternoon on Home, Services, and Contact. Industries and Case Studies stay placeholder. About gets a working draft. The split-the-priority decision is the one that gets the site useful by end of day rather than at end of week.
Day 2 morning, content that works (Step 3). Each priority page gets its first viewable section reviewed against the four questions. The Home page hero explains what your business does and who it serves in two sentences plus a primary CTA ("Schedule a discovery call"). The Services page lists three concrete service lines with one-paragraph descriptions, not five service lines with marketing language.
Day 2 afternoon, clean first version (Step 4). your business picks one heading style across the site, sets one CTA pattern ("Schedule a discovery call" everywhere a primary action belongs), and trims the navigation to the six pages plus a Contact item.
Day 3 morning, review (Step 5). your business walks the site on desktop and mobile. The contact path is two clicks from anywhere. Mobile rendering is clean. Page naming is consistent across navigation, URL, and page title. They publish.
The example shows a three-day cadence. Sites with more pages take longer; sites with less content can finish faster. The shape of the work is consistent.What your business deferred
The launch version doesn't include: a blog (waiting on the editorial cadence decision), team-member profile pages (the About page covers it), industry-specific landing variants (waiting until traffic shows which industries visit), the case-studies grid (placeholder until two real case studies are written). Each of these belongs in version two or later, not in the first publish.
The discipline that lets your business defer is treating the launch as the end of phase one rather than the end of the build. Visitors arriving at the launch site get a useful experience; the team gets feedback that informs phase two; nothing was launched at half-quality to fill space.
Three failure modes to avoid
Most failed first-site builds fall into one of three patterns. Knowing the pattern in advance makes them easier to avoid.
Failure mode 1: building everything at once. The team tries to launch with twelve pages all at the same quality level. Result: every page is half-done. Visitors read the half-done state as effort over substance. The fix: pick the priority pages, finish them, let secondary pages be visibly secondary.
Failure mode 2: design before structure. The team opens SG-Builder and starts composing layouts before deciding what each page is for. Result: visually polished pages with unclear purpose, and the structural problems become visible only after design effort is sunk. The fix: write the page list first, decide what each page answers, then open the editor.
Failure mode 3: content as filler. The team treats copy as something to fill the space between visual elements. Result: pages where the visual reads finished but the words don't say much. The fix: write the answer to "what does this page need to communicate" before opening the editor; treat the editor as the place to lay out what is already known.
Recovering after a failure
When a first-site build has hit one of these failure modes, the recovery is the same in every case: stop adding new pages or new design treatment, return to the structure step (Step 1), and rebuild the priority pages (Step 2) at full quality before doing anything else.
The rebuild costs less than it sounds. Most pages can be rewritten in an hour or two when the structural decision is clear. The pages that can't are usually the pages that don't belong on the first version anyway.
Build sequence at a glance
For operators who want the entire sequence on one screen:
- Write the page list before opening the editor.
- Pick the priority pages (homepage, primary offers, contact).
- Write each priority page's first viewable section against the four-question test.
- Build the priority pages in SG-Builder using consistent heading and CTA patterns.
- Build the secondary pages at functional quality, lower polish than priority pages.
- Walk the site on desktop and mobile, fix anything that doesn't read clean.
- Verify naming consistency across navigation, URL, page title.
- Verify the contact path is two clicks from anywhere.
- Publish.
- Treat the launch as phase one; phase two is iteration on real visitor signal.
What success looks like
A first version that succeeds carries these signs:
- A visitor reaching the homepage understands within seconds what the business does and who it serves.
- The path from any page to the conversion action (contact, booking, purchase, signup) takes at most two clicks.
- Every page in the navigation exists and renders correctly.
- The pages that drive the business outcomes are visibly more polished than the pages that don't.
- Mobile rendering is clean — no overflowing text, no hidden actions, no wide images forcing horizontal scroll.
What to do if it does not work
The site feels unfinished. Usually a sign that the priority pages haven't been finished but secondary pages have. Pull effort back to the homepage, primary offers, and contact; let secondary pages stay placeholder until the priority ones are strong.
The navigation feels confusing. Often a sign of too many pages too early. Cut pages that don't fit any of the four jobs (offer / search / trust / action); the remaining navigation becomes obvious.
The contact path is buried. If a visitor has to search for how to contact the business, the conversion rate suffers visibly. Add a primary contact action to the header or above-the-fold homepage; verify it is reachable from every offer page.
Content reads as filler. Usually means the page is answering questions visitors don't have rather than questions they do. Rewrite the page's first viewable section to answer "what is this page about, who is it for, what should I do next, why are you credible" in plain language.
Mobile rendering breaks. Switch the SG-Builder preview to mobile, walk through every page, look for overflowing text, hidden buttons, oversized hero images. Most fixes are at the component-trait level — adjusting padding, switching to a mobile-first column setup, or compressing a hero image.
Best practices
A few lines of guidance distilled from teams that have built first sites well.
- Launch the smallest complete version, not the largest half-finished version.
- Keep one standard for headings, naming, and call-to-action language across the whole site.
- Build the homepage, offer pages, and contact path to a higher quality bar than secondary pages.
- Run a structural review before adding new pages, every time the page count grows.
- Use Getting Started with SGEN and Getting Started with the SGEN Admin as orientation reads alongside this build guide.
- Treat publishing the first version as the end of phase one, not the end of the build. Phase two is iteration based on what visitors do.
Common questions
How small is "smallest complete version"? For most small businesses, six to ten pages: homepage, two to four offer pages, About, Contact, and one or two location or support pages. Sites that need fewer (a one-page brochure) are fine; sites that need more (multi-location, multi-service) follow the same pattern at larger scale.
Should I write all the content first or build the pages first? Write enough content to know what each page is for. Build the page once you know what it has to say. Filling pages with placeholder text and then rewriting under design pressure usually ends up worse than writing the answer to "what does this page need to say" before opening the page in SG-Builder.
When should I add a blog? Once the priority pages are in good shape and you know what subjects regular visitors want to read about. Adding a blog before either of those usually produces posts no one reads.
How long should this take? A focused operator with content ready can ship a clean first version of a small business site in a single working day. Sites that take longer usually have unresolved decisions about what the site is for; resolve those before reopening the editor.
Reading order
Read this guide in sequence — each step assumes the prior step landed. If you have already done some of the structure work, skim the early steps and start where the work is.
Pair with Getting Started with SGEN for platform orientation and Getting Started with the SGEN Admin for the operator-surface tour. Both can be read before this guide or alongside it.