Set up a custom domain for your site

How to add a domain, verify DNS, provision SSL, redirect from the default subdomain, and confirm the site is healthy on the new name.

A custom domain is the public name of your site.
Setting one up replaces the default subdomain — your-site.sgen.app or similar — with a name the audience knows you by.
This page walks the full custom-domain workflow for a single SGEN site — adding the domain in the admin, verifying the DNS records, letting SSL provision automatically, switching the primary name, redirecting the old default to the new domain, and confirming the site serves cleanly on both surfaces.

The page is written for two operating modes.
The first is a fresh launch — the site is being built for the first time and the custom domain is part of the go-live plan.
The second is a rename — the site has been live on a default subdomain or on a previous custom domain and the team is migrating to a new name.
Both modes share the same surface; the rename path adds a redirect step from the old name to the new.

What is this for?

Use this page when you want your SGEN site to serve on a name you control — your own domain or subdomain.
The Domains module covers adding the name, walking through DNS verification, automatic SSL provisioning, picking the primary name, and adding a redirect from the default subdomain.

The page is a how-to.
It does not cover registering a domain with a domain registrar; that work happens outside SGEN.
It does not cover advanced DNS topics like wildcard routing, multi-region anycast, or DNSSEC; those topics live in the Domain Reference for power users.
The page focuses on the everyday workflow that every site goes through once.

Good use cases

• A new site launching for the first time and needing a domain like www.example.com instead of the default SGEN subdomain.
• A site rebranding from one domain to another — the old name still resolves while the new name becomes the public face.
• An additional language or regional version of a site that needs its own domain — example.de next to example.com.
• A campaign microsite that needs a short, memorable name for the run of the campaign.
• A migration in from another platform where the existing domain must point at the new SGEN site without a visible URL change for the audience.

What NOT to use this for

• Email hosting. SGEN does not host email. Adding a custom domain does not set up email; that work runs at the email provider with separate DNS records.
• Domain registration. Use a registrar to buy and renew a domain name. SGEN reads the DNS records you set at the registrar; it does not own the name.
• Path-based routing across multiple back-ends. The Domains module routes a whole domain at one SGEN site. For path-based splits across services, use the routing layer at the edge instead.
• Hiding the domain. A custom domain is the public name; the site is reachable from anyone who knows the name. For private staging, use the staging URL surface and lock it with the staging access control.

How this connects to other features

• Manage redirects — once the new domain is live, redirects from the old default subdomain to the new name use the standard redirect surface.
• Optimize for SEO — a domain change usually carries SEO weight; the SEO health report tracks canonical URLs across both names while search results catch up.
• Security — the SSL certificate provisioned for the custom domain is part of the site's security posture; the security panel surfaces the certificate's status and renewal cadence.
• Audit Log — every domain add, verification, primary-switch, and removal is recorded; use the log to confirm who changed what.

Before you start

• You own the domain at a registrar — you can sign in and edit DNS records for the domain.
• You are signed in as a user with site-admin permission for the SGEN site you are adding the domain to. Editors cannot add or change domains.
• The destination name is decided — whether the site will use example.com, www.example.com, or both.
• You have access to the team channel where the DNS-pointing window will be coordinated. Pointing DNS at SGEN takes a few minutes to a few hours to propagate; coordinate the window so visitors are not surprised by a flip.
• For a rename, you have a redirect plan from the old domain to the new. The redirect plan is built once the new domain is live and verified.

Where to find it

The per-site surface is the admin → Settings → Domains inside the site you are setting up.
This surface lists every domain attached to the site, the primary name, and the status of each domain — verifying, verified, SSL pending, or live.

The portfolio surface is SG-Dashboard → Site Manager → Domains at the account level.
This surface lists every domain across every site in the account, the primary name per site, and the certificate renewal calendar.
Use it to scan many sites at once and to confirm no site is sitting on a stale or pending domain.

Steps

The workflow has six parts — add the domain, set DNS records, verify the domain, let SSL provision, set the primary name, and redirect from the default subdomain.
The steps below cover the per-site surface.

1. Add the domain to the site

Open the site in the admin.
Click Settings in the left navigation.
Click Domains in the settings panel.

The page opens to the domain list.
The default subdomain — the auto-assigned *.sgen.app name — is in the list and marked as the primary name.

Click Add Domain in the top right.
The new-domain panel opens with one field.

Enter the domain name — example.com for the root domain, www.example.com for the www subdomain, or any other subdomain you want to attach to the site.

Click Save Domain.
The domain appears in the list with status Pending Verification.
The panel shows the DNS records the domain needs in order to verify.

For most setups two records matter — a record at the apex of the domain and a record at the www subdomain.
The exact record values appear in the verification panel and are unique to the site; copy them rather than typing them by hand.

2. Set the DNS records at your registrar

Open the DNS management surface at your registrar.
Find the zone editor for the domain you are adding.

The verification panel in SGEN names two records.
The first is for the apex — usually an A record or an ALIAS / ANAME record pointing at the SGEN edge address.
Apex CNAME records are not supported at most registrars; SGEN provides an apex-friendly record value the registrar accepts.
The second is for the www subdomain — usually a CNAME pointing at the SGEN target hostname.

Copy each value from the SGEN verification panel and paste into the corresponding field at the registrar.
Save the zone changes.

DNS propagation begins immediately at the registrar's nameservers and reaches the global resolver network over minutes to hours.
Typical propagation completes within fifteen minutes on a modern registrar; slower registrars take longer.

Do not delete the existing records yet if the domain is currently serving content somewhere else.
For a rename, the old setup keeps serving until the new records propagate; only after the new domain verifies and SSL provisions should the old records be retired.

For a domain that has never served any site before, the new records are the only records; there is nothing to retire.

3. Verify the domain in SGEN

Return to the admin → Settings → Domains.
The new domain row shows status Pending Verification with a small Check Now button next to it.

Click Check Now.
SGEN queries DNS for the records named in the verification panel.
A match returns the row to status Verified — SSL Pending.
A miss keeps the row in Pending Verification and surfaces the actual records seen at DNS, which helps spot a typo or a missing record at the registrar.

If the records look right but the verification still misses, give propagation a few more minutes and click Check Now again.
The platform also runs a passive verification check every fifteen minutes; the row flips automatically once propagation completes.

Once the row reaches Verified — SSL Pending, the verification step is done.
SSL provisioning starts automatically — no operator action is needed for the certificate itself.

4. Wait for automatic SSL provisioning

SGEN provisions a trusted SSL certificate for every verified domain at no extra cost.
The provisioning runs in the background after verification completes.

Typical provisioning completes within five to fifteen minutes for a standard apex + www pair.
The row shows status SSL Pending during provisioning and flips to Live once the certificate is in place.

Once the row is Live, the domain serves HTTPS traffic with a trusted certificate.
The certificate auto-renews well in advance of expiry; the operator does not need to touch the renewal cycle for typical domains.

For a domain that includes additional subdomains — blog.example.com, shop.example.com, and so on — repeat the Add Domain step for each.
Each subdomain gets its own row, its own verification check, and its own certificate.

If SSL provisioning takes longer than thirty minutes, open the row to see the certificate status detail.
The detail panel names any blocker — a CAA record on the domain that excludes the SSL provider, an HSTS preload mismatch on a related domain, or a temporary upstream issue at the certificate authority.
Most blockers resolve in minutes; persistent blockers warrant a support ticket.

5. Set the new domain as the primary name

The Domains list carries a primary marker on one row at a time.
The primary name is the canonical name for the site — the name that appears in canonical URLs, share previews, and search results.

On the new domain's row, click the action menu and pick Set as primary.
The primary marker moves to the new domain.
The previous primary name — usually the default *.sgen.app subdomain — remains attached to the site and continues serving but is no longer the canonical name.

Setting a new primary name causes a wave of canonical-URL updates across the site.
Internal links continue to work; the platform rewrites canonical tags on every public page to use the new name.
Search engines pick up the new canonical over the next several days as they recrawl the site.

For a rename from one custom domain to another, the same step applies — the new name becomes primary, the old name continues serving until the rename plan retires it.

The Audit Log records the primary-switch action with the actor, the previous name, and the new name.

6. Redirect the old default subdomain to the new domain

The default *.sgen.app subdomain stays attached to the site by default.
For a clean public face, redirect every request on the default to the new custom domain.
Open the admin → Redirects and add a wildcard redirect rule that captures every URL on the default subdomain and points at the equivalent URL on the new domain.

A typical rule shape — source https://your-site.sgen.app/* with destination https://www.example.com/$1 using a 301 type.
The 301 type is the right pick because the move is permanent.

Use the redirect simulator to confirm a sample URL on the default subdomain lands on the new domain at the matching path.
The simulator step is covered in detail on the Manage Redirects page.

For a rename from one custom domain to another, build the redirect rule on the old custom domain pointing at the new one.
The old custom domain stays attached as a non-primary name with the redirect rule serving every request through to the new primary.

Set a calendar reminder for ninety days.
After ninety days, audit the inbound link sources to see how many still point at the old domain.
The redirect rule keeps the audience landing in the right place; ninety days is usually long enough for search results to update and for partner-side links to refresh.

7. Confirm the site is healthy on the new domain

Run a small post-launch check.

Open the public site on the new domain in an incognito browser window.
Confirm the page loads, the certificate is trusted, and a few internal links resolve cleanly.

Run a public-side broken-link scan if your team has one in place.
The most common post-rename surprise is an internal link that still points at a hard-coded old domain; the scan catches these.

Open the admin → SEO and run the SEO health report against the new name.
The report flags canonical mismatches, broken images, and missing meta information; clear any flags before the launch window closes.

For a rename, run the SEO health report against the old name as well.
The old name should now serve a clean redirect chain — every URL on the old name lands on the matching URL on the new name with a 301 status.

The Audit Log carries every step of the domain setup.
For a launch report to stakeholders, the log entries make a clean evidence trail.

What success looks like

A new domain is set up correctly when the domain row shows status Live in the admin → Settings → Domains, the primary marker sits on the new domain, the public site serves on the new name with a trusted certificate, and the default subdomain redirects cleanly to the new name.

A rename is successful when both domains continue to resolve, the new domain serves the canonical content, the old domain serves a redirect to the new one with a 301 status, the SEO health report shows zero canonical mismatches, and the Audit Log carries the full setup story.

A portfolio of custom domains is in good shape when every site in SG-Dashboard → Site Manager → Domains shows Live status, every certificate renewal is on schedule, and no site is sitting on a long-pending verification or SSL stall.

What to do if it does not work

Examples

Example A — fresh launch with apex and www.
A new business is launching for the first time on example.com.
Operator adds both example.com and www.example.com in the admin → Settings → Domains.
The verification panel surfaces two records — an apex-friendly ALIAS for the root and a CNAME for www.
Operator pastes both into the registrar's zone editor.
Within ten minutes both rows reach Verified; within another five minutes both reach Live.
Operator sets www.example.com as primary and adds a redirect from the apex to the www subdomain for canonical clarity.

Example B — rebrand from one custom domain to another.
A business is rebranding from oldname.com to newname.com.
Operator adds newname.com and www.newname.com to the admin, waits for verification and SSL, sets www.newname.com as primary.
Opens the admin → Redirects and adds two rules — one from oldname.com/ to https://www.newname.com/$1 and one from www.oldname.com/ to https://www.newname.com/$1, both 301.
Confirms the rules fire in the simulator.
Sets a six-month reminder to audit inbound link sources before retiring the old domain.

Example C — additional regional domain.
A site that runs on example.com is launching a German-language version on example.de.
Operator adds example.de and www.example.de to the admin, completes verification and SSL.
Leaves www.example.com as the primary name for the English site and configures the German-language variant in the language settings.
Both names serve as canonical for their respective languages; the language settings route between them.

Example D — campaign microsite.
A marketing team is running a six-week campaign on a memorable short domain springsale.example.
Operator adds the campaign domain to the SGEN site that holds the campaign landing page.
Verification and SSL complete within twenty minutes.
Sets the campaign domain as primary for the campaign site.
After the campaign closes, switches primary back to the main domain and adds a 301 redirect from the campaign domain to the main domain's seasonal collection page.

Example E — migration in from another platform.
A site is migrating in from a previous platform on example.com.
The operator builds the new site on the SGEN default subdomain, runs a content review, and prepares the launch.
On launch day, the operator changes the DNS records at the registrar from the old platform's targets to the SGEN targets.
Verification completes within twenty minutes; SSL completes within ten more.
The operator sets the custom domain as primary.
The audience sees no visible URL change; the platform behind the URL has switched.

Common questions about custom domains

Does adding a custom domain cost extra?
The domain registration cost belongs to your registrar.
SGEN does not charge per-domain on most plans; some enterprise plans add advanced routing options on a separate line.
Check your plan settings in SG-Dashboard for the exact policy.

Can I keep using the default subdomain after the rename?
Yes — the default subdomain stays attached to the site.
The recommended pattern is to leave it attached and to add a 301 redirect from every URL on the default to the matching URL on the custom domain.
That keeps inbound links from the pre-launch period working through the rename.

What type of SSL certificate does SGEN provision?
SGEN provisions a domain-validated certificate from a public certificate authority.
The certificate is trusted by every major browser and renews automatically.
For sites that need extended-validation or organization-validation certificates, contact support — those require a separate workflow.

How long does the full setup usually take?
For a registrar that propagates quickly and a domain with no existing complications, the full setup — add, verify, SSL, primary switch — is typically under thirty minutes.
Slower registrars or domains with existing CAA or HSTS configuration can take longer.

Can I attach the same domain to two different SGEN sites?
No.
A domain points at one SGEN site at a time.
To serve two sites on the same domain, use subdomain or path-based routing — blog.example.com for the blog site, example.com for the main site — with each subdomain attached to its own SGEN site.

What happens to my redirects when I rename the primary domain?
Existing redirect rules continue to fire on whichever name the rule's source targets.
For most rules that target paths only, the source is name-agnostic and the rule fires regardless of the domain it is accessed under.
For rules with full URLs in the source, audit the rule list after the rename and update any that point at the old name.

Plan for large-site, enterprise, and multi-site scenarios

A portfolio of sites or a large enterprise account raises the operational stakes of custom-domain management.
The mechanics stay the same; the discipline changes.

Large single-site planning

A site with many subdomains — region variants, blog, shop, support, status — needs a clear naming convention written down and applied consistently.
Pick a convention and document it in the team's internal runbook so future operators do not invent new patterns alongside the established ones.

For a site with sensitive content or regulatory weight, add CAA records to the domain that name the SGEN certificate authority.
CAA records restrict who can issue certificates for your domain, which lifts the security posture without complicating the renewal cycle.

For sites with very high traffic, plan the DNS-pointing window outside the busy hours of the audience.
The propagation window itself is non-disruptive — both old and new targets resolve during propagation — but the support team should be on hand if a corner case surfaces.

Multi-site portfolio planning

For an agency or in-house team running many sites, the portfolio surface in SG-Dashboard is the right lens.
Open SG-Dashboard → Site Manager → Domains for a single view of every domain across every site, every certificate renewal date, and any site sitting on a pending verification or SSL stall.

Pick a portfolio cadence and write it down.
A typical agency cadence — weekly walk of the portfolio Domains view to confirm no site is stuck on a pending row, quarterly audit of registrar-side DNS records against the SGEN-expected values to catch drift, annual review of CAA records and SSL policies across the portfolio.

For an enterprise account, every custom-domain action is part of the change record.
The Audit Log captures the actor, the moment, and the action; export the log on a regular cadence and store the export with the team's compliance records.

A documented portfolio playbook for domain renames — the steps, the redirect plan, the SEO health checks, the rollback path — turns the rename from a rare bespoke event into a routine procedure.
The first rename written up becomes the template for every rename after.

DNS audit on a quarterly cadence

A domain that is in place and serving cleanly is easy to forget.
A quarterly DNS audit catches the cases where something changed at the registrar without the team noticing.

Open the admin → Settings → Domains for each site in the portfolio.
Confirm every row reads Live and that the SSL certificate's renewal date is in the future.
For any row not in the Live state, open the row detail and read the named blocker.

Run an external DNS check against each domain — a public DNS lookup tool that shows the resolved records.
Compare the resolved records against the SGEN-expected values in the verification panel.
A mismatch is the signal that a registrar-side change has happened without coordination.

For an enterprise account with many domains, automate the audit.
The team's monitoring stack can poll the public DNS and alert when a record drifts from the expected value.
The alert closes the gap between "something changed" and "the team noticed" from weeks to minutes.

Multi-region domain planning

A site with a global audience often serves on more than one regional domain.
Plan the regional layout before the second domain is added.
A clear convention — language code at the domain level (example.de, example.fr) versus language code in the path (example.com/de, example.com/fr) — has implications for SEO, audience expectations, and operational complexity.

For a domain-level regional split, each regional domain is its own SGEN site under the account.
The portfolio surface in SG-Dashboard rolls up the regional sites for portfolio reporting.
Per-site configuration handles the regional content; the link between sites is established through the language settings rather than through routing.

For a path-level regional split, the regional content is part of a single SGEN site.
The language settings hold the language variants of each page; the platform serves the right variant based on the path.
The path-level pattern keeps the SEO weight on one domain and simplifies maintenance at the cost of some flexibility in regional branding.

Document the regional layout in the team's internal runbook so future operators understand the model before adding new regions.

Related reading

• Manage redirects
• Optimize for SEO
• Security
• Audit Log