A subsite whose mapped domain is parked looks deleted from every angle — the front end shows a parking page, the REST API returns nothing, and no URL you guess resolves. It isn’t gone. Here’s why it hides, and the thirty-second fix.
200 OK from the host’s placeholder, so read the response body, not the status code, when a domain’s routing is in doubt.We needed three articles off one subsite of a WordPress Multisite network. The subsite simply would not load — and chasing it down turned into a useful lesson about how Multisite addressing actually works. Here is what we hit, in order, and the fix that finally worked.
The mapped domain shows a registrar parking page. The subsite answers on no address you still know.
Network admin lists it. The database holds its rows. Neither hands you a URL that actually resolves.
The mapping is a ROW, not the site. The site never moved; the only thing pointing at it did.
Edit the mapping, not the site. Nothing about the content, the IDs or the uploads ever changed.
The site was reachable throughout, at an address the mapping had quietly taken out of service.
Table of Contents
The symptom
The network has several subsites. Some live under the primary domain as subdirectories (network.example/shop); others are mapped to their own domains (brandx.example). The one we wanted was domain-mapped — and that domain had lapsed into a parked state. The front end showed a placeholder, and the REST API returned nothing we could use. The content was clearly still somewhere; we just had no working address for it.
The dead ends
We worked through the obvious routes, and each one taught us something worth writing down.
- Public DNS. The mapped domain did not resolve at all. The resolver even appended a local search suffix and matched a wildcard, which is easy to misread as “the domain exists.” It does not — a name that only resolves with a suffix tacked on is effectively unresolved.
- Pinning the hostname to the network’s server. We forced the request to the network’s IP with the right
Hostheader. It returned200 OK— but the body was the host’s generic “parked domain” placeholder, not WordPress. This is the trap: a managed host serves a parking page for any hostname it does not recognize as an active site, so a200proves nothing. Always read the response body, not just the status code — the same habit as auditing any other HTTP response — when a domain’s routing is in doubt. - Subdomain forms. Guesses like
brandx.network.exampledid not resolve — this network is subdirectory-based, not subdomain-based. - Subdirectory guesses. Every
network.example/brandx-style path returned a hard404, the same as any made-up path. That404was the real clue, though we did not see it yet. - A header-versus-certificate trick. We tried connecting to the live origin while presenting the dead domain’s
Hostheader. The content delivery layer refused the mismatch and closed the connection. Fronted sites generally require the server name and the host header to agree. - A REST endpoint for the site list. Core WordPress does not expose one. There is no built-in route that enumerates a network’s blogs, so you cannot discover a missing subsite that way.
The hard 404 on every subdirectory guess was the answer hiding in plain sight.
The insight
The hard 404 on every subdirectory guess was the answer hiding in plain sight. There are two kinds of subsites on a subdirectory network:
- A subdirectory subsite keeps a path on the primary domain even when it is also mapped to a custom domain.
network.example/shopkeeps answering regardless of the mapped domain’s health. - A full-domain subsite is added with its own domain and a root path. It has no subdirectory fallback. Its only address is that domain.
Our subsite was the second kind. The blog still existed in the database, but with its domain parked it had nowhere to answer — no path on the primary domain, no subdomain, nothing. That is why no guess could ever land: there was no second address to find.
A full-domain subsite has no fallback; its only address is that domain.
The fix
The clean fix takes about thirty seconds in the dashboard. In Network Admin → Sites, edit the site, and on the Info tab change Site Address (URL) from the dead domain to a path on a live domain — for example network.example/brandx/ — then save. That re-homes the blog onto an address that actually answers, and the front end and the REST API both come back immediately. The alternative is to repair the domain itself — re-point its DNS records at the host and clear the parking — so the original address works again. Re-pathing is faster when you only need to read the content; repairing DNS is right when the custom domain has to stay public.
Two gotchas worth keeping
- Application Passwords authenticate the REST API and XML-RPC, not the dashboard. Browser pages under
wp-adminneed a real cookie session, so an application password will not script you into Network Admin. A human makes the site-address change in the dashboard; automation can read over REST afterward. - A status code is not proof of arrival. A parked domain happily returns
200— the same 200-that-isn’t-what-it-looks-like trap as a maintenance page. When a domain’s routing is uncertain, confirm you reached the application by checking the body — the REST root’s site name is a good, cheap signal.
A parked domain happily returns 200 — that’s not proof you ever reached the site.
The short version
| Step | What it tells you |
|---|---|
| Resolve the domain | A name that only resolves with a search suffix is not really resolving |
| Pin host to server IP | A 200 parked page is not your site — read the body |
| Try subdirectory paths | A hard 404 everywhere means there is no path fallback |
| Check the subsite type | Full-domain subsites have only one address; subdirectory ones keep a path |
| Re-path or repair DNS | Re-path to read now; repair DNS to keep the public domain |
The lesson that stuck: on a Multisite network, a subsite’s type decides whether it survives losing its domain. A subdirectory subsite degrades gracefully; a full-domain subsite disappears entirely until you give it a living address. Knowing which kind you are dealing with turns an afternoon of guesswork into a single dashboard edit.
Frequently Asked Questions
Is my subsite’s content gone if the mapped domain is parked?
No. A parked domain only kills the address, not the data — the blog’s rows are still in the Multisite database. The site looks deleted because a full-domain subsite has no fallback address to answer on, but the moment you give it a living address (a path on a live domain, or a repaired domain) the front end and REST API return immediately.
How do I list all the subsites in a Multisite network?
Through Network Admin → Sites in the dashboard. Core WordPress exposes no REST route that enumerates a network’s blogs, so you can’t discover a missing subsite over the API — the dashboard (or WP-CLI on the server) is the authoritative list.
Can I reach a domain-mapped subsite without fixing the domain?
Yes. In Network Admin → Sites, edit the site and change its Site Address (URL) to a path on a domain that already resolves (for example network.example/brandx/). That re-homes the blog onto a working address instantly. Repairing the domain’s DNS is the alternative when the custom domain has to stay public.
Why does the parked domain return 200 OK if the site is unreachable?
Because the host serves a generic parking placeholder for any hostname it doesn’t recognise as an active site — and that placeholder is a real page, so it answers 200. The status code only tells you something responded, not that you reached your site. Read the response body (the REST root’s site name is a cheap signal) to confirm.
