WordPress Multisite has many uses. You can use it to create a network like Edublogs that helps people create their own site, you can use it for a network of sites or blogs for your organization, and you can use it to host sites for yourself or your clients.
If you’re like lots of web designers and developers, the chances are you’ll have plenty of domains that you’ve registered and sites that you’ve created (or some still in the works), and keeping on top of them all can be a bit of a headache. Similarly, if you run an agency or you’re a freelancer who provides hosting for your clients, again you’ll have multiple WordPress sites to keep up-to-date, which can take time.
Multisite can solve all those problems for you.
This is the fourth post in our six-part WordPress Multisite masterclass series. In this series, you’ll learn everything you need to know to create your own network, add sites to it or let users add their own, and manage the network. You’ll learn how to ensure your network is secure and high performing and how to create a successful community of users and sites.
In this tutorial, you’ll learn how you can use Multisite to host sites of your own or for clients, which act as separate sites. They all have their own domain name, and as far as visitors are concerned they’re completely separate websites. I’ll also show you how using Multisite to do this can improve your workflow and also give you some tips for making it work for you and avoiding any potential problems. Then I’ll run through the domain mapping process in detail so you can set that up on your own Multisite network.
Using Multisite to Host Your or Your Clients’ Sites
As I think you’ll know by now, if you read my posts here on the WPMU DEV Blog, I’m a big fan of Multisite and I use it for different applications. One of those is to host sites for clients. I run a small agency and while some of my clients have their own hosting or need a standalone WordPress installation because of the uniqueness of their site, many of my clients have sites that are structurally very similar, not very large, and which can be easily hosted on one Multisite network.
I do this for client sites, but there’s no reason you couldn’t do it for a network of your own sites using multiple domains. The techniques are identical.
Let’s take a look at the pros and cons of doing this.
Pros: The Benefits of Multisite for Client Sites
There are a few main benefits to hosting most of my client sites in one WordPress installation:
It saves on server space.
It saves installing WordPress every time I start work on a new site.
It saves keeping multiple instances of WordPress updated.
It saves updating plugins and themes in multiple WordPress installations.
It means I can use the same plugins on multiple sites without installing them again and again.
It means I can use plugins like Support System to communicate with clients from one installation.
For me, it makes things much more efficient. However, I have had to ensure that the way I work is optimised for working with Multisite, and put processes in place to avoid some of the pitfalls.
Cons: The Pitfalls of Hosting Lots of Sites on One WordPress Installation
There will probably be people reading this who throw up their hands in horror at the thought of keeping all of those precious sites in one place. I know there will be some who think the risks of doing this outweigh the benefits. If you’re one of those people, then by all means continue to use a separate WordPress installation for each site.
There are indeed some potential pitfalls of using one Multisite installation for all your sites:
Database size – the database can start to get unwieldy over time. But if wordpress.com and Edublogs can use Multisite to host millions of sites, there’s no reason you can’t learn from their experience to scale your own Multisite installation.
Security – If your Multisite network is hacked, then all of your sites will be affected. Pretty scary, huh? Well, yes. But in my experience whenever I’ve been the victim of a hack it’s been at the server level and it’s affected all my sites anyway. You do need to ensure security on your network, in particular if you have lots of users.
If something breaks, it could break the whole network. This is why you should never do updates on your live network until you’ve tested them on a staging site first. I’ll look at this shortly.
Perfomance – Hosting lots of sites on one WordPress installation won’t work if you’re using cheap, slow hosting or are limited by your hosting provider in terms of database size, bandwidth or uploads.
If you or your client decides to move a site out of the network in the future, doing so is trickier than simply moving a standalone site to a new server or hosting provider. But it is possible to do it. There are two ways to do this – you can either use plugins (which is simpler but less reliable) or you can export the relevant tables from the database (which is tricker but quicker and more through).
This means that using Multisite to host multiple sites will work best if these two conditions are true:
You take precautions to ensure your network is secure and that it won’t break.
You work in a way that means the same code is duplicated across all or most of the sites you build (e.g. plugins, themes). Let’s face it, how many of us have the same core list of plugins we install in every new site that we build?
Let’s take a look at what this means in practice.
Avoiding the Pitfalls: Precautions
There are precautions you can take to avoid the pitfalls I’ve listed above:
Keep your network backed up regularly – Every day at a minimum, more frequent if you have sites being updated on a daily basis. I use Snapshot Pro to back up each of the individual sites in my network, and I also use Updraft Plus to keep the entire database backed up too. This means that if one site goes down, I can use Snapshot’s one-click restore to restore it, and if the whole network experiences problems, I have a database backup I can reinstall manually.
Keep your network as secure as possible. Follow our ultimate guide to WordPress security and put in place the measures it recommends. A risk you have with Multisite over a standard WordPress installation is that you have more sites (obviously) and more users. You can put in place security restrictions during the site registration and user signup process to ensure people don’t use certain slugs for their site, to block site creation by specific domains, to keep out sploggers and to restrict people to setting secure passwords. Do these things. If you aren’t allowing user and site registration by users, make sure the processes you follow are secure.
When updating WordPress, plugins or themes, never update your live network before updating a staging version of your network first. A staging site is a copy of your live site which you use just for testing purposes (it’s different from a development site which will often be on your local machine). It’s a good idea to host your staging network on the same server as your live one so the conditions are as similar as possible. Make sure it’s blocked to search engines and keep the database as up to date as possible using your backup plugin or a tool like Vagrant.
If you can afford it, use a quality WordPress managed hosting provider. They will look after backups, security and restores for you and will often provide you with a staging environment too. Talk to your provider about the best hosting setup for your needs – something like VPS (virtual private server) works well for many Multisite networks.
Only use code from trusted sources, or write your own, This is crucial for all WordPress installations, but for Multisite it’s particularly important as if you have multiple sites running multiple themes and plugins, you want to ensure all of your plugins and themes work nicely together. If you’re using third party code, I’d recommend getting as much as possible of it from us at WPMU DEV, as our themes and plugins are designed to play nicely with each other and they’re optimized for Multisite.
I follow these tips and I haven’t had any problems with my Multisite network yet (touch wood!)
Multisite and Your Workflow
But using Multisite effectively with client sites isn’t just about avoiding pitfalls. It’s also about workflow. There are aspects of your workflow that will make using Multisite much smoother. This is about developing a workflow that makes using Multisite more efficient, and also about identifying the kind of workflow that will mean Multisite is a better way to go than lots of standalone WordPress installations.
Let’s take a look at some aspects of this:
You work with the same themes for all your sites, or a child theme of the same parent theme. This could be the case if you use a theme building system like Upfront or one of the many WordPress frameworks out there. Personally I have my own framework theme I’ve developed for use in client sites, and for each new project I create a child theme of that. The framework has lots of functions and hooks I can tap into to make each site based on it unique and add custom code, and I also use (responsive) object oriented CSS which means I can edit the styling for each new site with the minimum of fuss.
You install the same set of plugins for every site you create. Before I started using Multisite to host client sites, I had a list of core plugins that I installed on every new site. These included plugins for backing up, SEO, performance and security. Now instead of having to install them on every new site, I just have them network activated on my Multisite network instead.
You want to enhance customer service by using plugins for support or training. A plugin like Support System lets your clients raise tickets which you can respond to and turn into FAQs to display on your base site if you want to. I use this on one of my networks to keep all the support discussions with clients ion one place. If you ant to provide tutorial for your clients showing them how to use their site, you can install a plugin like Integrated Video Tutorials which will give your clients video guidance. You only have to do this once on your network and it’s there for everyone.
You want to create a community amongst your clients. Multisite is a great platform for creating a community, another’s no reason you can’t do this with your clients. I’ll look at this in depth in the next part of this course.
So, now you know what using Multisite to host multiple client sites (or your own sites) on multiple domains is all about, you need to know how to go about doing it.
Guide to Domain Mapping
If you’re hosting sites for clients, it’s very likely that they’ll each want to use their own unique domain. This might be something that puts you off using Multisite, thinking that you can only offer them a subdomain or subdirectory of your own domain.
But using unique domains for each site is straightforward with the Domain Mapping plugin. This lets you add as many extra domains as you want to each of the sites in your network and assign one as the ‘primary’ domain which will be displayed in visitors’ browsers. This means that to a visitor, the site behaves as if it’s hosted on its own using that domain.
The plugin also lets you charge your users for mapping domains to your network or to sell domains – a great way to monetise your network.
Mapping a domain to a site in your network is something you can do as the network admin or that you can leave your clients or users to do. If you’re expecting your clients or users to do it, you’ll need to give them guidance on doing this. I do this for one of my networks, while for another one I set up domain mapping myself. There are pros and cons to each approach – letting your clients do it saves you a job, but gives you more control.
Note: Domain mapping isn’t just for client sites. If you’ve created a network that lets people add their own site, they might want to map their own domain to it. You can even charge for this and sell domains.
Mapping domains to your network consists of six steps:
Copying one file from the plugin folder to your WordPress-content directory.
Making one small edit to your wp-config.php file.
Pointing domains at your network using DNS – there are two ways to do this, which I’ll cover in detail shortly.
Adding domains to the settings for the individual sites in your network.
Selecting the primary domain if it’s not the default one.
I’m going to show you the process you use to do this but first, let’s get some key concepts out of the way.
Primary vs Secondary Domains
The primary domain is the domain visitors see in their browser when they visit the site. A secondary domain is any other domain which points to that site. You can only have one primary domain but you can have as many secondary domains as you like.
So let’s imagine you have a network at http://mynetwork.com. You have a site on it (using subdirectories) at http://mynetwork.com/mysite. You want to direct two domains to that site: http://mysite.com and http://mysite.org. The primary domain is http://mysite.com, which is the domain you want visitors to see in their browser. In other words, you want the site to behave as if it’s a standalone site hosted at http://mysite.com.
The you first install the plugin, the primary domain for your site will be its subdirectory on the network, which is http://mynetwork.com/mysite. You then point the other two domains to it and add them both to that site’s settings. This will set them up as secondary domains, so they’ll point to your site but visitors will still see http://mynetwork.com/mysite in their browser. Finally you select http://mysite.com as the primary domain in your site settings (or in network settings as the network admin). This means that if someone types http://mynetwork.com/mysite, http://mysite.com or http://mysite.org into their browser they’ll be taken to http://mysite.com and they’ll see the site you’ve created at http://mynetwork.com/mysite – but they won’t know it’s part of the network.
Confused? Hopefully, you won’t be when we’ve worked through the process!
DNS: A and CNAME Records
Another concept you’ll need to understand before you use domain mapping is DNS, which stands for Domain Name System. This is the system you use to tell a domain name which server and/or site it should point to. To do this, you can use one off two methods:
A records map a domain to an IP address, which is a unique identifying code for a server. For example, the WPMU DEV site is hosted at the 188.8.131.52 IP address. This is the most fundamental address for any website, and any domain name will eventually resolve to an IP address. If you’re asking your clients to set up domain mapping themselves, a good way to do it is by having a unique IP address for your network (which you can buy from your hosting provider) and then getting them to create A records posting to that for their domain.
CNAME records map a domain to another domain. So in the example above, http://mysite.com might have a CNAME record of http://mynetwork.com/mysite. Using this saves you having to have a unique IP address.
All this will become clearer as we work through the process.
Setting up Domain Mapping
Setting up Domain Mapping doesn’t take long, although it can take a while for the DNS changes you make to any domains pointing at your site to propagate. Propagation is the process of your DNS records taking effect across the internet – you can watch your DNS changes propagating by using a DNS checker if you’ve got time to kill!
You will need FTP access to your network and a text editor, as you’ll need to copy a file and edit another one. If you don’t have a text editor already, you’ll find one in our roundup of the best ones.
Let’s get started.
Installing the Domain Mapping Plugin
The first step is to install the plugin. Do so in the normal way, via the WPMU DEV dashboard or by uploading it to your wp-content/plugins folder. Then activate it.
Now in your network admin screens go to Settings > Domain Mapping. You’ll notice a dirty great error message telling you what you need to do next:
Now in your FTP client find the wp-content/plugins/domain-mapping directory. In there you’ll find a file called sunrise.php. Take that file and copy it (don’t move it) to your wp-content directory.
Now open your wp-config.php file, which you’ll find in the root folder of your WordPress installation. Find the line that reads:
Above that line, add a new line and type this:
Now save your wp-config.php file.
Go back to your site and refresh the domain mapping screen you were in before. The error message will be gone:
Now you can get your domain configuration set up.
Configuring Domain Mapping for Your Network
The plugin will automatically detect your IP address and give you that in the domain mapping screen. Copy that into the Server IP Address field below the blue box that shows the IP address. If it isn’t detected for you by the plugin, use a DNS checker or ask your host for your IP address.
Then scroll down to the Allow multiple mappings per site section. If you want to restrict your site admins to adding just one mapped domain, leave this unchecked. However I like to use more than one domain, so I’ll check that.
The next section is called Administrative mapping. This relates to the domain that will be used for the admin screens. So for a site mapped to http://mysite.com but hosted on http://mynetwork.com/mysite, you can choose to use http://mysite.com/wp-admin or http://mynetwork.com/mysite/wp-admin for the admin screens. Using the mapped domain is better for clients, as they’ll be working with their site as if it’s hosted on their own domain. But for users creating their own site, who will know that they’re on your network, you might prefer to use the network domain instead. Alternatively you can give site admins the option to choose which one they use
These are the options:
Domain entered by the user – the site admin gets to choose which domain to use for admin screens.
Mapped domain – the mapped domain will always be used, for all sites with mapped domains.
Original domain – the network domain will be used for all sites.
I’m selecting the first option, as it gives me more flexibility.
You then have the option to make a similar choice in the Login mapping section, but this relates just to the wp-login screen. Even if your sites are using the network domain for their admin screens, it can look more professional if you use the mapped domains for login screens. It also means that if the sites on your network have users who can log into that site but aren’t aware that the site is mapped, then the login screen won’t confuse them. So here I’ll select the second option, mapped domain.
Next up is Cross-domain autologin. This lets you allow users to log in to all the sites on your network that they have access to with just one login. I find this useful for users with multiple sites and for myself as the network admin when I’m working across sites, so I select Yes. If you’d rather force your users to login to each site separately, select No.
Now scroll down to the Check domain propagation before mapping section. If you select Yes here, the plugin will check that a domain has been successfully mapped to your network before mapping it. This is useful if your users will be setting up their own domains as it prevents them from making a mistake. But if you’re doing the domain mapping yourself for your clients, you might prefer to select No. Personally I tend to set up domain mapping at the same time as doing the DNS, which means the DNS won’t have propagated when I set up domain mapping – but it will do in time. So I select No.
The next two sections release to HTTPS, and are only relevant if you’ve bought a SSL certificate for your network, making it more secure. Here you can choose whether or not to force https for login and admin pages and for front-end pages. I’m leaving No selected in both cases as my network doesn’t have SSL.
Next, in the Prohibited mappings field, add any domains that you don’t want your users to map to your network. As I’m working with known client domains I don’t need to add anything here, but you might use this to avoid spammy domains being directed to your site, or ones which conflict with your organisation or brand.
The next section is called Enable excluded/forced URLs. Here are the options:
Allow site admins to set map-excluded pages – site admins can specify individual pages on the site that won’t use mapped domains.
Allow site admins to set map-excluded URLs – site admins can specify individual URLs on the site that won’t use mapped domains.
Allow site admins to set https-forced pages – site admins can specify individual pages on the site that will have https forced, which could be useful for store pages or login pages.
Allow site admins to set https-forced urls – site admins can specify individual pages on the site that will have https forced.
I’m going to uncheck the second two as I’m not using SSL.
Once you’ve done all that, click the Save Changes button to save your changes.
In the Domain Mapping screen there are three tabs. We’ve already completed the first one, Mapping options. The second, Reseller options, is relevant if you’re selling domains through your site, and gives you access to providers you can use to do this. As I’m working with clients and I buy their domain names myself, I don’t need to use this tab.
The third tab is Mapped Domains. Here you can see what domains have been mapped for individual sites in your network and manage them. Even when I’m working as network admin, I tend to add domains in the site admin pages for each site, so I don’t normally use this tab. However if you have a site in your network that’s not available because the primary domain isn’t working (and the primary domain is mapped for admin screens too), then this is the only place you’ll be able to switch off mapping for that domain, or demote it to a secondary domain. It’s very useful to have access to this screen if that happens!
Once you’ve got domain mapping configured, you need to add a domain. This consists of two steps: pointing it at your network and adding it to the site.
Pointing a Domain at Your Network
To point a domain at your network, you need to use the admin system provided by your domain registrar. You can either use a CNAME or A record. Sometimes you might find that one of them doesn’t work, in which case try the other. Remember:
An A record consists of the IP address of your network, which is a numerical value.
A CNAME record is the domain name of your site.
Site Administrators have a screen for domain mapping that provides them with the information they need to do this. In the individual site, go to Tools > Domain Mapping:
Use your registrar’s tools to set up a CNAME or A record with the correct information.
Note: some domain registrars don’t provide DNS tools because they restrict you to using their own servers or charge you extra for DNS. If this is the case, speak to them to see if they’ll do it for you. Or even better, find another domain registrar. It’s your domain and you should be allowed to point it wherever you want.
Adding Domains to a Site
Once you’ve pointed the domain at your site, you need to add it to the domain mapping settings for that site. In the site admin screens for the site, go to Tools > Domain Mapping (if you’re not there already).
In the Map new domain name field type the domain name to be mapped and click the Map domain button. Below you can see that I’ve done this with a made up domain name: it’s showing as invalid because the domain doesn’t point to my site. If your DNS has worked it will give you a valid message instead.
Note: Adding a domain that isn’t pointing at your site here will do nothing. So you can’t use this plugin to get lots of domains you don’t own posting to your network!
If you’ve enabled it in the network settings, you can add as many domains as you want.
To select a domain as the primary domain, click the star icon to the right of its name. Only do this for domains which are successfully pointing to your site – if the DNS hasn’t resolved yet you won’t be able to access your site. If you need to, you can easily demote a domain to a secondary domain by unclicking that star later on (either here or in the network admin screens).
Any domains added to a site will now show up in the network admin screens, meaning the network administrator can also manage them. In the network admin, go to Settings > Domain Mapping and select the Mapped Domains tab:
This shows all the mapped domains and lets you manage them. From here you can delete mapped domains, make them primary domains (or remove the primary domain status) and switch them between http and https using the key icon.
And that’s it! Once you’ve added those domains you don’t need to do anything else. If you’ve added a primary domain to a site and used it for the admin screens as well as the front end, you will need to log in again, but apart from that, you’re good to go.
Domain Mapping Makes Multisite Even More Useful
To me, domain mapping is the thing that knocks criticism of WordPress Multisite out of the water. For those people who worry that their site won’t behave as if it were hosted alone, on its own domain, all they need do is set up domain mapping and then it will.
With domain mapping and some well organised security and workflow processes set up, you can use WordPress Multisite to host a network of client sites (or of sites created by yourself or your users) that behave as if each is a standalone site with its own domain. This gives you the efficiency advantages of Multisite without making the sites hosted on your network look less professional or impacting on SEO.
In the next tutorial in this series, we’ll explore another powerful aspect of WordPress Multisite: creating a community. I’ll show you how to use your network to connect your users and let them share content, follow each other and more. Missed a tutorial in our Multisite masterclass series? You can catch up on all six posts here: