Your Community’s Web Address
Customizing the web address (URL) of your community is an important step in setting up a new Vanilla forum. We recommend giving your community forum its own home on a subdomain of the primary domain you use in your web presence. For example, if you have your main website at example.com, you should use an address like https://community.example.com for your Vanilla forum.
Once properly set up your new custom domain hosted on Vanilla will automatically have an SSL Certificate generated and installed so that it can be served over HTTPS.
Using a Custom Domain
Newly created Vanilla communities are given a public URL that looks something like yourcompany.vanillacommunities.com.
In order to unify your branding and improve SEO, prior to launch you will want your new community’s URL to be something like community.yourcompany.com.
It’s a simple process. You just have to log in into you forum dashboard, go to Settings -> Custom Domain and follow the on-screen instructions:
Securing your Custom Domain
SSL certificates are automatically installed for both Vanilla URLs and Custom Domain.
You do not have to worry about it!
If you are using a top-level domain such as yourcommunity.com (as opposed to community.yourcompany.com), please read on!
A-Records
We still highly recommend CNAMEs, however 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.79
- 162.159.138.78
If you are using a provider that supports “CNAME Flattening”, such as Cloudflare, you can even switch this to a flattened CNAME pointing at site-{YOUR_SITE_ID}.onvanilla.net, which is ideal and highly recommended.
If you choose to use a top level domain for your community, we also recommend that you create a matching CNAME for the “www” subdomain which points at the top level domain.
For example, if you choose to use "domain.com", we recommend that you create a CNAME for "www.domain.com” which points at “domain.com”. This will ensure that both the naked top level domain and the standard “www” version will each work.
Subdomains vs. Subfolders
Forums are a first-class web application and a primary driver of content in a healthy web presence. Even when a forum is not the main focus of your web presence, it should be maintained on its own subdomain.
In the past, forums were frequently set up as subfolders (e.g. example.com/forum) under the root domain of a web presence. The reality of many legacy server setups made this the simplest way to run a forum 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 reindexed.
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 Suggest or Offer 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 example.com silently forwards requests for example.com/forum to the independent server where your forum 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 forum must pass thru it.
- 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 forum becomes dependent on the main website, adding a big asterisk to any SLA.
- You are responsible for the setup and maintenance of a reverse proxy setup, which is what cloud services are designed to eliminate.
- It complicates all network-related trouleshooting, which leads to more complex support needs and communication overhead.
- The forum cannot effectively be protected from DDoS via Cloudflare or similar service.
- Security of the forum 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.
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/node1
community.domain.com/node2
Etc
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.com
Node2.community.com
Etc
Note that option number 2 requires that the DNS is configured for each instance - resulting in more work for you and as a result is considered slightly more fragile.
