Can’t Access the WordPress Multisite Admin? Causes and Fixes

This article is a localized edition of the Japanese original. Read the Japanese original

When you can't get into the admin screens of a WordPress Multisite network, the cause usually falls into one of a few groups: permissions, wp-config.php settings, web server rewrites, DNS, or a mismatch with the domains stored in the database. Start from the symptom to narrow down the cause, then check and fix it step by step.

The commands in this article use WP-CLI. The steps were checked against the official WordPress handbook (Advanced Administration) and the official WP-CLI documentation as of November 2026. Back up your database and files before you start.

wp db export before-fix.sql

Narrow down the cause from the symptom

Check the current settings

# Multisite constants
wp config get MULTISITE
wp config get SUBDOMAIN_INSTALL
wp config get DOMAIN_CURRENT_SITE
wp config get PATH_CURRENT_SITE

# List the sites in the network (with domain and path)
wp site list --fields=blog_id,domain,path,url

# List Super Admins
wp super-admin list

The domain and path in wp site list come from the wp_blogs table (assuming the wp_ prefix). Make sure they match the URL you are opening in the browser.

Check the wp-config.php constants

When the network was created, constants like these were added to wp-config.php. The values differ for each install, so compare them with what the Network Setup screen in Network Admin (/wp-admin/network/setup.php) shows.

<?php
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false ); // false for subdirectories, true for subdomains
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

What to check:

• DOMAIN_CURRENT_SITE and PATH_CURRENT_SITE match the domain and path of the main site (blog_id 1) in the wp_site and wp_blogs tables. If they don't, WordPress can't find the network and may show the "Error establishing a database connection" screen.
• They agree exactly, including whether www is used and http versus https.
• The constants sit above the /* That's all, stop editing! Happy publishing. */ line. Anything written after require_once ABSPATH . 'wp-settings.php'; has no effect.
• Changing SUBDOMAIN_INSTALL after the network exists means updating .htaccess and every site URL to match. Don't change it except to correct a configuration mistake.

Check Super Admin rights

Only Super Admins can open Network Admin (/wp-admin/network/). An Administrator of a subsite can't.

# Grant Super Admin (username, email or ID)
wp super-admin add username

# Confirm in the Super Admin list
wp super-admin list

The list of Super Admins is stored as a network setting (site_admins in the wp_sitemeta table). From the admin screens, another Super Admin edits the user under Users in Network Admin and checks the option that grants Super Admin privileges.

Add the user to the subsite

In Multisite, user accounts are shared across the network, but each user's role is set per site. If you can't get into a subsite's admin, check whether you have been added as a user of that site.

# Check users and roles on the subsite (--url is that site's URL)
wp user list --url=https://example.com/site1/ --fields=ID,user_login,roles

# Add the user as an administrator of the subsite
wp user set-role username administrator --url=https://example.com/site1/

On Multisite, wp user set-role adds the user to the target site and then sets the role. From the admin screens, open Sites in Network Admin, click Edit for the site, and add an existing user on the Users tab.

Check the rewrite rules

Apache (.htaccess)

The Multisite .htaccess differs from the single-site version, and it also differs between subdirectory and subdomain networks. Use the one that matches your network type.

For a subdirectory network (example.com/site1/):

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

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
# END WordPress Multisite

For a subdomain network (site1.example.com):

# BEGIN WordPress Multisite
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]
# END WordPress Multisite

If WordPress lives in a directory other than /, set RewriteBase to that path. The Network Setup screen shows rules tailored to your install.

Notes:

• On Multisite, neither wp rewrite flush --hard nor saving the permalink settings rewrites .htaccess (WordPress core does not write .htaccess on Multisite). Edit it by hand.
• wp rewrite flush has no --network option. To regenerate each site's rewrite rules, run it per site with --url.
• Apache needs mod_rewrite enabled and AllowOverride All (at least FileInfo) allowed for that directory.

Nginx

Nginx ignores .htaccess. A subdirectory network needs rewrites that strip the site-name part and pass the request to wp-admin and so on. The configuration below is based on the official handbook example (match the PHP handling to the location ~ \.php$ block in your own setup).

server {
    server_name example.com;
    root /var/www/example.com/htdocs;
    index index.php;

    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;
    }

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

For a subdomain network, accept the subdomains as well, as in server_name example.com *.example.com;, and the try_files line in location / is enough. After editing, check with sudo nginx -t and apply with sudo systemctl reload nginx.

DNS and web server for subdomain networks

In a subdomain network, each subsite hostname (site1.example.com) must reach your WordPress server.

# Check that DNS returns the server's IP
dig +short site1.example.com

• Create a DNS record (A or CNAME) for each subdomain, or a wildcard record (*.example.com). According to the official handbook, wildcard DNS is only needed if users can create sites on demand (so new subdomains appear on the fly).
• The web server must also accept the hostname (ServerAlias in Apache, server_name in Nginx).
• With HTTPS, the SSL certificate must cover the subdomains (a wildcard certificate, or one per subdomain).

Check the site’s registered address

In a subdomain network, if no site in the database matches the hostname you opened, WordPress redirects to wp-signup.php (the new-site signup screen). Use wp site list --fields=blog_id,domain,path to check that the hostname and path you are opening are registered.

If only one site has the wrong URL, check that site's home and siteurl.

# Check the site URLs (--url is the address registered in wp_blogs)
wp option get home --url=https://site1.example.com/
wp option get siteurl --url=https://site1.example.com/

# Set the correct values
wp option update home 'https://site1.example.com' --url=https://site1.example.com/
wp option update siteurl 'https://site1.example.com' --url=https://site1.example.com/

To fix the domain or path stored in wp_blogs, open Sites in Network Admin, click Edit for the site, and change the site address.

Check the site’s status

If a site is archived, deactivated (flagged as deleted) or marked as spam, users other than Super Admins see a suspension message instead of the site or its admin (Super Admins see everything as usual).

wp site list --fields=blog_id,url,archived,deleted,spam

# Restore the status (2 is the site's blog_id)
wp site unarchive 2
wp site activate 2
wp site unspam 2

If you can’t get in after changing the domain

Changing the domain of a Multisite network takes more steps than a single site. The official handbook says to move the files, update .htaccess and wp-config.php as needed, change every instance of the old domain in the database to the new one, and finally review wp_site, wp_blogs and each site's home and siteurl by eye.

WP-CLI's search-replace replaces values without breaking serialized data. With --network, it covers every table registered to the network.

# 1. Check the number of replacements with --dry-run first (wp-config.php still has the old domain)
wp search-replace 'old.example.com' 'new.example.com' --network --skip-columns=guid --dry-run

# 2. If it looks right, run it for real
wp search-replace 'old.example.com' 'new.example.com' --network --skip-columns=guid

# 3. Change DOMAIN_CURRENT_SITE in wp-config.php to the new domain

# 4. Check the result
wp site list --fields=blog_id,domain,path,url

If you change wp-config.php to the new domain first, the database still holds the old domain, so WP-CLI can't find the network either and stops. In that case, switch wp-config.php back to the old domain, run the replacement, and then change it. Replacing the domain also changes email addresses and other strings that contain it, so review the --dry-run output before running it.

If you still can’t get in

• Clear your browser cookies or try a private window (right after a domain or protocol change, old cookies may linger).
• If you added cookie-related constants such as COOKIE_DOMAIN to wp-config.php, remove them temporarily and test again.
• To rule out plugins, temporarily deactivate them with wp plugin deactivate --all --network and wp plugin deactivate --all --url=<site-URL>, then test (reactivate them afterward).

Related articles: How to set up WordPress Multisite and How to fix WordPress Multisite errors.

Summary

• If you can't open Network Admin, first check with wp super-admin list whether you are a Super Admin.
• If you can't open a subsite's admin, check with wp user list --url= whether you are a user of that site, and add yourself with wp user set-role.
• For 404s or broken screens, add the .htaccess rules (or Nginx rewrites) for your network type by hand. WordPress does not write .htaccess on Multisite.
• For domain problems, make sure the wp-config.php constants, wp_site, wp_blogs and each site's home and siteurl all agree.

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)