How to: White Labeled Staging Domain for Clients

Occasionally, clients will want to see the progress of their beautiful new website. Or maybe you just want to show off some new changes. But you don’t want the changes to be indexed by search engines, and you don’t want them accessible to the public [yet].

Fortunately, you can have a password-protected custom staging domain for a Webflow-hosted website with a few quick and easy steps. This way you can show off your work at staging.example.com instead of staging.webflow.io.

You can skip the first two steps if your site’s already setup with Webflow Hosting.

1. Buy Hosting

Connecting any project to a custom domain requires Hosting [otherwise everyone would just proxy their domain to their Webflow.IO staging subdomain without paying for server costs]. You will not need a Lite or Professional Account Plan for this.

Any Webflow Hosting Plan [Basic, CMS, or Business] will work, although we ask that you don’t use Webflow in your domain. :wink:

2. Add your domain & setup DNS

You will need these three records when using SSL:

Two A records:

@ → 34.193.69.252
@ → 34.193.204.92

One CNAME record:

www → proxy-ssl.webflow.com

We have a helpful, step-by-step tutorial on setting up your custom domain that I would highly recommend here:

3. Add an additional CNAME record for staging

Here’s what my Webflow DNS records look like:

4. Add your subdomain under Hosting Settings

Add your staging subdomain under the Custom Domains section just like any other subdomain:

https://dha4w82d62smt.cloudfront.net/items/132S3H1t2x0s2S0H0l0h/Screen%20Recording%202018-06-06%20at%2004.38%20PM.mov?X-CloudApp-Visitor-Id=2844539

5. Enable Password Protection and publish to staging

First, I always try to make a manual backup version before I make any changes to the staging site. Because I have definitely broken things in the past. And restoring backups can be a lifesaver. You can do this within the Designer with ⌘+Shift+S (or Ctrl+Shift+S on Windows).

You can learn more about backups here:

Next, navigate to the General Settings of your project. Scroll to the section where it says Website Password to enable and set a site-wide password.

Click the dropdown arrow on the Publish button and publish only to your staging domain:

Now your staging domain has site-wide password protection, and the content won’t be indexed by search engines or accessible to people who don’t have the password, but your production site will still be operating as usual:

Make sure you don’t publish to your production domain, or else your changes [and the password protection] will be on your live site.

6. But what if I need to publish to my production website?

When ready to publish changes to your live site, simply disable password protection from your project’s General Settings and publish to your live domains from the dropdown menu.

Aaaaaand that’s it!

Because site-wide password protection is applied after publishing – and it only applies to the domains you publish it to – you can use this to have a password protected custom staging domain that won’t be accessible to the public.

Hope you find this to be helpful, and feel free to reach out to me [or any of our Customer Success Team members] if you have questions! We’re always happy to help!

- Andrew

8 Likes

Hi,

Thank you for putting this together, I’m new so I am finding it difficult. Would you be able to provide another screen recording? The one regarding the subdomain (#4. Add your subdomain under Hosting Settings)the link that’s there isn’t working.

Hello,
I added various custom domains to my Custom Domains tab.
But still, I’d like to use the “DEV” subdomain as staging site.
And when I hover on Publish, I only see my main domain and the staging webflow.io one, is it normal ?
Cheers

@jonathanplevy You have probably made one of your custom domains default. Once you do that you can only publish to the default and the ***.weblow.io domain. Remove the default and all your custom domains become available to publish to.

Dear Erik,

Thanks for your reply.
I found out later yesterday that this could be the original problem.
What I’m afraid of is that if I don’t make one domain the main one, Google will scan and index all URLs and I would like to avoid the dev domain to be indexed for SEO reasons…
Cheers from Paris

Jonathan,
to avoid duplicate indexing problems use canonical URL’s

1 Like

Sometimes the simplest things are the ones we tend to forget…
Thanks a lot for your help Erik!
Wish you a great weekend
Cheers

1 Like

@Andrew Do you have any suggestions on how to handle a client updating the site via the editor when a staging deploy is “active”?

I’ve set this all up which works great, but if I go to the editor and change some content, the Publish button does not give me an option to pick which domain to publish to (or change password protection settings), and so clicking Publish results in the updates being pushed to every domain, which causes the “live” site to now include design changes from staging as well be password protected.

This seems like a pretty tricky issue if you have a client who may be updating site content while you are making design changes using a staging domain…

Any thoughts on how to handle this type of situation?

1 Like