When setting up a new Higher Logic Vanilla (Vanilla) community, customizing its web address (URL) is an important step.
- We recommend giving your Vanilla community its own home on a subdomain of the primary domain you use for your web presence.
- For example, if your main website is
example.com, you should use an address like https://community.example.com for your Vanilla community.
Once set up, your custom domain hosted on Vanilla will automatically have a secure sockets layer (SSL) Certificate generated and installed so that it can be served over HTTPS.
📝 NOTE: At this time, Vanilla does not support multiple domains/subdomains. This means that you will only be able to point your chosen subdomain to your site. For example, if you set up subdomain.yourdomain.com, you will not be able to also use a CNAME record for www.subdomain.yourdomain.com.
Set up a custom domain
New Vanilla communities are given a public URL that looks something like:
yourcompany.vanillacommunities.com
In order to unify your branding and improve search engine optimization (SEO), you'll want to change your community's URL prior to launch to something like:
community.yourcompany.com
Fortunately, this is a simple process:
- Access the Dashboard.
- Navigate to Settings > Appearance > Custom Domain.
- Follow the provided instructions.
Secure your custom domain
SSL certificates are automatically installed for Vanilla URLs and custom domains. There's nothing you need to do!
📝 NOTE: We are unable to accommodate customer-provided SSL certificates. Our infrastructure is set up to handle renewals automatically, and attempting to circumvent this with a manual process opens your site up to performance issues and downtime.
⚠️WARNING: Certificate authorities often have limits on the number of SSL certificates they will issue for a single domain within a given timeframe. Please avoid adding, removing, and re-adding the same custom domain to avoid issues.
However, if you're using a top-level domain, such as yourcommunity.com instead of community.yourcompany.com, please read on.
A-Records
We highly recommend CNAMEs, but we do support static IPs.
If you would like to use a top-level domain (A-Record), your developer should point your root domain to one (or ideally both, using multiple A-records if you can) of the following IPs:
162.159.128.79162.159.138.78
If you're using a provider that supports “CNAME Flattening,” such as Cloudflare, you can switch this to a flattened CNAME pointing at site-{YOUR_SITE_ID}.onvanilla.net, which is ideal and highly recommended. This should be done after you've connected and confirmed the domain setup is working.
📝 NOTE: If you use A-Records, visits to the *.vanillacommunities.com domain will not automatically resolve to your custom domain. This means your site will be available at both URLs. If you’re using SSO, we recommend setting up your IdP to handle logins from *.vanillacommunities.com and your custom domain.
Subdomains vs. Subfolders
Communities are a first-class web application and a primary driver of content in a healthy web presence. Even when a community is not the main focus of your web presence, it should be maintained on its own subdomain.
In the past, communities were frequently set up as subfolders (e.g., example.com/community) under the root domain of a web presence. The reality of many legacy server setups made this the simplest way to run a community, and it became fairly standard to see sites organized this way. And in the 90s and early 00s, search engines often did not combine rankings across subdomains, causing “splintered” SEO effects. In the age of web services, none of this is true anymore.
In the present, all first-class search engines catalog subdomains as an extension of the primary domain. Google Webmaster Tools, in particular, has settings to manually declare subdomains as official parts of your primary web presence, and notes that there is no penalty or side effects to this setup. Google itself offers subdomain-based web services based on this model, so there is no rationale for believing it would penalize it.
Even if your site has used subfolders for many years, it is safe to transition to a subdomain-based URL system using properly configured 301 redirects. Whenever implementing 301 redirects for any reason, it is normal to see a short-term decline in traffic while the pages are re-indexed.
Implementing a proper web services architecture by using subdomains for independent applications gives you a more robust and secure web presence with no downsides.
Why we don’t recommend subfolders
Reverse Proxy is the only reliable way to serve an independent web application in a subfolder of a domain that is mapped elsewhere. In this setup, your main website (e.g., example.com) silently forwards requests for example.com/community to the independent server where your community is hosted. In other words, your server is now a single point of failure for what should be an independent service, since all requests to the community must pass through it.
In addition, there are other downsides to consider:
- Requests are slower, because they have to make an extra jump. This hurts search engine rankings (Google has stated response times are a factor in rankings).
- Uptime for the community becomes dependent on the main website, adding a big asterisk to any SLA.
- You are responsible for the set up and maintenance of a Reverse Proxy setup, which is what cloud services are designed to eliminate.
- It complicates all network-related troubleshooting, which leads to more complex support needs and communication overhead.
- The community cannot effectively be protected from DDoS via Cloudflare or similar service.
- Security of the community is now dependent on the security of the main website since all requests are intercepted.
These are serious compromises that come with no measurable benefit.
Hub/Node
This section is for Enterprise (FKA VIP) clients using our Multisite feature.
Each Node is accessible via either a subdomain or a subfolder off a domain shared by the whole Hub. This is called the Hub URL Format.
For example, the muffins Node in the bakery Hub might be accessible at the URLs muffins.bakery.company.com or bakery.company.com/muffins, depending on the configuration. Only one type of Hub URL Format is supported per Hub.
Clients using our multisite (Hub/Node) feature can structure their domain in one of two ways:
Folders for each node
This method uses the format: community.yoursite.com/<nodename>
For example:
community.domain.com/node1community.domain.com/node2
Subdomains for each node
This method uses the format: <nodename>.yoursite.com. Sites cannot have more than one yoursite.com, and each node must be a subdomain of a single top-level domain.
For example:
Node1.community.comNode2.community.com
📝 NOTE: This method requires that the DNS is configured for each instance, resulting in more work for you. As a result, this method is considered slightly more fragile.
FAQ
Is it possible to have multiple custom domains leading to the same Vanilla community?
- Vanilla only supports one custom domain being pointed toward it at a time (this being the one you set up on the Settings > Appearance > Custom Domain page in the Dashboard).
- If you would like additional URLs to lead to your community, you would need to set up redirects on your end for any other custom domains that you have to take users to the community.
Additional resources
Click the link below to access a video expanding on what you learned in this article.
