I’ve spent a lot of time over the last six months working with enterprise customers as they setup multisite in Drupal 9. One of the most common conundrums for organizations as they approach multisite is figuring out how to manage the sites’ domains. This post is all about the differences between domain-based and path-based multisite. Picking one or the other (or trying to do a hybrid) will have major implications on your application, so it’s not a decision to be taken lightly!
What is the Same (and what isn’t)
Right up front, let’s get a few of the similarities out of the way. Regardless of which option you choose (purely domain, purely path, or a hybrid):
All your your sites will have their own, unique databases. This means that each site will have separate content, users, etc.
Each site will run off of the same underlying codebase / application / docroot. This means that all sites will run the same version of Drupal, modules, etc.
Deployments / updates will impact all sites simultaneously
Where does that leave us? It’s how you actually navigate to the sites that is going to change in these approaches. And while this may not sound like a big deal (it’s just DNS, right?) it can actually have a really significant impact on your application and the content you’re trying to manage.
In the following sections, I’ll use the example of a university website with a number of departments to illustrate the differences.
Introduction to Domain-Based Multisite
Domain-Based is my personal recommended approach. In this scenario, each site in your multisite setup has its own, unique URL. These could be entirely separate domains, sub-domains, or a mix.
For the domain-based example, let’s examine our university example.
example.edu [default site]
nursing.example.edu [site 1]
music.example.edu [site 2]In this case, example.edu would be our default site and will serve as the primary website. Any paths under example.edu (e.g. example.edu/admissions) would be pages owned by the default Drupal site. Likewise, nursing.example and music.example are separate sites in the multisite, and nurising.example.edu/admissions is piece of content owned by the school of nursing.
A domain-based world can have significant implications on domain / SSL configuration, as you will need to register many (perhaps hundreds / thousands) of domains for your platform and provide SSL certificates for each (or, be willing to register and share a wildcard certificate with your hosting provider).
Having said that, this approach “let’s Drupal be Drupal” and own all of the paths and routing necessary to create and manage content within each multisite.
Introduction to Path-Based Multisite
Path-Based multisite can be significantly harder to manage than a domain-based approach, although there are some potential SEO benefits (so it shouldn’t be dismissed entirely out of hand).
Let’s go back to our university example:
example.edu [default site]
example.edu/nursing [site 1]
example.edu/music [site 2]Here we see that the default site would still be example.edu. The primary differences are that the schools of nursing are now nested under this domain. Here is where things start to get confusing…
example.edu/admissions [?]
example.edu/nursing/admissions [site 2]Let’s go back to my example of an admissions page. The admissions page under the nursing site is certainly a page on the nursing multisite. Got that one. But what about the admissions page? Is that a page controlled by the default site? Or is that an entirely separate multisite in the array? Honestly, it can be either, but it can’t be both.
Remember that in a Drupal multisite scenario, you have a single docroot / codebase. That means that if you want to have a site like at a path (e.g. nursing) that path becomes unavailable to the default site to use for content. So, in this case, even if example.edu had a page of content called “nursing” it would be able to serve that page at example.edu/nursing because that path is being reserved for the school of nursing’s website.
In fact, this challenge will expand throughout all paths. Once you define a multisite at a path, the default site will lose access to place content on that path (as it will belong to another multisite).
Introduction to a Hybrid Approach
I won’t spend a lot of time on this, aside from defining it and strongly recommending that you don’t do it.
You can, technically, do a combination of both.
example.edu [default site]
example.edu/admissions [site 3]
nursing.example.edu [site 1]
music.example.edu [site 2]In this case, let’s pretend that the school of nursing and music opt to go with the domain-based route and register sub domains. But, for whatever reason our university decides that the office of admissions needs another site (not just a page within the default site). HOWEVER due to whatever fake university policy, they don’t get a subdomain. Instead, they setup a path based domain.
By adding both domains and paths, any path-based multisites will exist for all domain based sites.
example.edu/admissions [site 3]
nursing.example.edu/admissions [site 3]
music.example.edu/admissions [site 3]In this example, if we add admissions as a path-based multisite to the default example site, it becomes a path-based multisite for ALL sites. So, each of the three links in this example all route to the same site.
The hybrid approach becomes incredibly confusing because routing people to the place you want them to actually be gets weird real quick.
Other Considerations
As mentioned above, both a domain based and path based domain approach can have an impact on your SEO. Remember that a domain based multisites are treated as entirely separate websites by Google and other search engines, meaning that your primary domain may not get the benefit of keywords or other search context. This would be less of a factor with path based, as the path based domains are considered part of the root. You can read more on this topic here.
In Conclusion
There’s not really a “wrong” approach to doing this (except maybe hybrid). I am recommending the domain-based approach because I think it is MUCH easier to manage long-term and it’s much more comfortable to let Drupal mange paths and content internally (than it is to try and muck about at the server level with paths going to content, sometimes, and websites others).
Just do your research, consider the implications of SEO, and make a decision as early as possible so that you can build towards the right approach!
Related Content
Managing the domains of a multisite can be very complicated. Which strategy should you choose?