Drupal multisite in 2026. When it works, when it doesn't, and what to compare it with.

Managing several websites with one team and one platform has always been a poorly solved problem. Every mainstream CMS has tried its own variant —Multisite in WordPress, containers in JAMstack, logical tenants in most SaaS products— and each has its hidden costs.

Drupal multisite is one of the oldest and yet most solid solutions out there. So old that several generations of developers have declared it dead. But in 2024 the official decision from the Drupal core team made it clear that it stays as a first-class feature, and with the arrival of Drupal 11, Drupal CMS and Recipes (January 2025) it has picked up new tools that make it more practical than at any previous moment.

This guide goes over the real state of Drupal multisite in 2026: architecture, use cases, comparison with WordPress, modern alternatives (Pantheon Custom Upstreams, Acquia Site Factory, containers), a compact technical setup with Drupal 11.3 and criteria to decide whether it fits your project.

What Drupal multisite is

Drupal multisite is a native core feature that lets you serve multiple independent websites from a single codebase. A single Drupal install (core, modules and themes) runs several sites; each one with its own configuration, content and, normally, its own database, but sharing the same source code.

Drupal decides which site to load based on the requested domain: it reads HTTP_Host, looks inside sites/ for a folder with that name, loads its settings.php and connects to the matching database.

It's important to understand from the start that there are two completely different architectures for serving multiple sites from one Drupal install. Confusing the two is the source of most bad architectural decisions.

Traditional multisite (separate databases). The native core feature. Codebase is shared but each site has its own database, configuration, users and content, fully isolated. Sites share nothing automatically. This is what officially matches "multisite" in the documentation.

Multidomain with Domain (shared database). A solution based on the contributed Domain module, which by 2026 ships stable 2.x and 3.x releases compatible with Drupal 11. Here there's a single logical Drupal site with a single database, served under several domains with fine control over which content shows up on each one. Users are shared by default, content too unless you explicitly limit it. Domain 3.x has migrated to use core Config Collections to manage configuration overrides, and has introduced experimental support for path prefix, allowing several "domains" to share a hostname distinguished by the first URL segment.

Picking between the two is almost always the most important decision of the project, and it has nothing to do with personal preference: it depends on whether the sites share content/users (Domain) or are radically different projects that only share technical infrastructure (traditional multisite).

When multisite makes sense in 2026

After a decade watching multisite deployments —some brilliant, many disastrous— the pattern is fairly clear.

It fits well when:

• An organization publishes many sites with the same technical structure but isolated: university portals per faculty, municipal sites per department, corporate web networks per subsidiary, media networks with independent mastheads.
• You want one team maintaining the code but need each site to have its own editorial cycle, users, permissions and potentially its own hosting.
• The sites share enough functional similarities to justify a common base, but enough differences not to be a single multilingual site.
• You want to spin up microsites or campaigns quickly from a preconfigured structure.

It doesn't fit when:

• Sites share a lot of content or users and only differ in branding (the classic case for Domain, not multisite).
• Each site has radically different technical needs that require incompatible module versions (better separate installs).
• The team lacks experience with Composer, Drush and controlled deployments (multisite multiplies operational problems if the process isn't under control).
• You need each site to scale and fail independently at the infrastructure level (you should go for container-per-site or platforms like Pantheon or Acquia).

Real advantages of a well-built multisite

The usual "less work, more output" argument is true, but the concrete advantages deserve some precision.

Centralized maintenance. A single core or module update applies to every site at once. If you find a bug in a custom module, you fix it once and every site gets the patch on the next deployment. For teams that have managed 10 separate Drupal installs, the saving is substantial. For teams managing 50 or 100, it's the difference between viable and unviable.

Lower infrastructure costs. A single server can host dozens of sites because they share code and, depending on configuration, also PHP, OPcache and cache resources. Compared with N separate installs each with their own infrastructure, the reduction is obvious. Compared with specialized platforms like Acquia Site Factory, costs are also noticeably lower because you don't pay licensing or managed-platform fees.

Code and configuration reuse. With the arrival of Recipes in Drupal 11 (January 2025), the reuse pattern has improved radically. Recipes are preconfigured packages of functionality —content types, views, blocks, permissions, modules— that can be applied to any Drupal 11.2+ install. In a multisite, you can build your own Recipe for a "corporate blog base" and apply it to every new site in one shot. They replace the old install profiles with a much cleaner and composable syntax. Drupal CMS 1.0 and 2.0 are built entirely on Recipes.

Horizontal scalability for launches. Adding a new site to a well-configured multisite is practically instant: a new empty database, a new folder under sites/, a settings.php pointing to the DB, a Drush install with the chosen profile or Recipe. You can have a new site running in minutes.

Security consistency. A point that's underrated: with 50 separate installs it's statistically almost impossible to keep them all current on security patches. With multisite it's almost impossible not to —the same code update protects the entire fleet at once. The critical Drupal security advisory of 20 May 2026 (PSA-2026-05-18) would have been a nightmare for any agency with 30 separate sites; for a multisite, a single update.

Content sharing (only with Domain). If you go with Domain instead of traditional multisite, you can have a single piece of content published simultaneously on several domains, with fine control over which node appears where. It's a feature with no native equivalent in most CMSs.

Drupal multisite vs WordPress multisite

Both systems exist and solve real needs, but the philosophy is different enough to justify comparing them precisely.

Initial setup. In Drupal, enabling multisite doesn't require modifying core: you create a folder named after the domain under sites/, drop a settings.php with the connection to the new DB, and Drupal picks it up automatically. In WordPress you have to edit wp-config.php to define specific constants (WP_ALLOW_MULTISITE, then MULTISITE), touch .htaccess, run the network install from the dashboard, and pick between subdomains or subdirectories right then —a decision that's hard to change later.

Domain handling. Drupal multisite is designed for fully independent domains from day one. WordPress multisite by default assumes subdomains or subdirectories of a base domain; for custom domains you need domain mapping (now in core, but with hosting-specific quirks).

Database structure. Drupal allows a separate database per site (the usual and recommended option) or a shared DB with prefixes. WordPress multisite forces a single shared DB with a prefix per site. Drupal's isolation means a high-traffic site doesn't degrade other sites' DB, per-site backups are trivial and a corruption error affects only one site, not the whole network.

Functional isolation. In Drupal each site can have completely different modules enabled and different configuration, even different theme versions. In WordPress multisite all sites share the plugin and theme files; you can deactivate them per site, but the files are common. WordPress has the "network super admin" concept that can limit the autonomy of per-site admins; Drupal multisite has no such hierarchy because each site is essentially independent.

Portability. Pulling a site out of a Drupal multisite is relatively simple (copy the folder, copy the DB, isolate the install). In WordPress multisite, splitting a site off the network is complex because of how the shared DB structure stores references.

Philosophy. WordPress multisite was born to enable WordPress.com-style blog networks. Drupal multisite is an architecture tool for managing fleets of sites that are generally more complex. If the use case is "enable 200 simple blogs with self-registration", WordPress multisite can be perfectly adequate. If it's "a university with 40 portals with their own editorial workflows", Drupal multisite is practically the only reasonable open source option.

Practical setup with Drupal 11.3

This section walks through the typical case compactly: you want to add a second site to an existing Drupal 11 install (managed with Composer, as it should be in 2026).

1. Server and domain preparation. Every domain that will serve a multisite site must point to the same server at DNS level, and the webserver (Nginx or Apache) must have a server block or virtual host serving all those domains from the same Drupal root. For local development, the recommended option in 2026 is still DDEV, which has native multisite support via the --additional-hostnames flag.

2. Create the new site folder. Under web/sites/, create a folder with the exact domain name:

mkdir -p web/sites/second-domain.com/files
chmod 755 web/sites/second-domain.com
chmod 775 web/sites/second-domain.com/files

3. Generate the per-site settings.php. Copy the template and edit the new DB connection:

cp web/sites/default/default.settings.php web/sites/second-domain.com/settings.php

Inside the new settings.php, configure $databases['default']['default'] pointing at an empty DB you've created beforehand. In Drupal 11 it's good practice to externalize credentials with environment variables and load them with getenv(), especially if you work with platforms like Pantheon, Platform.sh/Upsun or Lando.

4. (Optional) sites.php for advanced mapping. Drupal detects the site by matching folder name to HTTP_Host. If you need aliases (for example, www.second-domain.com and second-domain.com pointing to the same site) or staging environments with different domains than production, edit web/sites/sites.php:

$sites['www.second-domain.com'] = 'second-domain.com';
$sites['staging.second-domain.com'] = 'second-domain.com';

5. Install via Drush with a Recipe. Instead of going through the browser installer, in 2026 the clean pattern is:

drush --uri=https://second-domain.com site:install \
  --site-name="Second Domain" \
  --account-name=admin \
  -y
drush --uri=https://second-domain.com recipe ../recipes/corporate-blog-base

The second command applies a custom Recipe you keep outside web/ (for example in recipes/). This is the step that replaces the manual configuration repeated site by site.

6. Modules and themes. Anything that lives under web/modules/ and web/themes/ is available to every site, but each site decides what it enables via its own configuration. If you need a module specific to a single site (rare but possible), you can drop it under web/sites/second-domain.com/modules/.

7. Update workflow. Code updates you do once:

composer update drupal/core-recommended drupal/core-composer-scaffold drupal/core-project-message -W

DB updates you run per site:

drush --uri=https://first-domain.com updb -y
drush --uri=https://second-domain.com updb -y

For large fleets it's worth wrapping this step in a script or Drush aliases.

Modern alternatives to "classic" multisite

Drupal multisite isn't the only way to serve multiple sites with shared infrastructure. In 2026 there are mature alternatives worth knowing before deciding.

Pantheon Custom Upstreams. Pantheon lets you define an "upstream" repository that serves as a base for N independent Drupal sites. Each site has its own install, but they share the same codebase maintained in one place. Changes to the upstream propagate to all sites with one click. Similar in philosophy to multisite, but with each site on separate infrastructure (own DB, own PHP instances, independent scaling). Good option for agencies with many clients sharing technology but not infrastructure.

Acquia Site Factory. The pure enterprise solution: a SaaS platform specifically designed to manage hundreds or thousands of Drupal sites with shared code. It ships all the governance machinery, multi-level deployment workflows, global user management and contractual SLAs. Expensive, but for large-corporation, government or university organizations with serious audit requirements, often the right answer. "Homebrew" Drupal multisite doesn't scale well to that size operationally (not technically).

Container-per-site (Docker / Kubernetes). The modern microservices approach: each site lives in its own container with its Drupal install, its DB and its lifecycle. They share a Docker base image (which you can update centrally), but they're operationally independent. Clear advantage: total performance and failure isolation. Downside: more resource consumption and operational complexity (Kubernetes has a real learning curve). Good option when isolation matters more than resource efficiency, or when sites have very different load patterns.

Drupal CMS with Recipes. For cases where each site can be a separate install but you want functional uniformity, Drupal CMS 2.0 (October 2025) and its Recipes ecosystem is a lightweight alternative to multisite. You define your "stack" in a custom Recipe and applying it to each new site is one Drush command.

The question isn't "which is better". It's which fits your specific case. Traditional multisite is unbeatable on resource efficiency and maintenance centralization. Container-per-site is unbeatable on isolation. Managed platforms are unbeatable on enterprise-scale operations. Pantheon Upstreams is an elegant middle ground.

SEO in a multisite environment

The SEO part is simpler than it sounds, because each site in a Drupal multisite is, for all practical purposes, an independent site as far as Google is concerned. But there are five points to watch.

Domains vs subdomains vs subpaths. For sites that have to build independent authority (different brands, different markets), separate domains. For sites that share brand and authority (same company, different languages or regions), subdomains or subpaths. Drupal multisite handles domains and subdomains perfectly; subpaths is technically possible but tricky, and the natural subpath solution tends to be a single multilingual Drupal site (not a multisite). Domain 3.x has added experimental path prefix support that shifts this a bit, but with care.

Duplicate content. If you use Domain to share content across domains, you'll need to configure canonical tags with the Metatag module pointing to the primary version. In traditional multisite, content lives in different databases, so duplicate risk only exists if you physically copy content between sites, which is rare.

Independent sitemaps and robots.txt. Each site must have its own sitemap.xml and robots.txt. The Simple XML Sitemap module works naturally with multisite —each site generates its own without interfering. Robots is part of the codebase and applies to all, but often you want to differentiate (for example, prevent indexing of internal sites); the RobotsTxt module provides per-site versions.

Hreflang. If the sites correspond to languages/regions of the same organization, configure hreflang properly with Metatag or Hreflang Multilingual. Multisite doesn't automate this relationship because sites are independent; you have to define it explicitly. A cleaner alternative for clearly multilingual cases is a single Drupal site with native core translation.

Shared performance. A code-level optimization (caches, CDN, image lazy loading, AVIF/WebP format) propagates to every site at once. This is a direct technical-SEO advantage: every site benefits from each Core Web Vitals improvement you ship.

Decision: three questions to rule out options fast

If you've read this far and still hesitate between Drupal multisite, Domain, separate instances or specialized platforms, these three questions resolve most cases.

1. Do the sites share content or users?

• Yes, often → Domain.
• No, never → traditional multisite or separate instances.

2. How many sites do you expect to maintain simultaneously?

• Up to about 15-20, with the same team → traditional multisite is ideal.
• 20-100, with isolation requirements → Pantheon Custom Upstreams or container-per-site.
• 100+ with enterprise governance → Acquia Site Factory or equivalent.

3. Do you need sites to scale and fail independently?

• Yes → container-per-site, Pantheon or Acquia.
• No, all have similar load patterns → traditional multisite.

These three questions resolve 90% of cases. The rest are matters of team, budget and governance that don't get resolved by reading an article.

What to remember

Drupal multisite in 2026 isn't an old solution surviving by inertia. It's a mature, officially supported, well-maintained tool, compatible with the most important new pieces of the ecosystem (Recipes, Drupal CMS, Drupal 11). For technical teams with Drupal experience that have to serve dozens of sites on the same tech base, it remains one of the most efficient and solid solutions in the open source landscape.

What's changed is the context. Today multisite competes not only with separate installs, but also with specialized platforms, orchestrated containers and Recipes-based workflows. The decision is no longer "multisite or not"; it's which multitenant pattern fits your team, scale and budget. And for a good share of cases, the answer is still multisite, now powered by the new tools that version 11 and Drupal CMS have brought in.