Codex tools: Log in
This section outlines some requirements to consider before you begin creating a multisite network.
The sites in a multisite network are separate, very like the separate blogs at WordPress.com. They are not interconnected like things in other kinds of networks (even though plugins can create various kinds of interconnections between the sites). If you plan on creating sites that are strongly interconnected, that share data, or share users, then a multisite network might not be the best solution.
For example, if all you want is for different collections of web pages to look very different, then you can probably achieve what you want in a single site by using a plugin to switch themes, templates, or stylesheets.
For another example, if all you want is for different groups of users to have access to different information, then you can probably achieve what you want in a single site by using a plugin to switch capabilities, menus, and link URLs.
This guide describes how to install manually WordPress Multisite in your current WordPress installation. There are also available ready-to-run packages from BitNami.
You can choose between several different types of multisite network depending on how you want your network to handle URLs, and on whether it will allow end users to create new sites on demand.
Different types of network have different server requirements, which are described in a section below. If you do not have full control over your server then certain types of multisite network might not be available to you. For example, you might not have full control over your server because you use a shared hosting environment. In that case you will have to negotiate the requirements with whoever operates the hosting environment.
The sites in a network have different URLs. You can choose one of two ways for the URL to specify the site:
Additionally, you can map domains like example1.com, example2.com, etc, however a plugin is required.
You can also choose whether or not to allow end users to create new sites on demand. Domain-based on-demand sites are normally only possible using subdomains like site1.example.com and site2.example.com. Path-based on-demand sites are also possible.
The multisite installation process uses different terminology. A sub-domain install creates a domain-based network, even though you might use separate domains, and not subdomains, for your sites. A sub-directory install creates a path-based network, even though it does not use file system directories. If you want to use a sub-domain install, you must install WordPress in the root of your webpath (i.e. domain.com) however it does not need to be installed in the root (i.e. /public_html/) if you choose to run WordPress from it's own directory.
After the multisite network installation is complete, WordPress uses the terminology domain and path for each site's domain and path in the Network Admin user interface. A super admin (that is, a multisite network administrator) can edit sites' domain and path settings, although it is unusual to do this to established sites because it changes their URLs.
Plugins can extend the options available and help with administration. For example, you can use the WordPress MU Domain Mapping plugin to help you map individual sites to independent domain names. For another example, you can use the Networks for WordPress plugin to configure multiple networks in the same WordPress installation.
To create a multisite network you must be the administrator of a WordPress installation, and you normally need access to the server's file system so that you can edit files and create a directory. For example, you could access the server's file system using FTP, or using the File Manager in cPanel, or in some other way.
You do not necessarily need any knowledge of WordPress development, PHP, HTML, CSS, server administration or system administration, although knowledge of these things might be useful for troubleshooting or for customizing your multisite network after installation.
When you are planning a network, it can sometimes be helpful to use a development server for initial testing. However, setting up a development server that exactly matches your production server is not always possible, and transferring an entire network to a production server may not be easy. A test site on your production server is sometimes a more useful way to test your planned network.
Some server requirements depend on the type of multisite network you want to create, as follows.
Also known as 'Subdomain' installs, a Domain-based network uses URLs like
A domain-based network maps different domain names to the same directory in the server's file system where WordPress is installed. You can do this in various ways, for example:
On-demand domain-based sites require the wildcard subdomains method. You can create additional sites manually in the same network using other methods.
Whichever methods you use, you will need to configure your DNS (to map the domain name to the server's IP address) and server (to map the domain name to the WordPress installation directory). WordPress will then map the domain name to the site.
WordPress must be installed in the root of your webfolder (i.e. public_html) for subdomains to work correctly. They will not work from within a subdirectory.
For some examples of how to configure wildcard subdomains on various systems, see: Configuring Wildcard Subdomains
Also known as 'Subfolder' installs, a path-based network uses URLs like
If you are using pretty permalinks in your site already, then a path-based network will work as well, and you do not need any of the other information in this section. That said, be aware that your main site will use the following URL pattern for posts:
At this time, you cannot remove the blog slug.
For a path-based network you normally require mod_rewrite to be loaded on the Apache server, support for it in .htaccess files, and Options FollowSymLinks either already enabled or at least not permanently disabled. If you have access to the server configuration, then you could use a Directory section instead of a .htaccess file.
The requirement is the same for on-demand path-based sites.
Example: Configuring mod_rewrite in an Apache server on Ubuntu Linux.
When you install a multisite network you start from an existing WordPress installation. If it is a fresh install with its own domain name, then you do not need to read this section. If it is an established site, or not reachable using just a domain name, then the following requirements apply to allow it to be converted to a multisite network.
Giving WordPress its own directory works with Multisite as of 3.5, however you must make the 'own directory' changes before you activate Multisite.
While it's not recommended to use www in your domain URL, if you chose to do so and plan to use subdomains for multisite, make sure that both the site address and the WordPress address are the same. Also keep in mind some hosts will default to showing this sort of URL:
For this, and many other reasons, we do not suggest you use www in your domain name whenever possible. If you plan on changing them to
www.domain.com, do so before you begin the rest of the setup for multisite, as changing the domain name after the fact is more complicated.
You cannot create a network in the following cases:
You cannot choose Sub-domain Install (for a domain-based network) in the following cases:
(Note that you can create a domain-based network on your local machine for testing purposes by using your hosts file to map some other hostnames to the IP address 127.0.0.1, so that you never have to use the hostname
You cannot choose Sub-directory Install (for a path-based network) if your existing WordPress installation has been set up for more than a month, due to issues with existing permalinks. (This problem will be fixed in a future version. See Switching network types for more information.)
wp-admin/network.php for more detail)