Blog > Content Marketing > The Pros and Cons of WordPress Multisite vs ManageWP
The Pros and Cons of WordPress Multisite vs ManageWPPublished by James Parsons • Category: Content Marketing

Have you ever wondered how some of the largest blog networks out there do it? How they manage all the disparate sites and users? I did, once, so I took a look at Gawker media. They have a bunch of different sites, like Gizmodo, Lifehacker, Kotaku and Io9. They have a unique and consistent look, which indicates that they all run on the same content management system. A good guess might be WordPress.

Well, unfortunately, it’s not true. I can’t use Gawker as a WordPress example because they don’t use it. All signs point to their CMS being a completely custom, in-house design. Oh well! The point is, you can use WordPress to manage a multiple-site blog network, and if you want, you can even use a Gawker-like theme.

What is WordPress Multisite

WordPress Multisite is a feature you can use with any default WordPress.org installation. It allows you to use one single WordPress installation to host and run as many individual blogs as you could want. It’s insanely scalable. I’m not exaggerating; looking at it has driven men to madness before.

Multipress Screenshot

Okay, so not really, but it’s still crazy big. WordPress.com, you know, that blog platform that hosts hundreds of thousands of free blogs? That’s all one WordPress installation running Multisite. Oh, I’m sure they actually have several redundant installations and backups across a server farm, but the core of it is the concept. It’s all one thing, it’s all one entity, running an incredible number of blogs.

You’re never going to need that many, personal user or business. Realistically, the limit is more tied to your web hosting. Multisite can use up a lot of resources, so your hundred blogs suddenly require significant hosting fees. Remember; Multisite doesn’t save you from the requirements of hosting several sites; it just helps keep them under one roof for management and CMS.

The Pros and Cons of WordPress Multisite

Multisite is a great system, except when you try to do something it doesn’t and cannot support. At that point you run into a wall; do you do without that feature you were looking for, or do you explore non-Multisite options? Rather than face that decision, it’s good to go into it with a firm idea of what Multisite can do and how to use it.

Multisite, to start off with, is great at sharing. It’s one core code installation, running on one server.

  • Your central code base is shared, so you don’t have to worry about updating six versions of WordPress every time a patch comes out.
  • Your user base is shared, so you don’t have to worry about inconsistent usernames and passwords amongst your writers and commenters.
  • Your plugins are shared, so every blog has the same internal and external features, and even things like calendars are shared and visible to each blog as centralized editorial tracking.
  • Your themes are shared, though they can be controlled, so each sub-site has its own theme but you can swap between them freely.

The single biggest perk of this is the fact that everything is one install. It cannot be stressed enough how convenient this is. If you have two sites, you know how much of a hassle it is to go through the entire update and compatibility testing process with one only to have to start over with another. Imagine if you had 35 different sites. With Multisite, every one of those sites is using the same code, so you update WordPress once, do your compatibility testing once, and you’re done.

The flip side to this is that with everything shared, Multisite doesn’t keep secrets. If a user logs in to one site, they are logged in on all of them. It’s much like when you log in to Facebook, you’re automatically logged in to every site that uses Facebook comments. The same goes for user profiles. If you have a gaming-focused site, a recipes-focused site, and a DIY-focused site, one user will not be able to customize their profile for each site. It’s one single profile page, shared amongst the three.

This also applies to themes. If you tweak the files of one theme for one of your sites, any other site that uses that theme is also going to change. If you wanted the two sites to look and feel different, you would need to fork the theme and keep the old version as well.

Multisite WordPress

This means, to use a black hat example, you can’t use Multisite for a private blog network and keep it hidden. Running your blog network and your money blog on the same Multisite is really transparent. All someone would need to do is register for your main site and then visit the filler sites to see if their login is active.

This happens on WordPress.com as well; some high profile WordPress.com VIP customers have their own domains and everything, but someone with WordPress.com login information can just log in and see their dashboard. It’s not a security loophole, it doesn’t give them any special access, it’s just impossible to hide the fact that it’s on a Multisite installation.

Multisite also has some features that are, well, a little difficult to use. It’s less like their features, and more like workarounds to get functionality you want. For example:

  • It’s difficult to share content from one site to another without all of the usual duplicate content issues that crop up. Same with menus.
  • It’s impossible to remove the /blog/ bit from the URL of sub-sites.
  • It’s a complex chore to restrict the availability and access of plugins from one site. For example, if you wanted a particular drop-down social sharing bar on every site except one, removing it from that one is difficult.
  • It’s also very difficult to create special user roles. Making a limited editor role or a superuser with visibility but no access is simple on a normal WordPress site, but with Multisite it becomes a chore.
  • This is exacerbated by wanting those roles to be limited to one site. It’s either very tricky or impossible to have a user with editor permissions on one site but only user permissions on the rest.

Finally, it’s very tricky to try to move or migrate an entire multisite from one web host to another. It’s even worse if you’re trying to separate out one site and leave the rest intact. Multisite is designed to be “multiple separate sites” but with some shared benefits. Not one site shared across multiple domains.

One thing to note here; while plugin and software infrastructure is shared with a Multisite, configuration and individual settings are not. This is where the “multiple separate sites” issue comes in. You can’t manage user permissions across all sites, or set up custom functionality for each site in a different way, with a single root location. It’s not scalable, it’s not expandable, and it’s not time-saving.

The biggest problem with Multisite is actually user perception of it. People see a system with a handful of features they want and a bunch of features that, while they could use them, are very difficult to implement. Rather than investigate other means of accomplishing the same goals, they decide to go for the complications, and that causes issues.

Multisite is bad for, for example, web hosts. Someone like HostGator isn’t going to be able to use Multisite to manage the blogs of all of their clients. That’s just asking for trouble when someone wants to migrate, someone wants a feature that shouldn’t be available to other blogs, or people want more custom options. Multisite is for you running multiple sites, not for you allowing multiple people to run their own sites.

Reasons to Avoid Multisite

There are enough issues with Multisite that it’s a perfectly valid idea to avoid it. I’ll discuss an alternative momentarily, but first I’ll summarize Mika Epstein’s reasons to avoid Multisite.

  • When the feature you want is a feature WordPress does, or that a basic plugin can do, using Multisite is overkill and places severe restrictions on your site in exchange.
  • If you want all of your sites to look the same, Multisite looks ideal, but the features used for a Multisite are very restrictive and make it difficult to branch out later, whereas plugins and custom post options are much easier to manage.
  • If you want admins of individual sites to be restricted from making changes on that site, Multisite doesn’t give that power. Well, it does, but it takes a ton of setup time and permission management. Multisite is not a replacement for a lack of trust.
  • It’s very, very difficult to keep sites separate in terms of user data. This ranges from user profiles to shared logins. It’s actually impossible to have individual user profiles on each site.

There are more, of course, but for now I’ll move on. Since you’re now thoroughly convinced that Multisite isn’t the best option for running a blog network, let’s look at something that might be; ManageWP.

What is ManageWP

Let me first just put this out here. WordPress Multisite is not designed for you as a user looking to manage a network of blogs. It was designed for WordPress to manage WordPress.com and was included as a feature almost as an afterthought. Some big sites like EduBlogs have taken advantage of it the way it was intended.

ManageWP

Everything that you think makes Multisite ideal, everything that you want it to do, is something that ManageWP was designed to be able to do. It’s specifically designed, not for WordPress’ internal use, but for your use as a consumer and customer of WordPress.

The first thing to know about ManageWP is that it takes all of your disparate WordPress sites and consolidates them into one single unified dashboard. It’s fairly intuitive in function, with a top tabs list and a sidebar with more tabs and nested options. If you’ve ever used a dashboard for a complex web app, you know the basic layout well enough. It’s not difficult to find most common tasks and options you want to set.

From that dashboard you have access to updating plugins and software, back up site content and structure, and even run security scans. Pretty much everything you could want to do to a WordPress install, you can do from this dashboard. It also has the Multisite convenience of updating plugins across each site with one click. It’s not one piece of software, though, it just performs the same set of update tasks on each site automatically.

ManageWP also comes with some popular plugin functionality tied in to its core software. One of the big ones is site backups. You can schedule these automatically and, what’s more, you can set them to back up to a cloud location, like Amazon S3, Google Drive, or even Email. This also enables very easy site cloning, so you can copy a site for testing or as the basis for a new spinoff site incredibly easily.

Backups ManageWP

Now, there’s one downside to using ManageWP, and that’s the fact that it’s not a free piece of software. It works on a freemium model, and the price scales to the number of sites and the purpose you want for those sites.

  • Standard is a plan for individual bloggers running several sites. It comes with the one-click update function, the central dashboard, and most of the convenience features. It also costs 80 cents per website per month. Managing five websites? That’s $4 a month. Very reasonable!
  • Professional is for small businesses, marketers, web developers and other mid-scale professionals. It includes all the normal features, plus scheduled backups, the clone wizard, some analytics and Google Analytics integration. It’s more expensive though, at $2.40 per site per month. Those same five sites would cost you $12 per month here.
  • Business is for large companies, typically those managing a lot of marketing or SEO clients, and usually those companies managing a huge volume of sites. It’s not quite as scalable as WordPress.com, you’re not going to make a million-blog network, but it comes with Yoast-like SEO analysis and white label functionality on the dashboard, among other perks. It’s $4.80 per site per month, so 5 sites is $24 monthly, but chances are at this tier you’re rolling more like 50 sites. Or maybe not! Who am I to say?

They do offer price discounts if you bill annually or biennially, getting free months for each system. They also scale the cost downwards when you manage more sites, under the assumption that their system is going to be more indispensible and this harder to move away from, so you’ll be a long term client. For example, at 500 sites, the business plan is only 84 cents per site per month. Of course, at 500 sites, that’s $420 a month.

ManageWP Pricing

Another thing to note is that by “website” they mean “domain.” If you’re running five sites, but they’re all subfolders on www.example.com, that only counts as one site as far as their program is concerned.

ManageWP’s main benefit is all of the holes that Multisite misses. Say you want to have five sites, each with a different theme; okay, you can do that with both. What if you then want, say, a different analytics suite for one of those sites? You would have to install both, but somehow disable one of them on four sites and the other one on the fifth. With ManageWP, each install is separate, so your plugins are individually installed and monitored. ManageWP just allows quick and easy updating from one central location.

The same can be said for user permissions and account information. ManageWP keeps each of these sites separate in every sense except from the dashboard management perspective. Your users all have their own accounts. They can’t log on to site A and be also logged on to site B. The flip side to this is that you can have someone who is an admin on sites A and B, but is only a normal user on site C and an editor on site D. They will have to manage their own logins, but that’s a small price to pay for all of the segmentation you’re allowed.

How do They Stack Up?

Here’s the interesting thing; the two systems are not mutually exclusive. You can create a Multisite, or even several Multisites, and manage all of them through the ManageWP system. However, this is very strongly Not Recommended. Multisite is complicated and tricky enough to get working, and trying to manage several Multisites through a third party dashboard just further complicates everything.

Honestly, there is a niche for Multisites, but it’s very, very niche. It’s really only good for when you’re trying to run a network of blogs like Edublogs.

If you’re a developer looking to manage sites for numerous clients with disparate requirements, or if you’re one blogger looking to run several joined but complimentary – and different – blogs, you’re going to want to have stand-alone blogs managed from a central dashboard like ManageWP. ManageWP might cost a little money, but honestly the price is so low it’s barely worth talking about. In most cases at low scale it’s cheaper than a Netflix subscription, so how can you go wrong?

Written by James Parsons

James Parsons

James is a content marketing and SEO professional who enjoys the challenge of driving sales through blogging while creating awesome and useful content.

Comments

  1. Sudhir Gupta says:

    my site goes too slow when i login wp-admin after multisite. i hate this

  2. David William says:

    Thanks for the excellent guide James. I have a bunch of WordPress websites and thinking to switch to WordPress multisite.
    I read an article titled about how the security of one site can jeopradise the entire multisite network.

    I’m a bit confused, what if one of my sites got hacked, will it reflect all the subsites or not?
    How about the DDoS on a single site?

    Looking forward to your response, if everything goes well, I will be switching to WPMU in a month.

    • admin admin says:

      Hey David! Interesting question.

      It all depends if the sites each have their own cPanel, or if they share one.
      Also, whether or not they are all on the same box, or different servers.

      If they are all on the same cPanel and one of the sites gets hacked, they are potentially all at risk.
      If they are on different cPanels, they are generally protected, and only the site that gets hacked is affected (unless the other sites have the same vulnerability and are discovered).

      If they are all on the same server and you get DDoSed, all sites will go down.
      If they are on different servers, the other sites will not be affected, unless they are targeted by seperate DDoS attacks.

      It’s always smart to have your sites on different cPanels, but not everyone can afford to have seperate (quality) hosting for each site. If you’re worried about DDoS attacks and they are a credible threat to you, check out Cloudflare, hire an expert to harden your dedicated server firewall, and consider investing in a hardware firewall for bad DDoS attacks.

      I don’t know how large your sites are and if you are DDoSed frequently, so this might be overkill for you – usually Cloudflare blocks most “script kiddies” that like to play around with DDoS attacks.

Leave a reply

Share62
Tweet
Pin
Buffer
62 Shares