Scaling WordPress Multisite in 2026 - Managing 100+ Websites

Managing a handful of websites is easy. Managing 100+ websites for a global group or a franchise network is a logistical problem, unless you use the right architecture. In 2026, WordPress Multisite remains the built-in way to run a large fleet of sites from one WordPress installation.

Here is how to architect, govern, and scale a 100-site network.

Short answer: WordPress Multisite still works very well in 2026 when you need centralised control, shared code, and consistent governance across many sites. It becomes the wrong choice when you need hard data isolation, radically different infrastructure per site, or full autonomy for every team.

Learn more about enterprise WordPress development at WPPoland.

#Updating 100 WordPress sites from one codebase

The primary advantage of Multisite is having one core codebase to manage. Everything else in this guide builds on that.

#Centralized updates

When a security patch is released, you update it once at the network level, and the new code is live for all 100 sites at the same moment. With 100 separate installations the same patch means 100 update runs, and every site that waits stays exposed for longer.

One detail matters at this scale: a core update can also change the database schema. The code is shared, but every site has its own tables, so after a core update WordPress asks you to run Upgrade Network. The Network Admin handbook describes it this way: the Upgrade Network feature “will step through each site, five at a time, and make sure any database changes are applied”. Deactivated sites are skipped and get their update when an admin of that site logs in after reactivation.

#Shared library

Themes and plugins are shared. If you want to update the corporate brand colors, you modify one theme and it reflects across all regional sites that use it.

Managing shared assets:

• Corporate theme: one parent theme, with per-brand variations as child themes
• Core plugins: SEO, security, cache and analytics installed once by the Super Admin
• Must-use plugins: files in mu-plugins load on every site and cannot be deactivated per site

#Brand consistency and its limit

Fonts, colors and spacing defined in the theme’s theme.json apply to every site that uses the theme. The limit is the database: the handbook notes that “Style changes made in the Site Editor affect only individual sites”, because they are stored in that site’s tables. If brand consistency matters, keep the design system in theme files under version control and restrict who can edit styles in the Site Editor.

#How to create a WordPress Multisite network

The official procedure is short, and the Create a Network guide sets the order:

1. Back up the database and files, verify that pretty permalinks work and deactivate all active plugins.
2. If WordPress runs from its own directory, set that up before activating Multisite.
3. Add define( 'WP_ALLOW_MULTISITE', true ); to wp-config.php above the line that ends editing. This enables Tools > Network Setup.
4. On the Network Setup screen choose sub-domains or sub-directories and install.
5. Add the lines WordPress generates to wp-config.php and .htaccess, then log in again.

The network administration handbook adds a point that saves time on modern stacks: WordPress can generate Apache and IIS rewrite rules, “but it cannot generate Nginx configuration”. On Nginx you write the Multisite rules yourself from the documented examples.

On the command line, WP-CLI does the same conversion with wp core multisite-convert, which creates the Multisite tables and adds the constants to wp-config.php. Add --subdomains for a domain-based network.

#Subdomain or subdirectory multisite

The choice decides how site URLs look and what the server must support. The prepare-network guide lists the rules:

A network cannot be created at all when the WordPress address uses a port other than 80 or 443. Switching type later is possible but heavy: changing SUBDOMAIN_INSTALL and the rewrite rules “does not migrate existing site addresses or configure DNS, virtual hosts, TLS certificates, redirects, and cookies”. For a 100-site plan, decide once and test on staging.

#WordPress multi-network and database sharding

For organizations that have outgrown a single network, multi-network setups group sites into several networks inside one installation. Core supports the data model, but the management UI comes from plugins such as WP Multi Network.

#Regional grouping

You can have a network for Europe, a network for the Americas and a network for APAC, all within one installation. Each network has its own settings and its own list of network-activated plugins.

In WP-CLI every network has a numeric ID. wp site create --network_id=2 adds a site to the second network, and wp site list --network=2 lists only its sites.

#Sharding with a db.php drop-in

To prevent the database from becoming a bottleneck, a db.php drop-in such as HyperDB distributes site tables across multiple database servers and sends reads to replicas.

Sharding strategies:

• By region: each regional network has its own database server
• By volume: high-traffic sites get dedicated servers
• Hybrid: a mix of both, based on measured load

#What is shared and what is per site

The administration handbook also adds that network activating a plugin “does not change where the plugin stores its data”. Whether settings are network-wide or per site depends on how each plugin is written, so check that before you approve a plugin for the network.

#SSO and user roles in WordPress Multisite

With 100 sites, you likely have hundreds of users. You cannot manage them manually.

#SSO integration

Integrate your Multisite with an identity provider such as Okta or Microsoft Entra ID (formerly Azure AD). When an employee leaves the company, their access to all 100 websites is revoked in one place. That closes the gap of orphaned accounts, a common way into old sites.

#Super Admin controls

Define which sites can activate which plugins. A regional marketing team shouldn’t be allowed to install a risky plugin that could break the whole network. WordPress enforces part of this by default: in a network, site admins “cannot install new themes or plugins and cannot edit the profiles of users on their site”. Only the Super Admin can.

Recommended role hierarchy:

Custom roles, such as an SEO manager with access to meta fields only, are possible with a role plugin or code, and they are defined per site.

#Plugin access for site admins

By default site admins do not see the Plugins screen at all. The Network Settings screen has a Menu Settings option that enables it. Even then, site admins can only activate or deactivate plugins the Super Admin installed; network-activated plugins show as “Network Active” with no option to deactivate.

A plugin can also declare Network: true in its header, which makes it network-only.

#Themes per site

Network enabling a theme does not switch any site to it. It only makes the theme available. A theme can also be enabled for a single site from the Edit Site screen, Themes tab. New sites get the newest default theme unless you set WP_DEFAULT_THEME in wp-config.php to the folder name of your corporate theme, which saves a manual step on every new site.

#How to syndicate content across a WordPress multisite network

Sites in a network do not share content by default. The handbook compares a network to “a mini version of WordPress.com” and points to plugins for sharing. Plan syndication as a feature you add, not one you get.

#Publishing one announcement on every site

Broadcast plugins let you post a global corporate announcement once and copy it to all 100 sites. Typical candidates are press releases, product updates, security and compliance notices and seasonal campaigns.

#Global search

Use Elasticsearch (via ElasticPress) to provide a search bar that can find content across every site in the entire network. Native WordPress search queries the tables of one site.

#Reading content from other sites

Every site exposes its own REST API, so a hub site can pull posts from regional sites over HTTP. Inside PHP, switch_to_blog() and restore_current_blog() let code read another site’s tables directly, which is how most syndication plugins work.

#WordPress Multisite performance checklist for 100+ sites

#Redis for Multisite

• Keys per site: the object cache keys data by site ID, so sites do not overwrite each other’s cache
• Global groups: users and network options are cached once for the network
• Memory alerts: one large site can fill the shared cache

#Upload limits per site

Network Settings also control storage. By default each site’s upload space is limited to 50 MB and the max upload file size to 1500 KB, both editable. Allowed file types are a network list; adding a type there “will NOT work” unless it is also allowed through the upload_mimes filter. With 100 sites, set these limits on purpose instead of raising them per complaint.

#Automating WordPress Multisite with WP-CLI and CI/CD

#Automated deployments

In a network of 100+ sites, manual deployments do not scale:

• CI/CD pipeline: every code change passes automated tests on staging
• Gradual rollout: when you run several networks or installations, ship to the smallest group first
• Rollback: keep the previous release ready to restore

#WP-CLI at scale

WP-CLI is the main tool for running a network from the command line. Commands below are from the official WP-CLI command reference:

# Update core once, then run the database update on every site
wp core update
wp core update-db --network

# Activate a plugin for the whole network
wp plugin activate my-plugin --network

# Activate a plugin on every site of network 2 only
wp site list --network=2 --field=url | xargs -I {} wp plugin activate my-plugin --url={}

# Count published posts per site
wp site list --field=url | while read url; do
  echo "$url $(wp post list --post_type=post --post_status=publish --format=count --url="$url")"
done

#Site lifecycle commands

Archive and deactivate are reversible and the Network Admin treats archive the same as deactivate in practice. Spam makes a site unavailable to everyone. Delete removes the site, so script it with --keep-tables until you have a verified backup.

#Monitoring and alerts per site

Each site in the network needs its own alerts:

• Uptime per site (the main site can be up while a sub-site is down)
• Core Web Vitals per site
• PHP errors per site (a plugin activated on one site can cause errors there only)
• Database growth per site

#How to map a custom domain to a multisite site

Domain mapping is native since WordPress 4.5, according to the domain mapping guide. The steps:

1. Point the domain’s DNS at the server and park it on the network’s main domain.
2. Install a TLS certificate for every domain; the guide recommends SNI for the extra domains.
3. In Network Admin, open Sites, edit the site and set Site Address (URL) to the full domain, for example https://example.com.
4. If logins fail with a cookie error, add define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); to wp-config.php.

For 100 brands on 100 domains, certificate renewal becomes the recurring job, so automate it on the server.

#When not to use multisite

Multisite isn’t always the answer. The handbook itself warns: if you plan sites that “share data, or share users” in a strongly connected way, “a multisite network might not be the best solution”. Avoid it if:

1. Unique requirements: Site A needs a completely different server configuration or a different PHP version than Site B.
2. IP reputation: If one site on the network is “spammy,” it could affect the reputation of all other sites on that same IP. This matters most for sites that depend on email deliverability.
3. Data isolation: A client requires their data to be in a completely separate database for legal reasons.
4. Team autonomy: Each team needs to choose and install its own plugins.
5. One dominant site: One site carries most of the traffic and needs its own infrastructure.

#Alternatives to Multisite

#How to migrate to WordPress Multisite step by step

#Phase 1: audit

• Inventory of all existing sites
• Analysis of plugins and themes in use, and whether each works in Multisite
• Data and isolation requirements
• Integrations per site

#Phase 2: architecture

• Network structure (one network or several)
• Sub-domain or sub-directory, decided once
• Database strategy
• Roles and permissions

#Phase 3: implementation

• Multisite environment on staging
• Content migration site by site
• SSO and governance
• Cache and CDN

#Phase 4: optimization

• Load testing
• Cache and database tuning
• Training for network admins
• Written runbooks for updates and new sites

The handbook warns that moving Multisite “is more complicated than moving a single install”, so test the migration path on staging before the production cutover.

#Conclusion

WordPress Multisite is a strong tool for anyone running a fleet of sites. It provides the efficiency of centralized management with the flexibility of decentralized content creation.

If you are looking to scale from 10 sites to 100 or 1000, architecting your Multisite correctly from day one is the most important technical decision you will make.

#Related resources

• WordPress development
• WordPress speed optimization
• WordPress security audit
• WordPress maintenance
• WooCommerce development
• Contact WPPoland