WordPress multisite: fix new subsites returning 404

Define the failure: an entire subsite or only its posts

The network’s main site opens, but a recently created subsite displays a 404 error. The goal is to route its requests to the correct WordPress installation, then verify that WordPress recognizes its address and content. Creating a new post or installing a redirect plugin does not necessarily fix that route.

Start by distinguishing three situations. The browser finds no server for the subdomain: examine DNS. The server responds but the whole subsite address returns 404: check the saved address and routing. The subsite homepage works while posts fail: its permalinks become a more precise lead.

This guide concerns an actual self-hosted multisite network. Super administrator access is required for the site record and authorized maintenance access for server configuration. A subsite administrator should not bypass missing permissions. Managing several sites from a WordPress.com account does not provide these network or server permissions: this procedure does not apply merely to that grouping.

Keep exact URLs for the main site, a working subsite, and a failing new subsite. Note when the problem appeared, especially after migration or a server change. Comparing these three reference cases guides the changes to make.

Identify the network type and prepare a rollback

A subdirectory network uses paths, such as domaine.example/atelier/. A subdomain network uses distinct names, such as atelier.domaine.example. Both require routing, but a path needs no new DNS record whereas a server name must resolve.

Also note whether WordPress resides at the hosting root or in a particular directory. Identify the server actually handling requests: Apache, Nginx, an intermediary server, or several combined layers. A name in an HTTP header does not always describe the hosting architecture fully.

Before a network-wide change, preserve the required database and files along with relevant configurations. In particular, keep a private copy of wp-config.php and existing routing rules. Do not upload configuration containing secrets into a public site directory.

Do not change SUBDOMAIN_INSTALL to try the other network type. That change involves migrating addresses and other services, not local 404 troubleshooting. Rollback must match each targeted change: previous subsite address, rules block, or server configuration.

Confirm the subsite exists in the intended network

With the authorized network account, open My Sites, Network Admin, Sites, then All Sites. Find the affected subsite. Open its record without editing values and compare the saved domain or path with the failing address. Also use its Visit link to avoid an address reconstructed from memory.

Record displayed states, including any archived or spam designation. An intentional state must be examined with the owner before modification. If the record is missing, check that you are viewing the correct network and creation actually completed; do not recreate several same-named sites to test.

If WP-CLI is already available to the maintainer, the command below provides a comparable inventory. Replace the path with the actual installation root; do not publish output, as it may reveal private subsites. This reads sites without creating or deleting any.

The expected result is one record with the intended address. A correct list validates neither the web server nor DNS: it shows only what this WordPress installation knows. If the command targets another directory, stop this diagnosis and correct its target.

wp --path="/chemin/reseau-wordpress" site list --fields=blog_id,domain,path,url,archived,spam,deleted --format=table

Correct only an obviously wrong subsite address

If the record reveals a definite domain or path typo, first record its initial value and the actually intended address. In Network Admin, Sites, Edit, examine the Info tab and site-address field. The precise field organization depends on network type and version.

A correction is appropriate, for example, for a mistyped character during creation after confirming the intended name. It may also update home and siteurl options when they matched the subsite’s old address. This is therefore not merely a label. If those options are customized or already differ, have their configuration examined instead of replacing them with SQL.

Do not automatically replace network constants or every subsite’s address to fix this one record. If a custom domain was just attached, its routing and certificate must already be prepared. An address correctly saved in WordPress does not create these external services.

If the correction was wrong, restore the value recorded before saving and check recovery. If a login redirect or old domain persists, record that new observation instead of making several successive replacements. It may be a domain or login issue separate from the original 404.

1. Confirm the affected subsite, current address, and expected address in its record.
2. Keep initial values and checked states without editing other fields.
3. Correct only the definite address typo, then save once.
4. Reopen the record, use Visit, and check the final address and administration.
5. If the correction does not match the intended site, restore the recorded address and check again; stop if a custom address does not follow that rollback.

Compare the subsite homepage, a post, and administration

From the network record, open the subsite homepage. Then open an existing post and administration at the corresponding address, with the trailing slash in wp-admin/. For each request, record the final address and result. A redirect to another site is different from a not-found page.

If homepage and administration both fail, first examine arrival at the correct installation and its network rules. If administration works and only one post fails, check that the content exists and is accessible under its intended status. A draft inaccessible to visitors does not demonstrate a global permalink failure.

In a subdirectory network, subsites are virtual. Normally, you do not need to create a physical directory named atelier and copy WordPress into it. A real directory with that name may even intercept some requests before network rules; have an existing conflict examined without blindly deleting its contents.

In a subdomain network, verify that the subsite name reaches network hosting and its certificate matches. If not, complete this arrival diagnosis before changing WordPress permalinks.

Apache approach: restore rules specific to this network

This approach suits hosting that actually uses Apache to apply WordPress rules and a maintainer with access to the relevant file. In network administration, Settings, Network Setup, find generated instructions for this installation when available. The menu depends in part on network configuration; do not change constants merely to display a button.

Compare this block with WordPress rules in the .htaccess serving the shared installation. Single-site, subdomain-network, and subdirectory-network examples are not interchangeable. An older multisite activation may also use a different legacy mechanism.

The correct fix must restore routing for the new site without disrupting the rest of the network. If generated instructions are absent or no longer match current architecture, send configuration to the maintainer instead of selecting a single-site block.

1. Confirm the served root and download a private copy of the current .htaccess.
2. Compare WordPress rules with this network’s instructions: subsite type, installation directory, and history.
3. Replace only the confirmed block, preserving protections and host directives.
4. Do not add a competing second block; save the file in its verified location.
5. Immediately check the main site, reference subsite, and new subsite.
6. If a 500 error appears or reference cases regress, immediately restore the retained file, check recovery, and record the error.

Check whether Apache actually applies the modified file

If the correct block changes nothing, confirm the file and directory actually served for this domain. Several installations may coexist in one hosting account. Editing a copy’s or old directory’s .htaccess naturally leaves the subsite request unchanged.

The server maintainer must then check that the rewrite module is loaded and directory configuration allows the relevant directives. Apache may ignore .htaccess files depending on settings. Giving the file more write permissions does not activate those directives.

Request a precise scope check: network virtual host, document root, and directive permissions for that directory. A global server change or very broad AllowOverride is not an automatic answer to this failure. On managed hosting, send these details to the operator with that access.

The expected result is a verified explanation of where rules apply. If rules are managed directly in main configuration, have that level corrected instead of multiplying local files. Preserve previous configuration and results from the same URLs to compare the change’s effect.

Nginx approach: correct routing in the right server block

Nginx does not read .htaccess rules. This approach concerns a maintainer authorized to change web configuration after identifying the file used for the network domain. Preserve the previous server block, document root, PHP settings, and HTTPS directives.

For a subdomain network, confirm that required names match the block serving the same WordPress installation. A response from Nginx’s default site may explain a 404 even when DNS points to the correct machine. Server aliases and the certificate are separate elements.

In a setup already configured to execute PHP, with WordPress at the root and the correct server block selected, path routing must be able to fall back to index.php. The snippet below illustrates that point within the existing location block; it is not a complete replacement server file.

A subdirectory network may also require multisite-specific rewriting of administration and PHP-file paths. Use the model matching the installation and its history. Do not replace custom configuration with this snippet alone or add a competing second location /.

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

Validate a Nginx change before reloading

After the prepared correction, the maintainer must test configuration actually used by the service. The command below targets the called binary’s default configuration. If hosting uses a specific path or parameters, use those from the service; testing another Nginx installation does not validate the active server.

The check examines syntax and attempts to open referenced files. An error requires fixing or restoring the backed-up file before any reload. Do not repeatedly restart the service to try to make the error disappear.

If checking succeeds, the maintainer applies the host’s intended reload procedure, then verifies reference URLs. Syntax success does not demonstrate that domains match the correct block, the certificate is suitable, or WordPress recognizes the subsite.

If routing regresses after application, restore the preserved configuration, validate it again, then reload through the same authorized procedure. This rollback must preserve other server sites. A WordPress administrator lacking these permissions sends the record and proposed change without trying to run these operations through a plugin.

nginx -t

Regenerate permalinks only for the affected subsite

This approach becomes relevant when WordPress receives the request and the subsite homepage works but existing posts remain missing. Open administration for that exact subsite. Check its name and address in the top bar to avoid accidentally changing the main site’s settings.

The expected result is correct resolution of the reference post with existing settings. The operation writes calculated rules for this subsite; it is not merely inspection.

This regenerates WordPress rules; it does not create DNS or reconfigure Nginx. If the entire subsite still returns 404 before WordPress even loads, return to routing. Repeated saves will not replace missing configuration.

Do not temporarily switch the whole network to a different structure. If a value was changed inadvertently, restore the recorded value and save the affected subsite. Also check pages and any custom content types: their rules depend on components actually loaded for this site.

1. Open Settings → Permalinks in the confirmed subsite dashboard.
2. Record the selected structure and custom bases without changing them.
3. Click Save Changes once.
4. Open the published reference post logged out, then a page and custom content if present.
5. If a value changed accidentally, restore the recorded value and save only on this subsite.

Use WP-CLI as a targeted regeneration alternative

A maintainer already equipped with WP-CLI can regenerate WordPress rules for the selected subsite. Replace the installation path and full URL with the values confirmed in the inventory. In multisite, --url targets the site whose context must load.

The following command writes this site’s rewrite rules to the database. Preserve permalink settings and have a restorable data copy before execution, then check the reference post. If the component registering a content type is absent, regeneration may only reflect that incomplete state; it does not recreate the component.

Do not add --hard to rewrite the network .htaccess. That option’s documentation limits it to single-site installations. Nor should you turn the example into a loop over every site: diagnosis concerns one identified target.

The success message confirms command execution, not the HTTP result. Verify the address in the browser afterward. If content does not return, keep the result and resume comparing routing, address, and components. Returning to previous settings must happen on this target without blindly restoring the entire network database.

wp --path="/chemin/reseau-wordpress" --url='https://reseau.example/atelier/' rewrite flush

Rule out an old cache or specific component without hiding the failure

After a demonstrated fix, a cache may still serve the previous 404. An Incognito session mainly removes some browser state; it does not bypass shared caching. Compare the same URL with the host’s documented checking mechanism, or have the maintainer verify logs and headers. If caching is confirmed, refresh only affected addresses through the existing tool.

A redirect plugin is not a substitute for network routing. Redirecting the subsite homepage to the main site would make its content disappear instead of making it accessible. A broken-link tool may inventory URLs but configures neither the virtual host nor shared server rules.

If a recent component change coincides with the failure, reproduce it on a network copy with a separate database and external effects disabled before use: emails, payments, and integrations must not contact production services. Examine subsite plugins, network-activated plugins, and must-use components separately. Network deactivation may affect working sites; it must not be the first public test.

The expected result is an explicit connection between a correction and observed behavior. Keep original settings and change only one verified cause at a time. Without that separation, it becomes difficult to know whether the subsite works through correct routing or only through a redirect still bypassing the problem.

Validate the network and keep a usable diagnostic record

Repeat the same reference cases after each retained fix: main-site homepage, main-site post, working subsite, and new subsite. For the latter, check homepage, a post, media resource, and administration access. One restored page does not demonstrate correct handling of every path.

Keep final addresses, useful messages, and the change made. If the failure persists, provide network type, installation path, server actually handling routing, and compared URL results. Add the subsite record and useful configuration excerpt with secrets removed.

Do not delete the subsite to recreate it before preserving its data and understanding the cause. That operation may change identifiers while leaving the same routing cause intact. Do not create additional WordPress directories to imitate virtual paths either.

Once resolution is verified, keep validated configuration with the procedure for creating future sites. A new-subsite check must include its name or path, arrival at the network, and internal pages. This helps detect a regression at the next hosting change without rewriting every site’s settings.

Choose the right guide according to the first failing check

If the browser cannot find the subdomain, first record the DNS response for that name and a working subsite. The unavailable-multisite-subdomain diagnosis distinguishes an individual record, wildcard rule, and subsite state in WordPress.

If several addresses changed after switching between subdomains and subdirectories, revisit the inventory before correcting permalinks. The multisite network switching and rollback guide helps test new addresses on a copy and preserve old destinations.

If the name responds and the expected server displays 404, continue with this guide’s address and routing checks. Keep a working subsite as a reference, then check a known page on the affected subsite.

Find both procedures in the related guides below.

Compare four paths across three reference sites

Prepare a grid with three columns: main site, old working subsite, and new failing subsite. For each, open the homepage, a published post, a known image, and administration access. Record the final URL and actual status; do not create a physical file or directory named after the subsite to try to resolve a virtual address.

In a subdirectory network, a working homepage with posts returning 404 points toward rewrite rules or their conditions; images failing alone also require checking their actual paths. In a subdomain network, a new name that does not even reach the server must be handled before permalinks. These observations guide investigation without proving the cause alone: a cache or proxy may also respond instead of WordPress.

For the server administrator, compare document roots and configuration actually loaded for reference names. Changing the right file on another virtual host will have no effect. Also check whether a real directory masks a path intended for WordPress, without moving it before identifying its owner.

Success requires the new site to regain all four paths while the old site stays functional. If the changed rule repairs the new site but breaks the old one, restore only that rule. Native network configuration is sufficient here; a redirect plugin risks concealing the routing defect without fixing it.