WordPress multisite is a built-in feature that lets you run multiple WordPress websites from a single installation. You get one dashboard, one set of core files, and one shared database that holds as many sites as you need under subdirectories, subdomains, or mapped custom domains. If you manage several WordPress sites for a business, a university, or a network of related brands, multisite cuts the overhead of maintaining separate installations by a wide margin.
The setup takes about fifteen minutes if you know where to edit two configuration files. After that, you can add new sites in seconds, share themes and plugins across the entire network, and handle updates from one admin panel instead of logging into each site individually. Whether you’re running two sites or two hundred, the administrative savings compound with every site you add to the network.
Most multisite guides were written before block themes and Full Site Editing changed how WordPress works at a structural level. The plugin recommendations in those older guides still point to tools that predate the block editor entirely, and their advice on themes doesn’t account for the Site Editor or Global Styles. This page covers multisite as it works in 2026, with specifics on how block themes behave on a network, which plugins actually support multisite activation, and how to handle GDPR consent across every subsite without repeating the same setup dozens of times.
Everything below applies to self-hosted WordPress.org sites on your own hosting. WordPress.com multisite is a different product with different limitations, and the two shouldn’t be confused.
When does WordPress multisite actually make sense?
Multisite works best when the sites in your network share a common purpose, a common owner, or both. A real estate agency with separate sites for each regional office is a strong candidate, because every site needs the same brand template and the same plugins. A university department running faculty blogs and course pages benefits from centralized theme management and a single login system for every professor. Franchise operations, government departments with public-facing microsites, and SaaS companies maintaining separate documentation portals alongside their marketing sites all fit this pattern cleanly.
The Super Admin role sits above every individual site administrator and controls what’s available to the entire network. You decide which themes and plugins can be activated, and individual site admins can only work with what you’ve approved. That level of control matters when you’re responsible for brand consistency, security compliance, or update schedules across a dozen properties that would otherwise drift apart over time.
Multisite is a poor fit when the sites have nothing in common beyond the person maintaining them. A web developer managing ten unrelated client sites should keep them on separate installations, because a security breach or a bad plugin update on one site ripples across the entire network. If a plugin conflict takes down the network admin, every site goes down with it. Shared hosting plans that don’t support wildcard subdomains or custom domain mapping also make multisite more trouble than it’s worth, since you’ll spend hours working around limitations that a separate install would avoid entirely.
There are a few practical limits to keep in mind when planning. All sites in a multisite network share a single database, with each site getting its own set of prefixed tables. That means you can’t isolate one site’s data from the others at the database level. For sites that handle sensitive financial or medical data, separate installations with separate databases are the safer choice. And performance-wise, a shared file system means the wp-content/uploads directory for all sites lives on the same disk, so a traffic spike on one subsite can slow down file serving for the others unless you’re using a CDN or object storage.
How do you install and configure a multisite network?
The installation process involves editing two files and following the code snippets WordPress generates for you. Before you start, back up your site completely, make sure pretty permalinks are turned on (Settings > Permalinks, pick anything except “Plain”), and confirm you have FTP or file manager access to edit wp-config.php and .htaccess. If you’re running any caching plugin, deactivate it first to avoid stale configuration being served during the transition.
Open wp-config.php and add this line above the comment that says “That’s all, stop editing!”:
define( 'WP_ALLOW_MULTISITE', true );
Save the file and refresh your WordPress dashboard. A new menu item appears under Tools called Network Setup. You’ll choose between two network structures: subdomains, where each site gets an address like site.example.com, or subdirectories, where each site lives at example.com/site/. Subdirectories are simpler because they don’t require wildcard DNS configuration. Subdomains give each site a cleaner URL but require your hosting to support wildcard subdomains and a wildcard SSL certificate. If your WordPress installation has been live for more than a month with existing content, WordPress will only offer subdomains, because subdirectory URLs could conflict with existing pages and posts.
After you pick the structure, WordPress generates two blocks of code. The first block goes into wp-config.php, right above the “stop editing” line you found earlier, and contains constants like MULTISITE, SUBDOMAIN_INSTALL, and DOMAIN_CURRENT_SITE. The second block replaces the existing rewrite rules in .htaccess with rules that route requests to the correct subsite. Copy both exactly as shown, save both files, log out, and log back in. You’ll see a “My Sites” menu at the top of the dashboard, and your multisite network is running.
For sites on completely separate domains rather than subdomains or subdirectories, point each domain’s DNS to the same server and map it through My Sites > Network Admin > Sites. WordPress has supported native domain mapping since version 4.5, so no plugin is needed. Edit the site, change its URL to the custom domain, and make sure the domain’s SSL certificate covers the mapped domain. Every domain in the network needs its own valid SSL, not just the primary domain, because a missing certificate on any subsite will trigger browser security warnings and break visitor trust.
Two more constants worth setting in wp-config.php after the initial setup: define( 'SUNRISE', true ); if you’re using domain mapping (this loads the sunrise.php dropin before WordPress initializes, which some hosting setups need for proper domain routing), and define( 'WP_MEMORY_LIMIT', '256M' ); to give each subsite enough PHP memory for the admin dashboard and the block editor. The default 40MB or 64MB limit that many hosts set will cause white screens on subsites that load multiple plugins and a block theme with the Site Editor active.
Which plugins work best on a WordPress multisite network?
Not every WordPress plugin works on multisite. Some plugins store their settings in the options table without accounting for site-specific prefixes, which means they either break on multisite, overwrite settings between subsites, or need to be configured separately on every single subsite. Before you network-activate any plugin, check whether the developer explicitly lists multisite support in the plugin’s documentation or readme, and test it on a staging network first.
For Gutenberg blocks, DigiBlocks supports network activation and gives every site in your multisite the same set of blocks without installing it on each subsite individually. The styling stays consistent across the network because every block uses the same markup and class structure, which matters if you need a uniform editing experience for site administrators who aren’t designers.
E-commerce on multisite gets complicated when WooCommerce is involved, because WooCommerce creates dozens of database tables per subsite and becomes harder to maintain as the network grows. If you’re selling digital products, courses, or services across your network, DigiCommerce is a lighter alternative built specifically for digital sales on WordPress. Each subsite can run its own store with its own checkout flow, and the Super Admin manages plugin settings from the network dashboard without the overhead WooCommerce adds to the shared database.
Cookie consent is an area where multisite creates real compliance problems that most consent plugins weren’t designed to handle. The typical plugin needs to be configured per site, which means repeating the same banner setup, legal links, and cookie categories on every subsite. DigiConsent handles this at the network level: one configuration applies across all subsites, consent records are stored centrally, and individual subsites can still add their own tracking scripts when needed.
For SEO, Rank Math supports multisite and allows you to manage SEO settings either globally or per site. Wordfence offers a multisite-compatible security dashboard that monitors the entire network from a single view. For caching, WP Rocket and W3 Total Cache both work on multisite, though you’ll want to test your caching configuration carefully because cache invalidation and page rules can behave differently per subsite. If your network serves sites in different countries, make sure the caching layer respects consent states, since a cached page that skips the consent banner is a compliance violation.
How do block themes handle a WordPress multisite setup?
Block themes and Full Site Editing changed the way themes work on multisite, because customization now happens visually rather than through code. With classic themes, each subsite could use a child theme to customize the parent, but those customizations were limited to PHP functions, CSS overrides, and widget areas. With block themes, each site admin gets access to the Site Editor, where they can rearrange templates, swap header and footer layouts, adjust typography, and modify colors without writing a line of code.
The Super Admin decides which block themes are available to the network by network-enabling them. When a theme is network-enabled, every subsite can activate it, and each site admin can then customize it through the Site Editor independently. The customizations are stored per site in the database through the template and template part systems, so one site’s layout changes don’t affect any other site in the network. This is useful when you want every site to start from the same branded baseline but need individual teams to adjust their own layouts and page templates.
Theme weight matters more on multisite than on standalone installations, because every theme asset gets loaded for every subsite. A heavy theme with 200KB of CSS, multiple JavaScript files, and embedded font stacks multiplied across a hundred subsites puts real strain on server resources and slows down page loads across the board. Lightweight block themes like DigiFlash and DigiFusion are built with minimal CSS and JavaScript footprints, which keeps the network fast as it grows. Both are full FSE block themes, so site admins still get the complete template editing experience without the performance cost of a bloated theme.
Template parts (headers, footers, sidebar patterns) are another area where block themes and multisite interact in ways that aren’t immediately obvious. When you create a custom header template part on one subsite through the Site Editor, that template part only exists for that subsite. Other subsites won’t see it, even if they’re using the same theme. If you want every site in the network to use a consistent custom header, you’ll need to define it in the theme itself (as a template part file in the parts/ directory) rather than through the Site Editor, so it ships with the theme to every subsite automatically.
One detail to watch: Global Styles changes in the Site Editor are stored per site, not per network. If you change the default font family or the primary color palette on one subsite, the other subsites keep their own settings. WordPress doesn’t have a built-in mechanism to push a Global Styles update across all sites at once. For strict brand consistency, you’ll want to lock down the theme.json defaults at the theme level, limit what individual site admins can override in the Site Editor, or use a must-use plugin (mu-plugin) to enforce network-wide style rules that individual sites can’t change.
How do you manage GDPR consent across every subsite?
Cookie consent on a multisite network is a compliance challenge that most single-site plugins don’t solve well. Each subsite in the network might use different analytics and tracking scripts, serve visitors in different legal jurisdictions, and need its own privacy policy URL. Installing and configuring a separate consent plugin on every subsite creates duplicate work that scales linearly with the network, and any missed update on a single subsite leaves it out of compliance with GDPR, CCPA, or whichever regulation applies.
The two approaches that actually work are network-activated consent plugins and external consent management platforms. A network-activated plugin installs once at the Super Admin level and applies its configuration to every subsite automatically. DigiConsent takes this approach: you configure your consent categories (analytics, marketing, functional), banner text, and legal page links at the network level, and every subsite inherits the same setup. Subsites that need additional tracking scripts or site-specific legal pages can add their own without breaking the shared configuration.
For networks that span multiple regions, geo-targeted consent behavior becomes a requirement rather than a nice-to-have. A visitor from Germany needs a GDPR-compliant banner with explicit opt-in before any non-essential cookies are set. A visitor from California may only need a CCPA notice with an opt-out option. A visitor from a jurisdiction with no specific cookie law might not need a banner at all. Running this geo-targeting logic per subsite is a maintenance problem that gets worse with every site you add. Centralizing it at the network level puts the logic in one place and applies it to every subsite automatically.
Whatever consent tool you choose, test it on a staging copy of your multisite before deploying to production. Consent plugins interact with page caching, CDN edge caching, and third-party scripts in ways that can produce unexpected results on multisite. Make sure the consent banner loads correctly on every subsite’s domain (especially if you’re using domain mapping), that the consent state persists across pages within each subsite, and that no tracking scripts fire before the visitor makes a choice. A consent banner that appears but doesn’t actually block scripts is worse than no banner at all, because it creates a false sense of compliance.
Your WordPress multisite network, built on the right stack
WordPress multisite hasn’t changed much at the database level since it was introduced, but the ecosystem around it looks very different now. Network-aware plugins that configure once and apply across every subsite, paired with block themes that give each site admin real visual control, have turned multisite into a production-ready way to run dozens of WordPress sites from a single installation. The difference between a multisite network that scales and one that becomes unmanageable comes down to the choices you make before you start adding subsites.
If you’re building or planning a WordPress multisite network, start with a lightweight block theme, install only plugins that explicitly support network activation, and handle GDPR consent at the network level from day one. The fifteen minutes it takes to edit wp-config.php and .htaccess is the easy part. Getting the theme and plugin stack right is what determines whether your network stays manageable at five sites, fifty sites, or five hundred.
