Staging Domains
Serve your staging build on custom domains, not just webflow.io.
The auto-detect embed picks an environment per request: it serves your staging build on .webflow.io addresses and your production build everywhere else. Staging domains extend that list, so a site on your own staging host gets the staging build too.
When You Need This
- Your Webflow site is on Enterprise, where staging runs on a custom hostname instead of
.webflow.io. - You preview on a host that isn't Webflow at all: a review deploy, a client-facing staging site, or a copy of the site on a subdomain you control.
- You want a specific address, like
staging.clientsite.com, to always load unreleased code while the live domain keeps serving production.
If you only publish to .webflow.io and your live domain, you don't need this. Auto-detect already handles both.
Configure Staging Domains
- Open the Domains icon in the left activity bar.
- Turn on Staging domains.
- Add each host that should load your staging code. Wildcards work:
*.example.comcovers every subdomain and the bare domain. - Use the auto-detect embed on those sites. The staging and production embeds are fixed to one environment and ignore this setting.
Propagation Timing
Changes take effect within about a minute. Save the list, wait a moment, then reload the site with the cache cleared.
webflow.io Is Always Staging
.webflow.io domains always use the staging build, whether or not you list them here. You never need to add one. The list is for hosts auto-detect would otherwise treat as production.
What a Staging Domain Also Allows
Adding a domain here does two things, and the second one is easy to miss:
- Requests from that host get the staging build through an auto-detect embed.
- That host is allowed to load this project's code, even when domain protection is on and the host isn't in the allowed list. That allowance is not limited to staging. The same host can load your production bundle too.
Two practical consequences:
- A wildcard on a host you share with other people (
*.pages.dev,*.vercel.app,*.netlify.app,*.github.io) allows every site on that host, not just yours. Prefer the exact hostname you control. - Removing a domain here removes both effects. Give it a minute, then re-check the site.
Interplay With Domain Protection
The two settings live side by side in the Domains panel and work together:
| Setting | Question it answers |
|---|---|
| Domain protection | Which domains may load this project's code at all? |
| Staging domains | Which of those domains get the staging build instead of production? |
When both are on, the protection card notes that your staging domains are allowed as well, so the allowed list you see there isn't the whole story.
Plan Requirement
Staging domains require the Beta, Individual, or Team plan. Free plan projects see an upgrade prompt in the Domains panel. See Plans and Limits.
Troubleshooting
If a site still loads production code:
- Confirm the site uses the auto-detect embed, not the production embed.
- Check the hostname matches exactly, including
www. Use a wildcard if you need subdomains. - Wait a minute after saving and reload with the cache cleared.
- Confirm you deployed to staging at least once. Auto-detect can only serve a staging build that exists.