Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
On WordPress Multisite, the “site does not exist” message usually means WordPress cannot match the hostname and path in your request to a registered site in the network. Fix it by checking the site record in Network Admin → Sites, then verify DNS and web-server routing, confirm that the URL matches the network’s subdomain or subdirectory mode, and only then investigate missing database tables. Back up the database and files before changing network settings or database data.
The same wording can also appear in administrative operations when a site ID is invalid or a site has been deleted. A single-site WordPress installation follows a different path: check its hosting virtual host, document root and site URL instead of applying Multisite-specific repairs.
| # | Preview | Product | Price | |
|---|---|---|---|---|
| 1 |
|
WordPress For Dummies (For Dummies (Computer/Tech)) | $16.59 | Buy on Amazon |
| 2 |
|
WordPress All-in-One For Dummies | $25.40 | Buy on Amazon |
| 3 |
|
Wordpress for Dummies | $26.94 | Buy on Amazon |
| 4 |
|
WordPress Web Design For Dummies | $16.48 | Buy on Amazon |
| 5 |
|
WordPress Web Design For Dummies | $29.30 | Buy on Amazon |
What the “site does not exist” message actually means
WordPress Multisite keeps a registry of sites. Each site is identified by a domain and a path. When a request arrives, core looks up that pair before loading the site. If no matching record is found, WordPress follows its ms_site_not_found path and may redirect or stop according to the network configuration. The browser-facing result is commonly a page saying that the site does not exist.
This is a routing and registration problem first, not proof that every WordPress file has disappeared. A site can be present in the database yet unreachable because DNS points the hostname elsewhere or the web server does not accept that hostname. Conversely, a hostname can resolve correctly while no matching site record exists in the network.
#1 Best Overall
“During activation of a new subdomain, the requested site does not yet exist.”
That sentence from WordPress Multisite source code explains a frequent timing problem: a new subdomain can be requested before its site record and routing are ready.
The phrase also appears in administrative code. wp_delete_site() and wp_update_site() return a WP_Error with code site_not_exist when the requested site ID cannot be found. Network administration can display the clearer message “The requested site does not exist.” Those administrative messages point to an absent or incorrect site object, rather than necessarily a DNS failure.
Protect the installation before troubleshooting
Make the investigation reversible. Export the database and back up the WordPress files before editing domain, path, network settings or database rows. Keep a copy of the original values and change one layer at a time. If the network is production-critical, schedule changes for a maintenance window and record the exact URL, hostname, path and time of each test.
- Write down the complete URL that fails, including scheme, hostname, port if applicable and every path segment.
- Note whether the failure occurs for one site or every site in the network.
- Record whether the site was newly created, recently moved, renamed, archived or restored.
- Do not create a second site with a similar hostname until the existing record, path and network ID have been checked.
Seven checks that identify the failing layer
1. Confirm whether this is Multisite
The domain-and-path lookup described above belongs to WordPress Multisite. In a single-site installation, there is no network site registry to search. Check the hosting virtual host, document root, configured site URL and whether the request is reaching the intended WordPress installation. Applying Multisite database fixes to a single-site installation can make the problem worse.
Rank #2
2. Compare the requested URL with Network Admin
Sign in to the network dashboard and open Network Admin → Sites. Find the site that should answer the request and compare the values character by character:
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →- Hostname spelling, including every subdomain label.
- Path, including leading and trailing slashes and any nested directory.
- Whether the request uses the network’s expected scheme and host.
- Whether the site is archived, deleted, inactive or otherwise unavailable.
- Whether the site belongs to this network rather than another installation.
WordPress must find the matching domain-and-path pair before it can load the site. A one-character spelling difference or an unexpected path is enough to produce the error.
3. Test DNS for the exact hostname
The hostname must resolve to the server that hosts this Multisite installation. A record that points to an old host, a different project or an unrelated default site can make a correctly registered site appear missing. Check the record for the exact failing hostname, not only the parent domain.
After correcting DNS, allow caches to expire according to the record’s time to live (TTL). Test again after the change is visible from the networks where your users connect. If only some locations fail, inconsistent DNS caching is a stronger possibility than a missing WordPress site record.
4. Check the web-server virtual host or alias
DNS only selects an IP address. The web server must also accept the requested hostname and route it to the document root containing this Multisite installation. Add or correct the virtual host, server alias or equivalent host configuration, then reload the server using your host’s normal procedure.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #3
A useful rule is: register the hostname as a site in the network and point its DNS or server alias at this installation. If either side is missing, the request can land on a default site or never reach WordPress’s Multisite bootstrap.
5. Identify the network URL mode
Determine whether the network was configured for subdomains or subdirectories. These modes use different URL patterns:
| Network mode | How WordPress identifies a site | Typical failing request | First checks |
|---|---|---|---|
| Subdomain | The hostname changes for each site, such as a site-specific subdomain. | A subdomain is not registered, does not resolve, or is not accepted by the server. | Network Admin site record, DNS record and server alias for that hostname. |
| Subdirectory | The network hostname stays the same while the site identifier appears in the path. | A request uses a subdomain pattern, or the path does not match the registered site. | Exact path in Network Admin, generated URLs and network settings. |
Subdomain and subdirectory networks are separate configurations. If links or incoming requests use subdomains while the network is configured for subdirectories, correct the generated URLs and network settings or plan a deliberate migration. Do not switch modes casually on a live network: URL values, rewrite behavior and DNS or server routing all need to be changed together.
6. Check database and blog-table state
If the site is listed correctly and DNS and server routing point to the right installation, inspect the database state. WordPress has a separate ms_not_installed() path for missing blog tables. Missing tables can mean the database server is not running, the installation was incomplete, or someone deleted the tables.
Check database connectivity, the configured table prefix and the existence of the tables for the affected site before attempting repairs. A site record can exist while its tables are absent, so registration alone does not prove that the site’s content database is intact.
Rank #4
7. Check for deletion or an invalid site ID
If the error occurs while editing or deleting a site in Network Admin, verify the site ID and current network membership. The site may have been deleted, moved to another network or referenced by an outdated ID. Use Network Admin and a known-good backup to establish whether the site object still exists before recreating anything.
Fixes for each cause
The site is missing from the network registry
Create the site in Network Admin → Sites → Add New using the exact domain and path that users request. Confirm the network ID and URL values before saving. If the site previously existed, restore its correct record from a verified backup rather than creating a near-duplicate.
After registration, test the exact URL. If it still fails, continue with DNS and server checks; adding a record in WordPress does not automatically create public DNS or a web-server alias.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteThe domain or subdomain resolves to the wrong server
Correct the DNS record for the failing hostname so it resolves to the server hosting the Multisite installation. Then configure that server’s virtual host or alias to accept the hostname and pass it to the same WordPress document root. Wait for TTL-based caches to expire, verify resolution again and retest the URL.
If your host manages DNS or server configuration for you, provide the exact hostname, expected destination and the network’s URL mode. Ask the administrator to confirm both the DNS record and the virtual-host mapping; checking only one leaves the other failure point untouched.
Best Value
The URL pattern does not match the installation mode
For a subdomain network, use the registered site hostname and make sure that hostname resolves and is accepted by the server. For a subdirectory network, use the registered path on the network’s existing hostname. Correct links, redirects and network settings that generate the wrong pattern.
If the organization truly needs to move from subdomains to subdirectories or the reverse, treat it as a migration. Back up first, inventory every site domain and path, update network configuration and generated URLs consistently, and arrange the required DNS and server changes. A partial switch commonly creates new “site does not exist” lookups because WordPress is searching for a different domain/path pair than the one recorded.
The site was newly created but activation is incomplete
A new subdomain can be requested during the interval before its site record is available or before DNS and server routing have propagated. Confirm that the site appears in Network Admin, then verify the hostname’s DNS and virtual-host mapping. Retest only after those layers are ready. Do not repeatedly create the site while activation is still in progress, because duplicate or near-duplicate records make later diagnosis harder.
Blog tables or the database are missing
First establish whether the database server is reachable and whether the configured table prefix is correct. Check that the affected site’s blog tables exist. If tables were deleted or the installation was incomplete, restore from a known-good backup or involve the host or database administrator. Database repair is materially riskier than correcting a URL, DNS record or server alias, so preserve a backup and avoid ad hoc row edits.
The site object or ID is invalid
Use Network Admin to search for the site by domain and path, not only by ID. If no record exists, determine whether it was intentionally deleted, moved to another network or removed during a restore. Restore the verified site record and related data when appropriate. If the record exists under a different ID, update the administrative workflow or integration that still references the old ID.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose the least risky fix first
| Failure layer | Evidence | Typical action | Risk |
|---|---|---|---|
| Site registration | No matching domain/path in Network Admin, or an invalid site ID. | Correct or restore the site record. | Low when done through Network Admin; verify before creating a new site. |
| DNS | Hostname resolves to another address or does not resolve to the Multisite host. | Correct the DNS record and wait for TTL-based propagation. | Usually reversible, but affects every service using the hostname. |
| Web-server routing | DNS is correct, but the host is rejected or routed to another document root. | Add or correct the virtual host/server alias. | Configuration change; isolate it to the affected hostname. |
| URL mode | Requests use subdomains on a subdirectory network, or paths do not match. | Correct generated URLs and network settings, or plan a full migration. | High if changed partially on a live network. |
| Database/blog tables | Site is registered and routed, but required tables are absent or database access fails. | Restore or repair with a verified backup and administrator help. | Highest; protect data and avoid unverified edits. |
Verification after every change
Retest the same URL after each single-layer change. Confirm that the hostname reaches the intended server, WordPress finds the expected domain/path record and the site’s tables load. Then check an administrator login and at least one front-end page for the affected site.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →- Test the failing hostname exactly as entered, including its path.
- Test another known-good site in the same network to detect a network-wide routing problem.
- For a subdomain network, test the site-specific hostname and the network’s main hostname separately.
- For a subdirectory network, test the network root and the affected site path separately.
- Check from a network that is not using an old DNS cache after the TTL window.
- Record the final domain, path, DNS destination and server alias so a future restore reproduces the working configuration.
When to involve the host or database administrator
Escalate when you cannot safely inspect DNS, virtual-host configuration or database tables, when the site was deleted without a verified backup, or when multiple sites fail simultaneously after a server move. Provide the exact hostname and path, network mode, current DNS destination, the site’s Network Admin status and the time the failure began. That information lets an administrator distinguish a missing site record from a host-level routing or database problem without making speculative changes.
Preventing the error on future Multisite changes
- Keep an inventory of every site’s domain, path, network ID and status.
- For each new subdomain, create the network site and the DNS/server mapping as one change plan.
- Document whether the network uses subdomains or subdirectories and keep generated URLs consistent with that mode.
- Back up the database and WordPress files before migrations, restores or direct database work.
- After deleting or moving a site, remove or update integrations that retain its old site ID.
- Use a staged hostname or maintenance window to verify activation before announcing a new site.
In most cases, the browser message is resolved by restoring the correct domain-and-path match and making DNS and server routing agree with it. Missing blog tables and invalid administrative IDs are separate failure paths; investigate them only after the registration and routing layers have been verified.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
