WordPress Multisite: A Practical Guide to Networks

What WordPress Multisite Is

WordPress Multisite is a feature that ships inside every copy of WordPress but sits switched off until you turn it on. Once enabled, a single WordPress installation can run many separate sites, called a network. Each site has its own content, its own settings, and its own address, and can have its own theme and look, yet all of them run on the same core files and share one database. You are not installing WordPress many times. You are installing it once and letting it host many sites.

The value of that arrangement is maintenance in one place. When a security update for WordPress comes out, you apply it once and every site in the network is updated. When you update a shared plugin or theme, the same is true. For someone managing dozens of related sites, that is a large saving compared with logging into dozens of separate installations and updating each by hand. One update, one backup routine, one set of files to care for, many sites served.

It is worth being clear about what is shared and what is not, because that boundary explains most of multisite's behaviour. Shared across the network are the WordPress core files, the pool of installed plugins and themes, and a single database, along with a network administrator who oversees the whole thing. Kept separate per site are the content, the active theme and settings, and the address. So the sites feel independent to visitors and to their own admins, while underneath they lean on one shared foundation.

That shared foundation is both the strength and the catch. It is why maintenance is efficient, and it is also why the sites are tied together in ways that matter, especially for backups, restoring, moving sites, and security. Keep that dual nature in mind as we go, because nearly every trade off in this guide comes back to it.

Read that diagram from the top down and the whole model makes sense. You maintain the box at the top once, and the benefit flows to every site below it. But the sites below are joined at that top box, so what happens to the shared installation happens, in some measure, to all of them. Hold that picture and the rest of this guide follows naturally.

Who Multisite Is For, and Who Should Avoid It

Multisite is a specialist tool. It is excellent for some situations and a poor fit for others, and knowing which you are in before you enable it saves a great deal of trouble. The deciding question is simple: are these sites genuinely related and managed by one team, or are they independent sites that happen to be yours?

Multisite fits well when the sites belong together and share a manager. A company with regional or departmental sites that should look and behave alike. A university with sites for many faculties under one team. A chain of locations each wanting its own page under a shared brand. A network of blogs on one platform. A business that spins up similar sites often and wants them all built from the same shared setup. In all of these, the shared foundation is a benefit, because you want consistency and central control, and the sites are not going to wander off on their own.

Multisite is a poor fit when the sites are independent and might need to go their separate ways. Unrelated client sites that each belong to a different business. Sites that will grow very differently in traffic or need. Anything where one site might need to be sold, moved, or handed to someone else later. In these cases the ties that make multisite efficient become ties that hold you back, because separating a site from a network is real work, and a problem in the shared installation touches everyone.

If you are unsure, lean toward separate installations. Multisite is harder to leave than to join, and the efficiency it offers is only worth the added complexity when you genuinely have many related sites to run. Building one or two sites is not a reason to enable a network.

Subdomains vs Subdirectories

When you enable multisite, WordPress asks you to choose how the sites in the network will be addressed, and this is a decision you make once. The two options are subdomains and subdirectories, and while both work equally well technically, they read very differently and changing your mind later is difficult, so choose deliberately.

Subdomains give each site an address like store.example.com or toronto.example.com. The site name sits in front of the main domain. This suits networks where each site feels like its own distinct thing, a separate brand, a separate location, an independent blog, because a subdomain reads as a place of its own. Subdomains do require a small piece of server setup, a wildcard arrangement so that any subdomain points to the installation, which good hosts handle without fuss.

Subdirectories give each site an address like example.com/store or example.com/toronto. The site name sits after the main domain, as a folder would. This suits sites that clearly belong to one parent, sections of a larger whole, regional pages under a single company, departments under one organisation, because a subdirectory reads as part of the main site rather than a separate one.

Neither is better in the abstract. Pick based on how the sites relate and how you want their addresses to read to visitors and search engines. If each site is its own identity, subdomains. If they are parts of one whole, subdirectories. Because switching afterwards is a serious undertaking, it is worth a moment to picture the addresses you will still be happy with in a year.

How to Enable Multisite

Turning on multisite is a configuration change, not an installation, and it is a change you should never make directly on a live site without a backup and, ideally, a test run first. If the site already exists and matters, do this on a staging copy and confirm everything works before repeating it on the live site. The steps below are the shape of the process rather than exact commands, because the details vary by host and version and you should follow the current official instructions as you go.

At a high level, enabling multisite involves three moves. First, you add a line to the site's main configuration file that tells WordPress to make the network feature available. After that, a new Network Setup screen appears in the admin tools, where you choose subdomains or subdirectories and confirm the network's basic details. Second, WordPress gives you a couple of blocks of configuration to paste in: more lines for that same configuration file, and rules for the server's configuration file that handle how addresses are routed to the right site. Third, you log back in, and the installation is now a network with your first site in it, plus a new Network Admin area for managing the whole thing.

A few cautions make this go smoothly. Take a full backup before you start, because you are changing core configuration. Make sure you can edit the configuration files, which means having access to the site's files through your host. Choose subdomains or subdirectories carefully, since this is the point of no easy return. And expect to log out and back in during the process, which is normal. If any of this feels beyond your comfort, that is a fair signal to get help, because a half enabled network is an unpleasant thing to untangle. The official WordPress network setup documentation is the authoritative reference for the exact steps on your version.

The Network Admin

Once multisite is on, a new layer of control appears: the Network Admin. This is the command centre for the whole network, and it introduces a role above the ordinary site administrator, the network administrator, sometimes called the super admin. Understanding this split is key to running a network well.

A network administrator oversees everything: they create and delete sites, install and manage the plugins and themes available across the network, control network wide settings, manage all users, and handle updates for the shared installation. This is a powerful role, effectively in charge of the entire installation and every site on it, which is why you keep the number of network admins very small and trusted.

A site administrator, by contrast, runs a single site within the network. They can manage their site's content, choose from the themes made available to them, activate the plugins allowed for their site, and adjust their site's settings. What they cannot do is install new plugins or themes into the network, create new sites, or touch the shared installation. That boundary is deliberate. It lets many people run their own sites without any one of them being able to affect the whole network.

In practice this means the network admin sets the boundaries, which plugins and themes exist, which settings apply everywhere, while site admins work within them. Getting this division right is most of what running a healthy network is about. Too many network admins and the shared system is exposed to too many hands. Too tight a leash on site admins and they cannot do their jobs. The Network Admin area is where you tune that balance.

Adding Sites to the Network

Adding a site to a running network is one of the pleasures of multisite, because it is fast. From the Network Admin, you create a new site by giving it an address, whichever subdomain or subdirectory it will live at, a title, and an administrator. Within moments a fully working WordPress site exists, ready for content, drawing on the network's shared plugins and themes.

That speed is the whole point for organisations that create similar sites often. There is no separate installation, no new database to set up, no fresh copy of WordPress to configure. The new site inherits the network's foundation and starts from a known state. If you have prepared the network with the right themes and plugins available, a new site can be up and consistent with its siblings almost immediately.

A useful practice is to decide, up front, what a new site should start with, which theme, which plugins active, which basic settings, so that every site added to the network begins life consistent with the rest rather than being configured from scratch each time. Some teams keep a template or a documented checklist so new sites are uniform. The more alike your network sites are meant to be, the more this consistency at creation pays off, and the less ongoing correction you do later.

You also manage the lifecycle of sites here. Sites can be deactivated, archived, or deleted from the Network Admin, and you can move between them to administer each. For a network of any size, spending a little time organising how sites are created and kept consistent turns multisite's speed into genuine efficiency rather than a pile of slightly different sites that are hard to maintain.

Plugins and Themes on a Network

Plugins and themes behave differently on multisite, and it is one of the first things that surprises people coming from a single site. On a network, only the network admin can install plugins and themes, and there are two ways to make each one available.

A plugin can be network activated, which turns it on for every site in the network at once. This suits foundational plugins that every site should have, a security plugin, a caching plugin, an analytics setup, something core to how all sites work. Network activation means you manage it in one place and every site is covered.

Alternatively, a plugin can be left available but not network activated, so that individual site administrators can choose to activate it on their own site. This suits plugins that only some sites need, a shop plugin for the sites that sell, a gallery plugin for the sites that need one. The network admin decides which plugins exist in the pool, and site admins pick from that pool for their site.

Themes work the same way. A theme must be made available across the network before any site can use it, and the network admin controls that list. A site admin then chooses their active theme from the themes the network has enabled. This keeps the design options controlled while still letting sites look different from one another.

Two cautions matter here. First, not every plugin is written to work correctly on multisite, since a network changes assumptions a plugin might make about there being one site and one set of data. Before you rely on a plugin in a network, confirm it supports multisite, ideally checking its documentation. Second, a network activated plugin runs everywhere, so a flaw in it, or a heavy performance cost, is multiplied across every site at once. That amplification is a good reason to be selective and disciplined about what you activate network wide. If a network needs custom behaviour, that is often better handled by purpose built code than by piling on plugins, something our plugin development work often addresses for networks.

Users Across the Network

User accounts on multisite are shared at the network level, which is a genuinely handy feature and occasionally a confusing one. There is a single pool of users for the whole network, and a person can be a member of one site, several sites, or none, with a different role on each.

The practical upside is that one person can hold a single account and use it across many sites in the network, rather than needing a separate login for each. Someone might be an editor on one site, an author on another, and have no access to a third, all from the same account and password. For an organisation where people work across several related sites, this is a real convenience and removes a lot of duplicate account management.

It also means the network admin manages users at the network level. Adding a user to the network makes the account exist; then that user is given a role on whichever specific sites they should reach. Site admins can add users to their own site, drawing from the shared pool or inviting new ones, but the overall user list belongs to the network. Removing someone from the whole network is different from removing them from one site, and it is worth being clear about which you intend.

The thing to hold in mind is that the shared user system, like everything else in multisite, ties the sites together. It is efficient precisely because it is shared, and it needs the same care that shared things always need: keep the number of high privilege accounts small, remove access for people who leave, and remember that an account on the network is a doorway that may reach more than one site. Good user discipline is part of keeping a network secure, which the next section takes up.

Domain Mapping

By default, every site in a network lives on a subdomain or subdirectory of the main domain. Domain mapping lets you give a network site its own separate domain instead, so a site that is technically part of your network can appear to visitors at its own address, with no sign that it shares an installation with others.

This is what makes multisite viable for networks where each site needs to look fully independent. A site that lives internally at a subdomain of your network can be presented to the world at its own domain, and visitors simply see that domain. Behind the scenes it is still one of your network sites, updated and maintained along with the rest, but its public identity is entirely its own.

The good news is that domain mapping is now built into WordPress core, so it no longer needs a separate plugin the way it once did. The work that remains is mostly on the hosting and domain side: the separate domain has to be pointed at your installation, and your host has to be set up to accept it and route it to the right network site. Once that plumbing is in place, mapping the domain to a site inside WordPress is straightforward.

Where domain mapping tends to get fiddly is exactly that hosting and DNS layer, and it is a common place for people to get stuck, because it touches domain settings, server configuration, and secure certificates for each mapped domain. If you are running a network where several sites need their own domains and their own secure certificates, this is an area where a little experience saves a lot of frustration, and where good hosting that understands multisite makes a real difference. Our guide to the best WordPress hosting covers what to look for, including support for the kind of setup networks need.

Backups and Updates Across a Network

Maintenance is where multisite's shared nature shows both its best and its most awkward sides. Updates are wonderfully efficient. Backups and restoring are where you feel the ties.

Updates are the clearest win. Because the whole network runs on one installation, you update WordPress core, and shared plugins and themes, once, and every site is updated together. For a manager of many sites this is a large saving over updating each site separately. The flip side is that an update affects every site at once, so a problematic update has network wide reach. This makes testing updates before applying them more important on a network than on a single site, ideally on a staging copy of the network, so a bad update does not break every site simultaneously.

Backups capture the whole network together, since there is one set of files and one shared database. That is convenient for protecting everything in one routine, and it means you are far less likely to forget to back up a site, because they are all in one backup. The difficulty comes when you want to restore or move just one site. Because the sites are intertwined in a shared database, pulling one site out of a backup, or restoring one site without touching the others, is genuinely harder than it is with separate installations. A whole network restore is straightforward; a single site restore is not.

This asymmetry is worth planning for. If your sites rarely need individual restores, the shared backup is simply convenient. If you expect to restore or roll back individual sites often, the shared database makes that painful, and it is one of the honest costs of a network. Whatever your situation, keep backups off site and test that you can actually restore from them, because a network backup that has never been tested is a large single point of failure. The care that goes into a network's maintenance routine is a good part of what keeps it healthy over the years.

Performance and Security

Running many sites from one installation has real implications for both speed and safety, and both come back to the same fact: everything is shared, so everything is connected.

On performance, all the network's sites draw on the same server resources and the same database. When traffic is modest and spread out, this is efficient. When one site has a surge, or the network grows large, the sites are competing for the same resources, and the shared database that holds every site's content grows and has to work harder. A busy network needs hosting sized for the whole load, not for one small site, and it benefits from caching and a database kept tidy. Underpowered hosting that would carry one site comfortably can struggle when that same box is running twenty. Plan the hosting for the network you expect, not the one site you start with.

On security, the shared installation concentrates risk. A serious compromise of the installation, or a security flaw in a network activated plugin, can affect every site at once rather than just one, because they all run on the same code. Every network admin has far reaching access, and even site admins share a system. None of this makes multisite insecure, well run networks are secure, but it does mean a single problem has a wider blast radius. That raises the value of the fundamentals: careful plugin choices, a small number of trusted network admins, prompt updates, and solid hosting. Our guide on how to secure a WordPress website applies to networks with extra force, precisely because one weakness can reach everything. The rule of thumb is that a network rewards discipline and punishes neglect more sharply than a single site does.

SEO Across a Network

Search visibility on a network raises questions a single site never faces, because now you have many sites that may share a domain, a design, and a theme. Handled with a little care, a network can rank perfectly well. Handled carelessly, the sites can dilute each other or trip over avoidable problems.

The most important idea is that, to search engines, each site in a network is generally treated as its own site with its own content, whether it lives on a subdomain, a subdirectory, or a mapped domain. That means each site needs the same search fundamentals any site needs: clear titles and descriptions, sensible structure, useful content, and its own sitemap. A network does not earn rankings automatically because a sibling site ranks. Every site has to stand on its own content.

The risk to watch on a network is sameness. When many sites share a theme and are built from the same template, it is easy to end up with near identical pages across sites, the same boilerplate, the same thin about page, the same copied text. Duplicate or barely different content across your own network helps no one and can hold sites back. The fix is to make sure each site has genuinely distinct, useful content of its own rather than a clone of its siblings. If two sites would say the same thing, question whether they should be two sites at all.

A few practical points help. Give each network site its own SEO plugin configuration, so titles, descriptions, and sitemaps are tuned per site rather than left generic. Decide deliberately how mapped domains and subdomains should be indexed, so you are not accidentally exposing a staging or internal address to search engines. And keep an eye on performance, since the shared hosting load discussed above affects speed, and speed affects rankings. Our guide to WordPress Multisite and our broader development notes cover the setup side, and the principle here is simple: treat each site's search presence as its own job, because to search engines, that is exactly what it is.

Migrating a Site Out of a Network

Sooner or later, someone wants to take one site out of a network and run it on its own, because it grew, changed hands, or simply needs independence. This is possible, and it is a known process, but it is more involved than moving a normal site, and that difficulty is one of the strongest reasons to think carefully before choosing multisite in the first place.

The challenge is the shared database. On a standalone site, moving means copying the files and the database to a new home. On a network, one site's content and settings are woven into a database shared with every other site, so extracting a single site means carefully separating out just that site's data, its posts, pages, media, users, and settings, and importing it cleanly into a fresh, standalone WordPress installation. Done carelessly, you either miss data or drag in things that belong to other sites.

Because of that, moving a site out of a network is a task to approach methodically: set up the new standalone installation, export the one site's content and media, bring across its users and settings, check that links and media point to the new home rather than the old network address, and test thoroughly before switching the domain over. It is the kind of job where a small mistake shows up as broken images or missing content that is annoying to chase down afterward.

The takeaway is not that you can never leave a network, you can, but that leaving costs effort, so the choice to join one should account for it. If there is a real chance a site will need to stand on its own later, starting it as a standalone site avoids the extraction entirely. We handle these separations as part of our migration work, and if you are facing one, our development team can pull a site out of a network cleanly.

Alternatives to Multisite

Multisite is not the only way to run several sites, and often it is not the best way. Before enabling a network, it is worth weighing the alternatives, because for many people who think they need multisite, something simpler serves better.

Separate installations. The plainest alternative is simply running each site as its own WordPress installation. Yes, you maintain each one separately, which is more update work. But each site is fully independent: it can be moved, sold, or changed without affecting the others, a problem on one never touches the rest, and there is no shared database to complicate backups and restores. For a handful of unrelated sites, separate installations are usually the calmer choice, and modern management tools can update many separate sites from one dashboard, softening the main downside.

Management dashboards. If your main reason for wanting multisite is updating many sites in one place, a management service that connects to your separate installations gives you much of that convenience, updates, backups, and monitoring across many sites from one screen, without tying the sites together in a shared installation. You get central maintenance while keeping each site independent.

A single site with sections. Sometimes what looks like a need for several sites is really one site with distinct sections. If the content is related and lives under one brand, categories, custom content types, or a well organised single site may do everything you wanted, with none of multisite's complexity. Do not build a network to solve what a good site structure handles.

The honest guidance is to choose multisite only when you genuinely have many related sites that benefit from a shared foundation and central control. If you are reaching for it to solve a maintenance chore or to organise content, one of these alternatives is very likely the better fit, and it will save you the complexity a network carries for its whole life.

When to Get Help

Enabling a basic network and adding a few sites is within reach of a confident WordPress user who follows the official steps carefully and works on a backup first. If your situation is simple and you are comfortable editing configuration files, you can set one up yourself.

There are clear points where help is worth it, though. The decision itself, whether multisite even fits your project or whether separate sites would serve you better, is worth a second opinion before you commit, because it is easier to choose right than to unwind later. Enabling multisite on an existing live site, mapping several custom domains with their own secure certificates, sizing and tuning hosting for a busy network, hardening a network against the wider risk it carries, and extracting a site out of a network are all tasks where experience prevents expensive mistakes. A network touches configuration, hosting, DNS, security, and a shared database all at once, and problems in that mix can affect every site you run.

We plan, build, and maintain WordPress networks, and we also advise honestly when a network is the wrong tool and something simpler will serve you better. We can enable and configure multisite safely, set up domain mapping and hosting properly, keep a network updated and secure over time, and cleanly separate a site when one needs to leave the network. Because we are developers, we can handle the parts that live below what plugins reach, from custom network behaviour to the trickier migrations.

If you are weighing a network or already running one that needs attention, you can get a free quote and we will look at your situation and give you a straight answer, or book a free consultation and we will talk it through with no obligation. Getting the decision right early is the cheapest it will ever be.