How to Build First Site in SGEN

⏱ 60-second answer below · full page ≈ 10 min · skim the bold lead-ins to move faster.

The 60-second answer. Build in this order — (1) write your page list before opening the editor, (2) pick the 3-5 pages that carry the most weight (homepage, primary offers, contact) and finish those first, (3) write each page's above-the-fold section to answer four questions: what is this, who is it for, what should I do next, why should I trust you, (4) keep headings and CTAs consistent across every page, (5) review on desktop and mobile before publishing. Do not start designing until you know what each page is for. A focused operator with content ready can ship a clean first site in a single working day.

That's the gist — everything below is the same idea in depth.

On this page: Before you start · Steps — build the first version · Three failure modes to avoid · What success looks like · Common questions · Build sequence at a glance

Get the structure right first, then scale from a clean base

When you build your first site in SGEN, the work goes best as a sequence: structure first, weighted pages second, clear content third, simple visuals fourth, review fifth. Skipping ahead — designing pages before the site map exists, decorating before the offer is clear — creates cleanup work that rarely fits the time budget.

If you are starting from scratch — create your account and site

If you do not yet have an SGEN account:

Go to sgen.com and sign up with your email address. Verify the link in your inbox.
Pick a starting template or start blank. You can swap templates later — the choice here affects only the initial page layout.
Set your site name and subdomain. These become the default URL you work from until you point a custom domain.
The setup wizard walks you through timezone, maintenance mode, and basic brand defaults. Complete all steps before opening SG-Builder.

Once provisioned, set your brand kit before building pages:

Globals → Colors — set your primary, secondary, and accent colors. SG-Builder inherits these across every component.
Globals → Fonts — pick a heading and body typeface. Changing fonts after pages are built works, but setting them first means every page you build matches from the start.
Globals → Logo / Favicon — upload your logo and favicon at web resolution (WebP recommended). These appear on every page automatically once set.

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 — written before opening the editor.
A few representative pieces of content: existing copy, a hero image, the business contact details.

If any of those are missing, work on them outside SGEN first. The build goes faster when the editor is where you compose what you already know, not where you decide what to say.

Use this guide when: you are starting a new SGEN site and want to ship the first useful version without false starts. Not a fit for: multi-site portfolio architecture (see How SGEN Replaces Your Traditional WordPress Stack) or deep design-system work.

Orientation reads that pair with this guide:

Getting Started with SGEN — platform orientation.
Getting Started with the SGEN Admin — operator-surface tour.

Steps — build the first version

1. Define the core structure

Start with the minimum complete set of pages. For most small businesses: a homepage, two to four primary pages that explain the offer, an About page, and a Contact path.

Add location pages, blog posts, and support pages when they serve real workflows — not because every site seems to have them. Speculative pages create maintenance work without serving anyone.

A useful exercise: list every page, then mark each as "explains the offer," "supports search," "establishes trust," or "drives action." Pages that don't fit any of those aren't needed in the first version.

2. Prioritize the pages that carry weight

Not every page deserves the same effort. The homepage, primary offer pages, and contact path should land before anything else gets attention — these are the pages visitors use to make decisions.

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. The opposite — every page at the same middling quality — 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, it's doing less work than it could.

A practical pattern: write each page's first viewable section as a single declarative summary plus a single primary action. Everything below supports visitors who want depth; the skimmer gets what the page is for in the first three seconds.

4. Keep the first version clean

The first build needs to be coherent, navigable, and ready to scale — not elaborate.

Consistent headings — one heading style for primary, one for secondary, no per-page typographic experiments.
Direct CTAs — "Schedule a call" beats "Click here to learn more about scheduling a call."
Simple navigation — if the path from homepage to contact takes more than two clicks, the navigation is doing too much.

Clean reads as confident, and confidence converts.

5. Review before you expand

Before adding more pages or design treatment, check the foundation:

Page naming is consistent across navigation, URL, and page title.
Navigation reflects the actual site (every primary page reachable in one click).
The path to contact or conversion is obvious from the homepage and every primary offer page.
Content reads correctly across desktop, tablet, and mobile viewports.

When the foundation reads coherently, expansion is safe. If any check surfaces a problem, fix it before expanding — the cost of structural issues grows with every page added on top.

When to involve a designer

A first site does not require a designer. Platform-default templates produce a clean rendered site without design effort.

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 budget and time to iterate on visual treatment after the first build is functional.

For most situations: launch with platform defaults; observe what visitors do; involve a designer for version two if visual treatment is what's holding the site back.

Templates and the first site

The first site usually doesn't need custom templates. Platform-default Page and Post templates cover priority pages cleanly. Reach for custom templates only after platform defaults have rendered for real visits and the gap is observable. Default first; extend when the gap is real.

Site speed at first launch

Platform defaults are tuned for site speed. First-site load times depend mostly on:

Hero image weight — large unoptimized hero images dominate first-paint timing.
Font choices — system fonts load instantly; custom web fonts add a few hundred milliseconds.
Component density — simpler compositions render faster.

The Media Library handles image optimization automatically on upload, avoiding the most common image-weight issue without operator action.

Glossary for first site setup

Term	Meaning
Site structure	The page list and the navigation that ties pages together. Get this right early; revisit before every expansion.
Minimum complete version	The smallest set of pages that lets a visitor evaluate the business and take a next action. The launch target for a first build, not a long-term ceiling.
Launch readiness	Every priority page reads as intentional, navigation reflects the actual site, and the conversion path is obvious.
Priority pages	Pages a visitor uses to make a decision — homepage, primary offers, contact. Should be visibly stronger than secondary pages.
Secondary pages	Pages that round out the site without driving the primary decision — About, location, support, blog. Can be functional at lower polish.
Four-question test	Each page's first viewable section answers: what is this page about, who is it for, what to do next, why is the business credible.

A worked example — small consulting firm

To make the sequence concrete, here is what the build looks like for a small consulting firm opening their first site.

Day 1 morning — structure (Step 1). They write their page list before opening the editor: Home, Services, Industries, About, Case Studies, Contact. Six pages, minimum complete set. The list takes 20 minutes; the discussion that produces it takes longer than the typing.

Day 1 afternoon — weighted pages (Step 2). Home, Services, and Contact get full attention. Industries and Case Studies stay placeholder. About gets a working draft. This split gets the site useful by end of day rather than end of week.

Day 2 morning — content that works (Step 3). Each priority page gets its first viewable section reviewed against the four questions. Home explains what the firm does and who it serves in two sentences plus a primary CTA. Services lists three concrete service lines with one-paragraph descriptions.

Day 2 afternoon — clean first version (Step 4). One heading style across the site. One CTA pattern everywhere a primary action belongs. Navigation trimmed to the six pages plus a Contact item.

Day 3 morning — review (Step 5). Walk the site on desktop and mobile. Contact path is two clicks from anywhere. Mobile rendering is clean. Naming is consistent. Publish.

What was deferred: a blog, team profile pages, industry-specific landing variants, and the case-studies grid — each belongs in version two or later, not in the first publish. Treating launch as end of phase one (not end of the build) is what makes disciplined deferral possible.

Three failure modes to avoid

Failure mode 1: building everything at once. The team tries to launch twelve pages all at the same quality level. Result: every page is half-done. 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. Fix: write the page list first, decide what each page answers, then open the editor.

Failure mode 3: content as filler. Copy treats the words as something to fill space between visual elements. Result: pages where the visual reads finished but the words don't say much. Fix: write the answer to "what does this page need to communicate" before opening the editor.

Recovering after a failure: stop adding new pages or design treatment, return to Step 1, and rebuild the priority pages at full quality before doing anything else. Most pages can be rewritten in an hour or two when the structural decision is clear.

Build sequence at a glance

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, and 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 takes at most two clicks.
Every page in the navigation exists and renders correctly.
The pages that drive 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.

When all five hold, the first version is ready to publish.

What to do if it does not work

The site feels unfinished. Priority pages haven't been finished but secondary pages have. Pull effort back to the homepage, primary offers, and contact.

The navigation feels confusing. Too many pages too early. Cut pages that don't fit any of the four jobs (offer / search / trust / action).

The contact path is buried. 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. Rewrite the page's first viewable section to answer the four-question test in plain language.

Mobile rendering breaks. Switch SG-Builder preview to mobile, walk every page, look for overflowing text, hidden buttons, oversized hero images. Most fixes are at the component-trait level.

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.

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.

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.

How long should this take? A focused operator with content ready can ship a clean first version 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.