Multisite runs several WordPress sites from one installation. One set of core files, one database, one place to apply updates. It is built into WordPress and switched off by default.
The decision to use it is harder to reverse than the decision to set it up, so it is worth understanding what you are committing to.
When it fits
Multisite makes sense when the sites are genuinely related and centrally managed.
A company with regional sites sharing a theme. A university with departmental sites. A platform where you create sites for other people. In those cases the shared plugin and theme library and the single update run are a real saving.
When it does not
Unrelated sites belonging to different owners. Sites likely to be sold or moved separately. Anything where one site needs a plugin the others must not have.
The common mistake is choosing multisite for five unrelated client sites because updating once sounds easier. It is easier, until a client wants to leave, and extracting a single site from a shared database is a genuinely awkward job.
Separate installations under separate cPanel accounts stay separate for free. That has value you only notice when you need it.
Subdomains or subdirectories, decide before enabling
This is the decision that cannot be changed afterwards without significant work.
Subdirectories: example.com/site1/. Nothing extra to configure and all sites share the domain's authority.
Subdomains: site1.example.com. Sites feel more independent, and this requires a wildcard DNS record and a wildcard certificate.
Pick subdirectories unless the sites need to feel like separate properties. It is the simpler arrangement in every operational respect.
Enabling it
Add to wp-config.php, above the line that says to stop editing:
define('WP_ALLOW_MULTISITE', true);
A Network Setup item appears under Tools. It asks for your choice of subdomains or subdirectories, then produces two blocks of configuration. One for wp-config.php and one for .htaccess.
Paste both, exactly as given. The .htaccess block replaces the standard WordPress rules instead of being added alongside them, and doing that wrong produces a network where the main site works and the others 404.
Back up the database and both files first. This changes the structure of the installation.
Deactivate plugins first
Do the conversion on a site with plugins deactivated. Several interfere with the process, and the failure is not always obvious.
Reactivate afterwards, deciding for each whether it belongs to one site or to the whole network.
How permissions change
Multisite introduces a role above administrator.
The Super Admin manages the network: creating sites, installing plugins and themes, applying updates.
A site Administrator manages one site's content, users and settings. They cannot install a plugin or a theme, and this surprises people who were administrators before the conversion.
That restriction is the point. Plugin installation is centralised because plugin files are shared, and a plugin installed for one site exists for all of them. There is more on the ordinary roles beneath this in WordPress user roles and permissions.
Plugins in a network
Network activation turns a plugin on for every site. Otherwise a Super Admin makes it available and each site activates it individually.
Prefer the second. Network-activating everything means every site carries the cost of every plugin, including the ones it never uses.
And check that a plugin supports multisite before relying on it. Many do not, and the way they fail is to store settings globally that should be per-site, so changing a setting on one site silently changes it on all of them.
What is shared and what is not
Shared: the core files, the plugin and theme files, and the user table.
Separate: each site's content, settings, and its own set of database tables.
The shared user table is worth understanding. A user account exists once across the network and is granted a role per site. That is convenient when the same people work on several sites, and it means a compromised account is a compromise of everything it has access to.
The consequences to accept
The database is shared. One database holds every site, and backing up or restoring a single site means extracting its tables specifically rather than restoring the file.
Moving a site out is real work. There are tools for it and none of them are one click.
A core update affects everything. One update run is the benefit, and one bad update taking down every site is the cost.
Hosting requirements go up. Ten sites on one installation still serve ten sites' worth of traffic from one account. Monitoring your hosting resources sets out watching for the ceiling.
Mapping real domains
Sites can answer on their own domains instead of a subdomain or subdirectory. Modern WordPress supports this without a plugin.
Each mapped domain has to point at this server and needs its own certificate. Add the domain in cPanel, run AutoSSL for it, and only then map it, mapping a domain that does not yet resolve here produces a site nobody can reach, including you.
If you are unsure
Do not enable it. Separate installations are simpler to run, simpler to back up, simpler to move and simpler to hand to someone else.
Multisite is the right answer for a specific shape of problem: many related sites, one operator, shared design. Outside that shape, the update convenience is not worth what it costs to undo.
Know what a network commits you to
Running several sites from one installation means they share the code, the plugins and the upgrade schedule. That is the benefit and it is also the constraint. A plugin required by one site is installed for all of them, and an update that breaks one breaks the set. Separating a site out afterwards is a migration rather than a setting, since its content lives in shared tables. The arrangement suits sites that are genuinely similar and is a poor fit for a collection that happens to share an owner.