WordPress Multisite — what I like to referred to as Monster Sites — is an often misunderstood creature. Most developer attempts at explaining the purpose of this configuration do not go beyond the knowledge of how to install and administrate it, while other developers explain Multisite from the perspective of misuse, documenting plenty of reasons to avoid it. This has left a gap in understanding of just what WordPress Multisite “should” be used for. Often, this gap is filled with experiments that ignore the advice of those who warned them to stay away. But only by testing the limits of what Multisites can become, do they learn why “monster” is an appropriate label.

Here be Monsters

In the autopsy of many Monster Sites, you tend to discover that your site was the victim of one of three beastly scenarios:

The Great White Vortex

The Great White Vortex appears when you keep adding and adding and adding sub-sites to your multisite instance until it becomes so unmanageable that you are crushed (or chewed-up) under its own administrative and vast content weight. Despite the potential latency issues from this behemoth, these sites can become shipwrecks that retain outdated branding, orphaned pages, and stale content.

Avoiding the Great White Vortex: Nets, Harpoons, and Canons

This Monster Site scenario starts off with trying to apply Single Site thinking to Multisite complexity. At no point does the site owner seem to account for the long-term use of the site, nor what complications can arise once the site reaches its monstrous size.

Over time, the Great White Vortex scenario appears when no proper planning or preparation went into managing how scaling would impact the site. The constant multisite additions create fully functioning Single Sites within the Monster Site. This means that the theme has to be created, content has to be managed, and changes have to be administered. An installation without a Captain to watch over it can be a disaster waiting to happen. The more sub-domains added to the multisite network, the more content requiring management. If the network has only one or two administrators trying to control dozens, or even hundreds of sites, they will quickly be torn apart by the feeding frenzy even one change per site, per day, could cause.

To avoid creating the Great White Vortex on your site, you need to first understand how many sites one admin can control and remain productive. I like to use Blackjack’s Number (or the Rule of 21). One administrator and/or content wrangler per twenty-one (21) sites. Why 21? A typical website administrator works an 9-hour day (8-hours of work plus a 1-hour lunch). One hour is taken up by socializing, catching up on emails, and day-to-day stuff. This leaves 7-hours to perform site changes at a rate of roughly 3-sites per hour, or 21-sites in a day. This equation can be altered depending on your admin’s skills and experience level, but it starts the process of getting you to think about how many admin’s will you need to manage a large network of sites, BEFORE you start adding sites.

So what do you do if you are already caught in the Great White Vortex? The first thing you should do is get your resources in check. If you cannot reduce your administration down to at least 21-sites each, you need to start prioritizing content management. This can be done by creating a list of your sub-sites, organizing them into equal groups, assigning each group to a certain day of the week, and then allowing your admin’s to conduct changes only on the day the group is scheduled. This will greatly reduce the chaos your admin’s will have in figuring out which sites received updates on which days and when. You can further reduce this by auditing each sub-site to find out if there are sites that do not update as frequently, or sites that are no longer needed due to lack of interest.

Monster Hunting Tips:

  • Plan out the use of your site to include growth and how that growth will impact content management over a time.
  • Try not to overwhelm a single administrator and/or content wrangler by limiting them to 21-sites or less.
  • In large networks, prioritize sites into groups that can become part of a weekly update schedule, and remove dead sites whenever possible.

The Hydra Divergence

The Hydra Divergence appears when you want to separate your multisite into two smaller multisite instances, or you want to pluck a single site out from the multisite to create an independent Single Site. Only when you attempt to do this, the complexity is so great for the average user that you end up spending more time extracting the site then it would have taken to recreate the site from scratch.

Avoiding the Hydra Divergence: When to Fish or Cut Bait

Expanding on my sea monster analogy, I like the think of WordPress Single Sites as fish. They swim, eat, and live a simple life, and much like most single installations, they have plenty of other fish — or schools of fish — to swim with. There is an oceans-worth of WordPress Single Site support, examples, hacks, plugins, themes, and knowledge floating across the Internet. This is why managing separate installations of single WordPress instances makes perfect sense if your ocean consists of just one fish site, or a small school of fish sites. Even if each site has a different purposes, function, and goal, single WordPress installations are easy to manage, troubleshoot, and keep alive. No matter where you sail, you can find someone who can help you fish.

The Hydra (cut one head off, two grow in its place) Divergence scenario appears, however, when you use WordPress Multisite to create that same ecosystem of fish sites only as sub-domains within your multisite network. These sites may never exist as their own little fish sites, but if there is a possibility that they might, you have just started mutating your network into a new monster. The migration of fish sites from within the monster is not a simple task. The Monster Sites that can use the Hydra to some advantage are those that develop demonstration sites, or use multisite to experiment with new theme designs. These configurations can exist as a multitude of sub-domains and one-off installations. They will most likely be switched off and turned into chum at some point, never needing attention beyond their brief usefulness. But if you know that a site will eventually need to be removed from your multisite network, you are better off creating a Single Site fish. For once it has become one of the many heads of the monster, cutting it off is somewhat of a Herculean feat.

So what do you do if you really need to remove a site from the Hydra Divergence? The first thing you should always do is make a back up of everything, including the database. Anytime you attempt a migration, you should make a clean backup to save you from scuttling your site on the rocks of a mistake. Fortunately, the good news is that WordPress Multisite (just like in WordPress Single Site) has a built in export function for packaging up site-specific content so that you can import it into a new installation. However, the bad news is it will not maintain any of your plugin or theme settings. For some themes, this is not a problem, but with others that include complex animations, it could take some time to recreate.

Additionally, the domain name that your site was mapped to within multisite is important to how your site is configured in the database. If you are keeping the same domain name, but only removing the sites from multisite, then the new Single Site installation should take your content import without issue. Unfortunately, if you are changing domain names, you will need to fix the domain name reference in your content before it will work again. The main point is to know what domain name you want first. The final step is moving code out of your Monster Site and into your new Single Site. Ideally, you want to copy the folders titled plugins into plugins, themes into themes, and the sub-folder within uploads that identifies your sub-site (e.g. ./uploads/sites/2/) into uploads. Once you have the new site working properly within its Single Site fish bowl, only then should you switch off the sub-site within your Monster.

Monster Hunting Tips:

  • Do not create Multisite sub-sites that you plan on migrating to Single Site sometime in the future.
  • Plan out your migration before you actually move anything and always make a backup of everything before you begin.
  • Always build out the Single Site before you switch off the sub-site within your Monster.

The Giant Squid Incursion

Despite the advantages a single code-base can provide you, a main disadvantage of multisite is its vulnerability to providing a successful hacker complete access to the entire multisite network for a single point-of-entry. A single, corrupt partition or database table, can also lead to a death of all the websites within your network.

Avoiding The Giant Squid Incursion: Safe Harbors Save Boats

The Giant Squid Incursion is difficult to escape once it has you in its clutches. A website hack or hardware failure is something you usually find out about after it happens. By then it’s too late to act, and all you can do is pick up the pieces and start over. But you can be proactive in keeping your multisite from getting destroyed. The first level of defense you can employ is hardening your WordPress administration login form with plugins that limit the number of failed login attempts (Login Lockdown), require two-factor authentication (Rubion), and/or block anyone coming to your site from a specific block of IP address (those known to be used by hackers) (BruteForce). Another technique is to require your administration pages to all use your server’s Secure Socket Layer (SSL) certificate. This way all passwords and user names are not sent in clear text, but are instead encrypted, making it harder for hackers to intercept.

Above all, the only true way to stop your website from being broadsided by hackers or Mr. Murphy of Murphy’s Law fame, is to make backups early and often. Nothing thwarts a successful hack like a fresh install from a weekly (or daily) backup! It is possible to even set your server to automatically backup your Monster Site so that you don’t have to. But always have a backup handy, especially when your multisite network begins to increase in size. There is no greater tragedy then to have a massive site go down only to find out that it was never backed up. Sites that sink like that, are rarely seen from again!

Monster Hunting Tips:

  • Understand that a multisite installation is vulnerable from a single point-of-entry.
  • You must harden your administration login account by reinforcing the gates through encryption, limiting login attempts, enforcing two-factor authentication, and blocking bad IP addresses from visiting.
  • Always backup. Backup early and often. Never be without a recent copy: the life you save could be your’s.

The Rhyme of the Ancient Monster Whisperer

There are many more strange creatures lurking within WordPress Multisites that can ruin your networks day. But if you consider how you will tackle the most mammoth problems using the strategies detailed above, you are well on your way to avoiding having your WordPress multisite devoured by the Monster Site it can become. Ultimately, my hope is that by approaching Multisite with a strategic eye on the long-term issues that can surface over time, you can tame your Monster Site before you have to deep-six it and start over.