Subdomain & custom domain
Understand the default OmniLab domain, aliases, and delegated custom domains used to publish OmniLab Pages.
Decide which web address your campaign appears under, from a quick OmniLab-hosted link to your own branded domain. This page covers the three options you can use: the default OmniLab-hosted domain, extra aliases, and a custom domain on your own website.
The three domain options
The default OmniLab-hosted domain is the standard OmniLab Pages web address OmniLab gives you when you launch without a branded domain.
| Term | What it means | Typical example | Best fit |
|---|---|---|---|
| Default hosted domain | The standard OmniLab Pages hostname on .topage.co. This is the fastest launch option. | https://example-brand.topage.co | Pilot launches, internal review, first public rollout |
| Alias | An extra public hostname that points to the same OmniLab Pages deployment as the main domain. Teams use aliases when different brands, locations, or channels need their own entry URL. | https://paris-centre.topage.co | Multiple entry points for the same rollout |
| Custom domain | A branded address on your own website, pointed to OmniLab by your IT or web team. | https://experience.example.com | Final branded launch, embedding under your own site domain |
How aliases and custom domains relate
A custom domain is a branded form of alias. The difference is who owns the address: OmniLab-hosted aliases usually stay on .topage.co, while a custom domain uses your own website address.
Recommended rollout path
Move through three stages:
- Start fast on the default hosted domain — launch on
.topage.coto keep things simple while you build and test. - Add aliases if needed — create extra entry URLs when different brands, locations, or channels each need their own public address.
- Add a branded custom domain when ready — switch to your own domain once the rollout is stable and your branding is confirmed.
How OmniLab chooses the main public base URL
At organisation level, OmniLab Pages uses one main base domain for public campaign URLs. OmniLab Campaigns and touchpoints then append their own public path and query parameters after that base domain.
| Organisation state | Main public base URL |
|---|---|
| A custom domain is configured | https://<custom-domain> |
| No custom domain is configured | https://<organisation-subdomain>.topage.co |
That means the same Campaign Public Link can stay unchanged while the organisation changes the host in front of it.
What you typically manage in OmniLab Studio
- Use the organisation Domain settings for the main OmniLab Pages subdomain when your rollout uses the default hosted domain.
- Treat extra aliases and custom domains as deployment work that may involve OmniLab plus your IT and web teams.
- After any domain change, retest landing pages, touchpoint URLs, QR codes, and embedded OmniLab Pages experiences before sharing the final links.
When to choose a custom domain
Choose a custom domain when:
- you want OmniLab Pages to appear under your own brand domain
- your website team wants the embedded experience to sit under the same top-level domain as the host page
- final QR codes, campaign links, or media placements must use the branded public hostname
If you do not need those constraints yet, the default hosted domain is usually the quickest and lowest-friction way to launch.
Related
Organisation domain settings
See what the organisation Domain screen manages directly in OmniLab Studio.
Embedding
Use the right implementation pattern for iframe, WordPress, WebView, or delegated-domain embeds.
Touchpoint URLs & slugs
See how the base domain combines with the Campaign Public Link and touchpoint parameters.