Fix 'No site defined on this host' Error in WordPress Multisite

The Error

You set up WordPress Multisite, add a new site, and try to visit it. Instead of your site, you get this:

No site defined on this host! If you are the owner of this site, please check Debugging WordPress for further assistance.

This hits both subdomain installs (site1.example.com) and subdirectory installs (example.com/site1). WordPress queried the wp_blogs table for the requested host, found no match, and gave up. The domain in your browser and the domain in the database are out of sync — full stop.

Root Causes

The domain in the browser doesn't match what's stored in wp_blogs or wp_site.
wp-config.php is missing required Multisite constants, or they point to the wrong domain.
The site was added under one domain, then the domain changed — database still has the old one.
A migration copied the database but skipped the URL update step.
Wildcard DNS for subdomains isn't resolving to the server at all.

Fix 1 — Verify wp-config.php Constants

Open wp-config.php and confirm these lines exist and are correct:

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

DOMAIN_CURRENT_SITE must exactly match the domain you visit. No www prefix unless your main site uses it. If you visit www.example.com but the constant says example.com, every subdomain lookup silently fails — this one typo accounts for a surprising number of support tickets.

Fix 2 — Check the Database Records

Log into MySQL and inspect the two key tables:

-- Check the network (site) record
SELECT * FROM wp_site;

-- Check individual blog records
SELECT blog_id, domain, path, archived, deleted FROM wp_blogs;

Compare the domain column against what you're requesting in the browser. Post-migration mismatches typically look like this:

-- Database says:
domain = 'site1.old-domain.com'

-- But you're visiting:
https://site1.new-domain.com

Fix it with targeted UPDATEs:

-- Update the network root
UPDATE wp_site SET domain = 'new-domain.com' WHERE id = 1;

-- Update the main blog
UPDATE wp_blogs SET domain = 'new-domain.com' WHERE blog_id = 1;

-- Update a specific sub-site (blog_id = 2 here)
UPDATE wp_blogs SET domain = 'site1.new-domain.com' WHERE blog_id = 2;

Don't stop there. Each site has its own options table — check those too:

-- Main site options
SELECT option_name, option_value FROM wp_options
WHERE option_name IN ('siteurl', 'home');

-- Sub-site with blog_id = 2 (table prefix = wp_2_)
SELECT option_name, option_value FROM wp_2_options
WHERE option_name IN ('siteurl', 'home');

Update any stale URLs you find there as well.

Fix 3 — Wildcard DNS for Subdomain Installs

Subdomain Multisite needs a wildcard DNS record. Without one, site1.example.com never reaches your server — WordPress doesn't even see the request, let alone try to route it.

Add this record in your DNS provider:

Type:  A
Name:  *
Value: YOUR_SERVER_IP
TTL:   3600

Give it a few minutes to propagate, then verify:

dig site1.example.com +short
# Should return your server IP

Testing locally? Add manual entries to /etc/hosts instead of waiting on DNS:

127.0.0.1  example.com
127.0.0.1  site1.example.com
127.0.0.1  site2.example.com

Fix 4 — Web Server Configuration

Nginx

Your server_name must accept wildcard subdomains. A common mistake is listing only the root domain:

server {
    listen 80;
    server_name example.com *.example.com;

    root /var/www/html;
    index index.php;

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

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

Reload after any changes: sudo nginx -t && sudo systemctl reload nginx

Apache

Make sure ServerAlias covers subdomains and mod_rewrite is enabled:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias *.example.com
    DocumentRoot /var/www/html

    <Directory /var/www/html>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Also check that .htaccess contains the Multisite rewrite rules. WordPress generates these during network setup. If they're gone, re-save your permalink settings — or grab them directly from the Network Setup screen and paste them in manually.

Fix 5 — After a Migration or Domain Change

Migrated from another server? Renamed the domain? Don't chase individual tables by hand. Use WP-CLI's bulk search-replace instead:

# Dry run first — always
wp search-replace 'old-domain.com' 'new-domain.com' --network --dry-run

# Apply when the output looks right
wp search-replace 'old-domain.com' 'new-domain.com' --network

# Clear all caches
wp cache flush --network

The --network flag runs the replace across every site table — wp_2_options, wp_3_options, and so on. On a network with 20 sites, this one command replaces what would otherwise be 40+ manual queries.

Verification

Once you've applied a fix, confirm things are actually working before calling it done:

# 1. Check WordPress can see all sites
wp site list --fields=blog_id,url,public,archived

# 2. Curl the sub-site directly — bypasses browser cache
curl -I http://site1.example.com
# Expect: HTTP/1.1 200 OK (or 301 redirect to HTTPS)

# 3. Confirm DB records look right
wp db query "SELECT blog_id, domain, path FROM wp_blogs;"

# 4. Scan PHP error log for anything still broken
tail -f /var/log/php/error.log

Prevention

Before migrating: snapshot all site URLs first with wp site list — you'll know exactly what needs updating on the other side.
After domain changes: run wp search-replace --network before the site goes live, not after users start reporting 404s.
Wildcard SSL: HTTPS installs need a certificate that covers *.example.com, not just the root domain. A bare-domain cert will break every subsite.
Staging environments: keep a separate wp-config.php with its own DOMAIN_CURRENT_SITE. That way, a production database dump won't silently break staging when someone imports it.