WordPress Multisite Domain Mapping Master Class For Client Sites
WordPress Multisite has many uses. You can use it to create a network like Edublogs that helps people create their own site. Or a network of sites or blogs for your organization. You can also use it to host sites for yourself or your clients.
If you’re like many web designers and developers, you’ll have plenty of domains registered for sites you’ve created (or some still in the works). Keeping on top of them all can be a bit of a headache. Similarly, if you run an agency or are a freelancer, and you provide hosting for your clients, you’ll have multiple WordPress sites to keep up-to-date. This can take a lot of time and effort.
WordPress 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. You’ll also learn how to manage the network and ensure that it’s secure and high performing. In the end, you’ll find out how to create a successful community of users and sites.
In this tutorial, I’ll cover 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.
Missed a tutorial in our WordPress Multisite Masterclass series? You can catch up on all six posts here:
- WordPress Multisite Masterclass: Getting Started
- WordPress Multisite Masterclass: Activation and Configuration
- WordPress Multisite Masterclass: Site and User Registration
- WordPress Multisite Masterclass: Client Sites and Domain Mapping [the post you’re reading now]
- WordPress Multisite Masterclass: Creating a Community
- WordPress Multisite Masterclass: Managing your 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 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 Awesome Support 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.
- Use one or more of my recommended plugins for network managers to smooth the network management process. A plugin I find especially useful is Multisite Enhancements, because it helps me with updates by showing me which sites are using which themes and plugins. This means I know which sites to test.
- 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 Beaver Themer or one of the many WordPress frameworks out there. Personally, I’ve 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 minimum 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 Awesome Support 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 want 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, and there’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 doing it yourself 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:
- Install a WordPress Multisite Network
- Configure DNS Records (Namerservers) for the Custom Domain
- Add the Custom Domain to Your Hosting Account
- Map a Network Subsite to Its Custom Domain
- Repeat the Process for More Subsites (if needed)
Before we get going, let’s discuss some important concepts that you need to understand.
Primary vs. Secondary Domains on a Multisite Network
The primary domain is the URL 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 network 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.
When you first enable Multisite, 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 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, get them to create A records pointing 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.
Time to Set 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 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 also 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.
Ready to get started? Go here for a detailed guide on WordPress Multisite domain mapping. It covers all the steps mentioned above.
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 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:
- WordPress Multisite Masterclass: Getting Started
- WordPress Multisite Masterclass: Activation and Configuration
- WordPress Multisite Masterclass: Site and User Creation
- WordPress Multisite Masterclass: Client Sites and Domain Mapping
- WordPress Multisite Masterclass: Creating a Community
- WordPress Multisite Masterclass: Managing Your Network