WordPress Multisite Setup Guide for Beginners

TL;DR: WordPress Multisite Setup

Use WordPress multisite when you need to manage multiple related WordPress sites from one installation with shared plugins, shared themes, central updates, and a network admin dashboard. Avoid multisite when websites are unrelated, need separate hosting accounts, require very different plugin stacks, need isolated backups/restores, or belong to separate clients with different risk levels. To enable multisite, back up the site, deactivate plugins, confirm permalinks work, add define( 'WP_ALLOW_MULTISITE', true ); to wp-config.php, go to Tools → Network Setup, choose subdomains or subdirectories, then add the generated wp-config.php and server rewrite rules.

What Is WordPress Multisite?

WordPress multisite is a built-in WordPress feature that lets one WordPress installation run a network of multiple sites. These sites are often called subsites or network sites.

In a multisite network:

• All sites share the same WordPress core files.
• Plugins are installed once at the network level.
• Themes are installed once at the network level.
• Each site can have its own content, pages, posts, media, users, settings, and URL.
• Each site has separate database tables for its own content.
• Media uploads are separated by site.
• A Super Admin can manage the full network.
• Individual site admins can manage their own subsites depending on permissions.

A normal WordPress install manages one site. A multisite install manages many sites from one network.

Official reference: Setting up a WordPress multisite network.

WordPress Multisite vs Multiple WordPress Installs

Before using multisite, compare it against separate WordPress installations. Multisite is not automatically better. It centralizes management, but it also centralizes risk and complexity.

Use multisite when central management is more valuable than isolation. Use separate installs when isolation, custom configuration, and independent recovery matter more.

When Should You Use WordPress Multisite?

Multisite is best when the sites are related and should share the same WordPress codebase, plugins, themes, update workflow, and administrator oversight.

Good use cases for multisite:

• University department websites.
• School or campus networks.
• Franchise or branch location sites.
• Agency-controlled template-based client microsites.
• Multilingual sites where each language has its own subsite.
• Documentation networks.
• Internal company portals.
• Nonprofit chapter websites.
• News networks with separate editorial sections.
• SaaS-style website builders where users can create sites.
• Product microsites managed by one organization.
• Event websites under one brand.

Multisite makes sense when:

• You control all sites in the network.
• The sites are related.
• You want centralized plugin/theme management.
• You want one Super Admin to manage everything.
• The sites can share one server environment.
• The sites use similar themes or design systems.
• The sites need consistent security and update policies.
• You understand that one bad plugin can affect the whole network.

When Should You Avoid WordPress Multisite?

Multisite is not the right answer just because you have more than one website. It can become harder to manage than separate installs if the sites are unrelated or need different technical requirements.

Avoid multisite when:

• The websites belong to unrelated clients.
• Each site needs separate hosting resources.
• Each site needs a very different plugin stack.
• Each site needs independent backup and restore control.
• One site should not be affected by another site’s plugin/theme issue.
• You need different PHP versions per site.
• You need different server configurations per site.
• You are using plugins that do not support multisite properly.
• You want simple migration in and out of the network.
• You only need separate pages or sections, not separate sites.

Use a normal WordPress site instead when:

• You only need different page designs.
• You only need different user permissions.
• You only need categories, custom post types, or landing pages.
• You only need a multilingual plugin.
• You only manage two or three unrelated websites.

Multisite is a network architecture decision. Do not use it only because it sounds advanced.

Subdomain vs Subdirectory Multisite

When creating a WordPress multisite network, you usually choose between subdomain-based sites and subdirectory-based sites.

Subdomain network example:

site1.example.com
site2.example.com
blog.example.com
docs.example.com

Subdirectory network example:

example.com/site1/
example.com/site2/
example.com/blog/
example.com/docs/

Choose subdomains if:

• Each site should feel more independent.
• You want URLs like store.example.com.
• You are building a SaaS-style network.
• You can manage wildcard DNS and SSL.
• You may map custom domains later.

Choose subdirectories if:

• You want a simpler setup.
• You want URLs like example.com/fr/.
• You do not want DNS complexity.
• The sites are clearly part of one main domain.
• You are creating a smaller controlled network.

Choose carefully. Switching network type later is possible, but it is not something you should plan casually on a production network.

Before You Enable Multisite

Multisite changes your WordPress installation. Prepare properly before enabling it, especially on an existing production site.

Pre-setup checklist:

• Take a full file backup.
• Take a full database backup.
• Confirm pretty permalinks work.
• Deactivate all active plugins temporarily.
• Confirm you can edit wp-config.php.
• Confirm you can edit .htaccess or server rewrite rules.
• Confirm DNS access if using subdomains.
• Confirm SSL support for subdomains or mapped domains.
• Confirm your host supports multisite.
• Test on staging first if the site already has important content.

WP-CLI database backup:

wp db export before-multisite.sql

Files backup with SSH:

tar -czf wordpress-before-multisite.tar.gz /path/to/wordpress

Do not enable multisite on a live business website without a rollback plan.

Step 1: Enable Multisite in wp-config.php

To unlock the Network Setup screen, add WP_ALLOW_MULTISITE to wp-config.php.

Add this above the final stop-editing comment:

/* Multisite */
define( 'WP_ALLOW_MULTISITE', true );

Correct placement:

/* Multisite */
define( 'WP_ALLOW_MULTISITE', true );

/* That's all, stop editing! Happy publishing. */

Save the file, then refresh your WordPress dashboard.

FyrePress tool: Use the FyrePress wp-config.php Builder when preparing configuration constants for review.

Step 2: Open Network Setup

After enabling multisite support in wp-config.php, WordPress will show a new menu item.

Tools → Network Setup

On this screen, choose your network type:

• Subdomains: site1.example.com
• Subdirectories: example.com/site1/

WordPress will also ask for:

• Network title.
• Network admin email.
• Site address structure.

After clicking install, WordPress will generate custom code that you must add to wp-config.php and your server rewrite rules.

Step 3: Add the Generated Multisite Constants

WordPress will show a set of constants after you install the network. The exact values depend on your domain, path, and network type.

Example subdirectory multisite constants:

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Example subdomain multisite constants:

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Important difference:

// Subdomain network
define( 'SUBDOMAIN_INSTALL', true );

// Subdirectory network
define( 'SUBDOMAIN_INSTALL', false );

Copy the exact code WordPress gives you. Do not blindly copy another website’s multisite constants because the domain and path values may be different.

Step 4: Add Apache .htaccess Rules

If your server uses Apache or LiteSpeed, WordPress will provide multisite rewrite rules. Replace the normal WordPress rewrite section with the multisite rules shown in your Network Setup screen.

Example subdirectory multisite .htaccess rules:

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]

# Add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]

Your generated rules may differ. Use the rules shown in your own Network Setup screen.

Apache requirements:

• mod_rewrite must be enabled.
• .htaccess overrides must be allowed.
• Pretty permalinks should work before enabling multisite.
• Multisite rewrite rules are different from normal single-site WordPress rules.

FyrePress tool: Use the FyrePress .htaccess Security Builder for Apache/LiteSpeed rule planning and safer rule examples.

Step 5: Configure Nginx for Multisite

Nginx does not use .htaccess. If your WordPress site runs on Nginx, you must configure rewrite rules in the Nginx server block. Many managed Nginx hosts require multisite to be enabled during site creation because the server config must support it.

Basic Nginx WordPress rule:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Subdirectory multisite Nginx concept:

if (!-e $request_filename) {
    rewrite /wp-admin$ $scheme://$host$request_uri/ permanent;
    rewrite ^(/[^/]+)?(/wp-.*) $2 last;
    rewrite ^(/[^/]+)?(/.*\.php) $2 last;
}

location / {
    try_files $uri $uri/ /index.php?$args;
}

Nginx multisite configuration can vary by stack, PHP-FPM setup, document root, subdomain/subdirectory choice, and host panel. Use your host’s recommended Nginx multisite template when available.

After editing Nginx:

sudo nginx -t
sudo systemctl reload nginx

Do not edit production Nginx rules without testing. A single syntax mistake can take the site offline.

Step 6: Log In Again and Open Network Admin

After adding the required constants and rewrite rules, WordPress will ask you to log in again.

After login, you should see:

My Sites → Network Admin

Network Admin areas:

• Dashboard: network overview.
• Sites: add, edit, archive, deactivate, or delete subsites.
• Users: manage network users.
• Themes: enable or disable themes for the network.
• Plugins: install, activate, or network activate plugins.
• Settings: configure registration, uploads, email, and network behavior.
• Updates: update WordPress core, plugins, and themes across the network.

Step 7: Configure Network Settings

Go to:

My Sites → Network Admin → Settings

Important network settings:

• Registration settings.
• New site registration.
• New user registration.
• Upload file types.
• Upload size limit.
• New site email templates.
• Welcome email templates.
• Banned names.
• Limited email registrations.
• Network language.
• Menu settings for site admins.

Recommended starting settings:

• Disable public site registration unless you intentionally run an open network.
• Limit allowed upload file types.
• Set reasonable upload size limits.
• Do not allow site admins to install plugins unless your workflow requires it.
• Keep plugin/theme installation under Super Admin control.
• Review welcome emails before allowing users to create sites.

Step 8: Add Your First Subsite

To add a new site, go to:

My Sites → Network Admin → Sites → Add New

You will need:

• Site address.
• Site title.
• Site language.
• Admin email.

Subdirectory example:

example.com/docs/

Subdomain example:

docs.example.com

After creating the subsite, open its dashboard and test:

• Frontend page loading.
• Admin login.
• Permalinks.
• Media upload.
• Theme activation.
• Plugin behavior.
• Email sending.

Step 9: Configure DNS for Subdomain Multisite

Subdirectory multisite usually does not need extra DNS for each subsite. Subdomain multisite does.

Manual DNS records:

site1.example.com  A  203.0.113.10
site2.example.com  A  203.0.113.10
docs.example.com   A  203.0.113.10

Wildcard DNS record:

*.example.com  A  203.0.113.10

A wildcard DNS record is useful when you want to create subdomain sites on demand without adding DNS records manually each time.

DNS checklist:

• Point subdomains to the same server as the network.
• Use wildcard DNS if creating sites dynamically.
• Confirm the web server accepts those subdomains.
• Install wildcard SSL or individual SSL certificates.
• Check CDN/proxy settings if using Cloudflare or another CDN.

Step 10: Configure SSL for Multisite

Every site in the network should use HTTPS, especially admin login screens. SSL setup depends on your URL structure.

For subdirectory networks:

https://example.com/site1/
https://example.com/site2/

One SSL certificate for the main domain usually covers the subdirectory network.

For subdomain networks:

https://site1.example.com
https://site2.example.com

You may need a wildcard SSL certificate:

*.example.com

For mapped custom domains:

https://clientdomain.com

Each mapped domain needs valid SSL.

wp-config.php SSL admin constant:

define( 'FORCE_SSL_ADMIN', true );

Domain Mapping in WordPress Multisite

Domain mapping lets a subsite use a custom domain instead of the original network URL.

Example:

Original subsite:
client1.example.com

Mapped domain:
clientdomain.com

Since WordPress 4.5, domain mapping is built into WordPress multisite. You do not usually need an old domain-mapping plugin for basic mapping.

Domain mapping checklist:

• Create the subsite first.
• Point the custom domain DNS to the multisite server.
• Install SSL for the mapped domain.
• Go to Network Admin → Sites.
• Edit the subsite.
• Change the Site Address URL to the mapped domain.
• Test login, frontend, media, and redirects.

Cookie login fix for mapped domains:

If login fails or cookies are blocked on mapped domains, WordPress documentation suggests this constant in some cases:

define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );

Add it only when needed and test carefully across all mapped domains.

Official reference: WordPress Multisite Domain Mapping.

Managing Plugins in Multisite

Plugins are installed once at the network level. Then they can be activated for individual sites or network activated for all sites.

Plugin activation types:

Plugin checklist:

• Check if the plugin supports multisite.
• Network activate only plugins that should affect every site.
• Do not let every subsite admin install plugins freely.
• Test plugin settings on multiple subsites.
• Check whether plugin database tables are per-site or network-wide.
• Review plugin licensing for multisite usage.
• Test updates on staging before production.

WP-CLI plugin commands:

wp plugin list
wp plugin activate plugin-folder --network
wp plugin deactivate plugin-folder --network
wp plugin update --all

A plugin bug on multisite can affect the whole network. Be stricter with plugin selection than you would be on a small single site.

Managing Themes in Multisite

Themes are installed at the network level, but you can choose which themes are available to subsites.

Theme management options:

• Network enable a theme for all sites.
• Enable a theme only for specific sites.
• Use one shared parent theme and different child themes.
• Use one block theme with different patterns/styles per subsite.
• Limit site admins to approved themes only.

Theme checklist:

• Keep themes updated.
• Remove unused themes.
• Keep one fallback theme.
• Test theme updates on staging.
• Document which sites use which theme.
• Check if block themes fit your network workflow.
• Check WooCommerce templates if any subsite uses WooCommerce.

WP-CLI theme commands:

wp theme list
wp theme enable theme-folder --network
wp theme disable theme-folder --network
wp theme update --all

Users, Roles, and Super Admins

Multisite changes user management. Users can exist at the network level and have roles on individual sites.

Important roles:

• Super Admin: controls the entire network.
• Site Admin: manages one subsite, depending on network permissions.
• Editor: manages content on a subsite.
• Author/Contributor: creates content based on role permissions.
• Subscriber: basic account access.

User management checklist:

• Limit Super Admin access strictly.
• Use two-factor authentication for Super Admins.
• Do not share one Super Admin account across a team.
• Assign users only to the sites they need.
• Review users quarterly.
• Remove old agency, freelancer, or staff accounts.
• Be careful with plugins that modify roles network-wide.

WP-CLI user commands:

wp user list
wp super-admin list
wp super-admin add username
wp super-admin remove username

Super Admin access is extremely powerful. Treat it like root access for the WordPress network.

Uploads and Media in Multisite

Each subsite has its own media upload directory. This keeps media organized between sites, but all media still lives inside the shared WordPress installation.

Typical media structure:

wp-content/uploads/sites/2/
wp-content/uploads/sites/3/
wp-content/uploads/sites/4/

Media checklist:

• Set upload size limits.
• Restrict allowed file types.
• Monitor disk usage per site.
• Use image optimization.
• Back up all uploads directories.
• Be careful when deleting a subsite because media may be removed.
• Use CDN carefully with mapped domains and subdomains.

Backups for WordPress Multisite

Multisite backups need more planning than single-site backups. The network shares files, plugins, themes, and one database, but each subsite has its own tables and uploads.

Backup checklist:

• Back up the full database.
• Back up all WordPress files.
• Back up wp-content/uploads/sites/.
• Back up wp-config.php.
• Back up .htaccess or Nginx configuration.
• Store backups off-server.
• Test restore on staging.
• Confirm whether your backup plugin supports multisite restore properly.
• Document how to restore one subsite vs the full network.

WP-CLI full database backup:

wp db export multisite-network-backup.sql

Files backup:

tar -czf multisite-files-backup.tar.gz /path/to/wordpress

Restoring one subsite from multisite is more complex than restoring one normal WordPress site. Test your restore workflow before relying on it.

Security Checklist for Multisite

Multisite centralizes management, so security needs to be stricter. One vulnerable plugin, weak Super Admin password, or server issue can affect the entire network.

Multisite security checklist:

• Use strong hosting.
• Keep WordPress core updated.
• Keep plugins and themes updated.
• Use only multisite-compatible plugins.
• Limit Super Admin accounts.
• Enable two-factor authentication for Super Admins.
• Disable dashboard file editing.
• Restrict plugin/theme installation to trusted administrators.
• Use a firewall or WAF.
• Monitor failed logins.
• Review user roles regularly.
• Limit upload file types.
• Use SSL across all sites.
• Monitor logs across the network.

wp-config.php hardening:

define( 'DISALLOW_FILE_EDIT', true );
define( 'FORCE_SSL_ADMIN', true );

Performance and Caching for Multisite

A multisite network can become heavy as you add more sites, plugins, users, and media. Performance planning matters early.

Performance checklist:

• Use page cache where appropriate.
• Use object cache for database-heavy networks.
• Use a CDN for media and static assets.
• Limit unnecessary plugins.
• Monitor database size.
• Monitor autoloaded options.
• Monitor slow queries.
• Optimize images across subsites.
• Set reasonable upload limits.
• Choose hosting resources based on the full network, not one site.

Redis object cache notes:

Redis can help multisite performance, but use a clear cache prefix and test carefully.

define( 'WP_REDIS_PREFIX', 'network_example_com_' );

WP-CLI Commands for Multisite

WP-CLI is very useful for managing multisite networks, especially for developers and agencies.

Create a multisite network with WP-CLI:

wp core multisite-convert

Create a subdomain network:

wp core multisite-convert --subdomains

Create a new site:

wp site create --slug=docs --title="Docs" --email=admin@example.com

List sites:

wp site list

Run a command for one site:

wp --url=example.com/docs/ plugin list

Run updates:

wp core update
wp plugin update --all
wp theme update --all

List Super Admins:

wp super-admin list

WP-CLI can create multisite database tables and add multisite constants, but Apache users still need to update rewrite rules manually after setup.

Common WordPress Multisite Problems and Fixes

Problem: Network Setup menu does not appear

Check that WP_ALLOW_MULTISITE is above the final stop-editing comment in wp-config.php.

define( 'WP_ALLOW_MULTISITE', true );

Problem: Subsite shows 404

Check rewrite rules, permalinks, Nginx config, Apache mod_rewrite, and whether the site path or subdomain exists correctly.

Problem: Subdomain does not load

Check DNS, wildcard DNS, web server aliases, SSL, and whether the subdomain points to the multisite server.

Problem: Login loop or cookies blocked

Check domain mapping, cookie settings, HTTPS redirects, mixed domain values, and whether COOKIE_DOMAIN is needed for mapped domains.

Problem: Media upload fails on subsites

Check folder permissions, upload path, disk space, upload size limit, and allowed file types.

Problem: Plugin works on one site but breaks another

Check whether the plugin is multisite-compatible, whether it stores settings per site or network-wide, and whether it should be network activated.

Problem: Domain mapping breaks SSL

Install SSL for the mapped domain and check CDN/proxy settings. A certificate for the main network domain does not automatically cover unrelated mapped domains.

FyrePress tool: If you see PHP errors, 500 errors, login loops, or rewrite issues, review the logs with the FyrePress Server Log Analyzer.

Migration Notes: Single Site to Multisite

Converting an existing single WordPress site to multisite is possible, but it should be done carefully. It is easier on a fresh install than on an established production website.

Before converting:

• Back up files and database.
• Test on staging.
• Deactivate plugins.
• Confirm permalinks work.
• Decide subdomain or subdirectory structure.
• Check if the site has existed long enough to restrict subdirectory choice.
• Check hosting support.
• Check plugin compatibility.
• Document rollback steps.

Be careful with:

• Existing URLs.
• Existing pages that conflict with subsite paths.
• Old redirects.
• SEO changes.
• Plugin settings.
• Theme customizations.
• Media paths.

Migration Notes: Multisite to Single Site

Moving one subsite out of multisite into a standalone WordPress install is more complicated than a normal migration. Content, media, users, theme settings, plugin settings, and database tables may need careful export/import.

Common extraction steps:

1. Export the subsite content.
2. Copy the subsite uploads folder.
3. Install a fresh standalone WordPress site.
4. Import content.
5. Move media files.
6. Reinstall required plugins and themes.
7. Reconfigure plugin settings.
8. Run URL search-replace if needed.
9. Set redirects.
10. Test everything.

Do not choose multisite unless you are comfortable with the fact that separating sites later may take real migration work.

Best Multisite Setup by Website Type

University or school network

Use multisite when departments, programs, teachers, or campuses need separate sites under one controlled platform. Subdomains usually work well for departments; subdirectories can work for smaller structures.

Agency microsite network

Use multisite only when all sites share one controlled stack and similar requirements. Avoid it for unrelated high-value clients who need independent hosting, backups, and isolation.

Franchise or branch websites

Multisite is a strong fit when every branch needs a similar site structure, shared theme, shared plugins, and centralized brand control.

Multilingual websites

Multisite can work when each language needs a separate subsite, but a multilingual plugin may be easier for smaller sites. Choose based on editorial workflow, SEO structure, and translation management.

SaaS-style website builder

Use subdomain multisite with wildcard DNS, strong user restrictions, strict plugin/theme control, good caching, and automated provisioning workflows.

WooCommerce stores

Be careful. Multiple WooCommerce stores inside multisite can work, but backups, orders, payment gateways, performance, and plugin compatibility need stronger planning.

WordPress Multisite Setup Checklist

• Confirm multisite is actually needed.
• Choose subdomain or subdirectory structure.
• Check hosting support.
• Check DNS access.
• Check SSL support.
• Back up files and database.
• Deactivate plugins temporarily.
• Confirm pretty permalinks work.
• Add WP_ALLOW_MULTISITE to wp-config.php.
• Go to Tools → Network Setup.
• Install the network.
• Add generated multisite constants.
• Add generated Apache rules or configure Nginx.
• Log in again.
• Configure Network Admin settings.
• Create the first subsite.
• Configure DNS if using subdomains.
• Install SSL.
• Test plugins, themes, uploads, login, and permalinks.
• Document backup and restore process.

Common Multisite Mistakes to Avoid

• Using multisite for unrelated client websites.
• Skipping backups before conversion.
• Forgetting to deactivate plugins before network setup.
• Choosing subdomains without DNS access.
• Forgetting wildcard SSL for subdomain networks.
• Using plugins that do not support multisite.
• Network activating plugins that should be site-specific.
• Giving too many users Super Admin access.
• Assuming one subsite can be restored easily without planning.
• Letting subsites upload unlimited files.
• Ignoring server resources as the network grows.
• Changing domain/path values on established sites without testing.
• Using multisite when custom post types or categories would be enough.

Final Recommendation

WordPress multisite is best for related website networks that need centralized management, shared plugins, shared themes, consistent updates, and one Super Admin layer. It is a strong fit for universities, franchises, organization networks, controlled microsite systems, and SaaS-style site networks.

Avoid multisite when websites are unrelated, need different server setups, require independent backups, belong to separate clients, or need strong isolation from each other. In those cases, separate WordPress installs are usually safer and easier to maintain.

The safest multisite setup starts with planning: choose the right URL structure, confirm DNS and SSL, back up everything, test on staging, use strict plugin/theme control, limit Super Admin access, and document backup/restore procedures before the network grows.

Frequently Asked Questions

What is WordPress multisite?

WordPress multisite is a built-in feature that lets one WordPress installation run multiple sites. The sites share WordPress core files, plugins, and themes, while each site can have its own content, media, users, settings, and URL.

When should I use WordPress multisite?

Use multisite when you manage multiple related websites that should share one WordPress installation, one update workflow, shared themes, shared plugins, and central network administration.

When should I avoid WordPress multisite?

Avoid multisite for unrelated client websites, sites that need separate hosting, sites with very different plugin stacks, or projects that require simple independent backups and restores.

Is WordPress multisite good for agencies?

Multisite can work for agency-controlled microsite networks with similar requirements. It is usually not ideal for unrelated high-value clients because one network issue can affect multiple sites.

Should I choose subdomains or subdirectories for multisite?

Choose subdomains when sites should feel more independent and you can manage DNS and SSL. Choose subdirectories when you want a simpler setup under one main domain without extra DNS complexity.

Do I need wildcard DNS for WordPress multisite?

You need wildcard DNS if you use subdomain multisite and want to create subdomain sites on demand. For manually created subdomains, you can add DNS records individually.

Can WordPress multisite use custom domains?

Yes. WordPress multisite supports native domain mapping. Point the custom domain DNS to the network server, install SSL for that domain, then update the subsite Site Address URL in Network Admin.

Can I use different themes on different multisite subsites?

Yes. Themes are installed at the network level, and the Super Admin can enable themes for the full network or for specific sites. Each subsite can use an enabled theme.

Can each subsite install its own plugins?

Plugins are installed at the network level. Site admins usually cannot install plugins unless the Super Admin allows it. Plugins can be activated per site or network activated across all sites.

Is WordPress multisite harder to back up?

Yes. Full-network backups are straightforward, but restoring one subsite from a multisite network can be more complex than restoring a standalone WordPress site. Test your restore process before relying on it.