Is WordPress Multisite One Theme or Multiple? How Themes Actually Work Across a Network

A WordPress multisite network has one shared themes directory on disk, and each site in the network activates its own theme from what the network administrator has made available. So the answer is both: one set of installed themes, many independently chosen active ones.

That split is the source of most multisite confusion, because it means theme decisions happen at two levels. The network admin controls what exists; individual site admins control what is used. Understanding which level you are operating at explains most of the behaviour people find surprising.

Table of contents

• The two levels of control
• Customising a shared theme per site
• What is actually shared and what is not
• When multisite is the wrong choice
• Subdomains or subdirectories
• Keeping a network maintainable
• How this fits the rest of the stack
• FAQ

The two levels of control

Themes in a multisite network live in one wp-content/themes directory shared by every site. There is no per-site theme directory and no way to install a theme for one site only.

What varies is availability and activation:

• Network Enable makes a theme available to every site in the network. Site admins can then activate it.
• Per-site enabling, from a site’s own Themes screen in Network Admin, makes a theme available to that one site.
• Activation is always per site. A site admin picks from what has been made available to them.

By default, site administrators in a network cannot install themes at all — only the network administrator can. That is intentional and it is one of the main reasons to use multisite: it centralises the thing most likely to break a site.

The practical consequence: a network of fifty sites can run fifty different themes, or all fifty can run the same one. The architecture does not push you either way.

Customising a shared theme per site

Since the theme files are shared, editing them affects every site using that theme. The mechanisms for per-site variation:

1. Customiser settings and theme options. Stored per site in that site’s options table. Colours, logos, and layout choices vary freely without touching files. This covers most of what people want.
2. A child theme per site. Install several child themes of one parent; each site activates its own. This is the right answer for genuine template differences and it scales badly past a handful — each child theme is a separate thing to maintain.
3. Conditional logic in the theme, using get_current_blog_id() to branch. Powerful and it turns your theme into a place where every site’s special cases accumulate. Use sparingly.

The ordering matters. Reach for options first, child themes when the structure genuinely differs, and conditionals only when neither works. A theme full of blog-id conditionals becomes unmaintainable faster than you expect.

What is actually shared and what is not

This is the part worth internalising, because it explains most multisite behaviour.

Shared across the network:

• The WordPress core installation — one copy, one version, updated once.
• The themes and plugins directories on disk.
• The uploads directory root, though each site gets its own subdirectory.
• The users table. A user account exists network-wide and is granted roles per site.

Separate per site:

• Its own set of database tables, prefixed with the site id.
• Its own posts, pages, comments, categories, and settings.
• Its own active theme and active plugins.
• Its own upload subdirectory.

The single shared core is the main operational argument for multisite: updating fifty sites is one update. It is also the main risk, because a core update that breaks something breaks fifty sites at once.

When multisite is the wrong choice

Multisite is frequently reached for when separate installations would be simpler. The cases where it is wrong:

• Sites with genuinely different plugin needs. Shared plugin files with per-site activation sounds fine until two sites need different versions of the same plugin, which is impossible.
• Sites owned by different clients. Any network admin can access every site. A compromised network admin account is a compromise of everything.
• Sites with very different traffic profiles. They share resources. One site getting popular affects all of them.
• Sites you might sell or hand over. Extracting one site from a multisite network is a genuinely unpleasant migration involving table surgery.

That last point deserves weight. Setting up multisite is easy; leaving it is not. If there is a reasonable chance a site will need to move out, starting it separately costs almost nothing and saves a difficult migration.

The good cases are narrower than the marketing suggests: sites that genuinely belong to one organisation, share a user base, and should be updated together. A company with regional sites, a university with department sites, a publisher with several titles.

Subdomains or subdirectories

You choose this at network setup and changing it later is painful, so it is worth a moment.

Subdomains — site1.example.com. Needs a wildcard DNS record and a wildcard TLS certificate. Each site feels like a separate property, which is right when they genuinely are.

Subdirectories — example.com/site1. No DNS work, no extra certificate, and everything sits under one domain’s authority.

Two practical notes. First, the wildcard certificate for a subdomain network covers exactly one level, which is fine here since sites are always one level deep. Second, a subdomain network with a parent-scoped cookie means every site can read it, so if the sites belong to different parties, subdirectories are not safer — the sites share a database and a filesystem either way.

For most networks subdirectories are less work. Subdomains earn their place when sites need to feel independent or may later move to their own domains, which multisite supports via domain mapping.

Keeping a network maintainable

Three habits that make the difference between a network that ages well and one that becomes untouchable:

1. Keep the theme count low. Every network-enabled theme is a thing to update and test against every core release. A network with three themes is manageable; one with thirty is a liability.
2. Test updates on a staging copy of the network. The shared-core property means one bad update takes every site down simultaneously. This is the single most valuable practice for a multisite.
3. Know how to extract a site before you need to. The process — exporting the site’s tables, remapping ids, moving the uploads subdirectory — is much less stressful as a rehearsed procedure than as an emergency.

The through-line is that multisite trades per-site independence for centralised maintenance. That trade is good when the sites really are one thing, and it gets worse the more the sites diverge.

How this fits the rest of the stack

The core trade in multisite is that one shared installation makes routine maintenance cheap and makes every failure network-wide, which puts a lot of weight on being able to test a change before it lands and undo it after. Managed WordPress on RunxBuild includes a dashboard file manager and database browser, so inspecting which tables belong to which site does not start with finding phpMyAdmin credentials, and plans start at $3 a month. If you are working out what a set of sites costs alongside their database and bandwidth, the RunxBuild hosting calculator itemises it.

Useful related references:

• Deploy WordPress for Free on RunxBuild
• WordPress Self-Hosting: LAMP, Docker, or Managed RunxBuild
• WordPress VIP: When the Enterprise WordPress Hosting Tier Makes Sense
• Database network security on RunxBuild

FAQ

Can each site in a multisite network use a different theme?

Yes. The themes directory is shared across the network, but each site activates its own theme from the ones the network administrator has made available. Fifty sites can run fifty different themes.

Can site admins install their own themes in multisite?

No, not by default. Only the network administrator can install themes and plugins. Site administrators choose from what has been network-enabled or enabled specifically for their site.

How do I customise one site without affecting others?

Use theme options and Customiser settings, which are stored per site. For structural differences, create a child theme per site. Conditional logic on get_current_blog_id() works but accumulates into an unmaintainable theme.

Should I use subdomains or subdirectories for multisite?

Subdirectories are less work — no wildcard DNS record and no wildcard certificate. Choose subdomains when sites need to feel independent or may later move to their own domains via domain mapping. Changing this later is painful.

Can I move one site out of a multisite network?

Yes, but it is an unpleasant migration involving exporting that site’s prefixed tables, remapping ids, and moving its uploads subdirectory. If a site is likely to need moving, keeping it as a separate installation from the start is much cheaper.