If a child-site link shows Object not found, The requested URL was not found on this server, or an Apache 404, the request is usually failing before WordPress can identify the site or resolve its permalink. In a subdirectory network, the first suspects are the network’s root-level rewrite rules, Apache’s permission to read .htaccess, and—when a custom hostname is involved—the virtual host or server block that receives the request.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Work from the outside in: record which URLs fail, confirm the document root and network type, restore the official subfolder rewrite pattern, verify Apache or Nginx routing, then check WordPress URL values and PHP logs. The sequence below lets you fix the narrowest broken layer without changing database URLs or plugins unnecessarily.
As an Amazon Associate I earn from qualifying purchases.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Start by identifying exactly what is broken
Do not begin by replacing random rewrite snippets. Test the same network through a short set of URLs and record the HTTP result and the hostname shown in the address bar.
- Open the network home page.
- Open the home page of one child site in its subdirectory form, such as
https://example.com/child/. - Open one internal permalink on that child site.
- Open that site’s
/wp-admin/. - If the site has a mapped hostname, repeat the tests on that hostname.
Use the pattern in this table to choose your first check.
| Observed failure | Most likely boundary | First check |
|---|---|---|
| Network home, every child site, and every admin URL fail | Web-server document root, virtual host, or a completely ignored rewrite file | Confirm the host points to the WordPress network directory and that Apache/Nginx is serving that directory. |
| Home pages work but internal permalinks return an Apache 404 | Pretty-permalink rewrite rules | Compare the root .htaccess with the current WordPress subfolder pattern and verify mod_rewrite. |
Only /wp-admin fails or loops |
Missing trailing-slash rule or an incorrect site URL | Check the network rule that redirects wp-admin to wp-admin/, then inspect URL values. |
| Subdirectory URLs work but a mapped hostname fails | Virtual-host/server-block or domain-to-directory mapping | Inspect the host configuration and the mapped site’s domain record; DNS by itself is not enough. |
| Only one child site fails | That site’s domain/path mapping or a site-specific URL value | Compare its network record and URL values with a working child site before touching global rewrite rules. |
A working network home page proves only that one request reached WordPress. It does not prove that Apache is passing deeper paths to index.php, that the child-site path is registered, or that a custom hostname reaches the same document root.
Understand the routing path in a subdirectory network
A browser request passes through several layers:
- DNS sends the hostname to an IP address.
- The web server selects an Apache virtual host or Nginx server block.
- That host chooses a document root and applies its rewrite and access rules.
- PHP starts WordPress, which resolves the network, child site, and permalink.
An Object Not Found page normally indicates a break in the first three stages. WordPress cannot repair a request that never reaches its front controller. This is why editing a theme, deactivating a plugin, or changing a page slug rarely fixes a server-generated 404.
In a subdirectory network, the WordPress installation and the network’s .htaccess rules belong at the document root that serves the network. A subfolder installation is not repaired by pasting rules intended for a subdomain network or for a separate WordPress directory. The RewriteBase, the child-site path pattern, and the final fallback must match the network type.
Protect the site before changing configuration
- Make a database backup and copy the current
.htaccessandwp-config.phpfiles. - Prefer a staging copy. If staging is unavailable, schedule the change and keep a host or file-manager rollback path open.
- Record the current domain, path, and document-root settings before changing any URL.
- Use an administrator account only for the dashboard steps; use the host’s documented procedure for server-level changes.
Never replace a working file with an unverified snippet and then make several unrelated changes at once. A one-layer-at-a-time test leaves you a known cause and a reversible fix.
Restore the modern Apache rules for a subfolder network
Confirm the file is in the correct place
For a WordPress 3.5 and newer subfolder network, the network rewrite file normally sits in the document root alongside wp-admin, wp-content, wp-includes, and index.php. If your host serves the site from a nested directory, that nested directory—not the account’s general home directory—is the relevant root.
Do not put the network rules inside each child-site directory. WordPress expects one network-level rule set to see the child prefix, such as child/, and route the request centrally.
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 →Compare the rules, line by line
WordPress Developer Resources publishes the following pattern for WordPress 3.5+ Multisite subfolder networks. Use the exact rules generated for your installed version and network type; treat this as the reference pattern, not an invitation to combine legacy and modern examples.
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
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]Each section has a distinct job:
RewriteEngine Onenables rewriting, while the authorization rule preserves the HTTP authorization header for applications that need it.RewriteBase /states that the network is rooted at the host’s web root. A network installed below another URL path requires the value generated for that installation, not a copied slash from a different site.- The
index.phpexclusion prevents the front controller from rewriting itself. - The
wp-adminrule adds the trailing slash expected by the administration application. - The file and directory conditions allow real assets and directories to be served directly.
- The
wp-content,wp-admin, andwp-includespass-through rule handles those directories when a child-site prefix appears before them. - The PHP pass-through rule prevents legitimate PHP entry points from being swallowed by the final fallback.
RewriteRule . index.php [L]sends the remaining request to WordPress, where the network and permalink can be resolved.
A missing final fallback commonly produces the exact symptom in which the home page loads but every pretty permalink is an Apache 404. A wrong RewriteBase or a rule copied from a subdomain installation can instead break every child path.
Make sure Apache is actually allowed to use .htaccess
A perfect file has no effect if the server ignores it. Ask the host or inspect the Apache virtual-host configuration for two prerequisites:
mod_rewriteis enabled. Without it, rewrite directives are unavailable or skipped.- Overrides are permitted for the network directory. The relevant Apache directory block must allow the type of override used by
.htaccess, commonly through an appropriateAllowOverridesetting.
A support case documented Object Not Found responses because Apache was not evaluating the subdirectory’s .htaccess. If changing the file produces no change at all, that is a stronger clue than a malformed rule. Check the host’s Apache error log for messages about invalid directives or denied overrides, and ask the host to confirm which document root and directory block handled the request.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsAfter the host confirms rewrite support, test a real child permalink—not just the home page. A rewrite engine can be enabled globally while the specific network directory still disallows overrides.
Regenerate permalink rules from WordPress
If the dashboard is reachable, open Settings → Permalinks and select Save Changes without changing the structure. WordPress rewrites its permalink configuration and may restore the expected network rule file. On a Multisite installation, perform this from the network/site context that owns the affected settings.
Rank #3
If the dashboard itself returns Object Not Found, do not keep refreshing the page or change the site URL as a guess. Restore the known-good network rules manually, or have the host restore them, then return to the dashboard to save permalinks. A permalink refresh cannot help while Apache is ignoring the file or sending the request to another document root.
Repair URL and domain mapping after a hostname change
Distinguish a URL value from a host route
Changing a domain involves two independent systems:
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 →| Layer | What must match | Typical symptom when wrong |
|---|---|---|
| WordPress data | The affected site’s siteurl and home values, plus the network’s registered domain and path |
Redirects to an old hostname, mixed paths, login loops, or links that point to the wrong site. |
| Web-server configuration | The Apache virtual host or Nginx server block, its document root, TLS host, and PHP handling | An immediate server-generated 404 or an Object Not Found page before WordPress output. |
Verify the values in the database before changing them again in the dashboard. In a typical installation, the site’s options are stored in the prefixed options table; the network’s site records are stored in the corresponding Multisite tables. Table prefixes vary, so identify the actual prefix rather than assuming wp_. Read the current values first, compare them with a working child site, and make a backup before any update.
A domain-mapping change can fail even when the original network URL still works. A DigitalOcean Multisite report describes this pattern and directs the investigation toward the Nginx server-block configuration. DNS can point a name at the server, but only the correct host block can send that name to the directory containing this network.
Check the host configuration
For Apache, inspect the virtual host that matches the mapped hostname, its document root, rewrite allowance, and certificate host. For Nginx, inspect the matching server block, root, PHP location, and front-controller handling. Confirm that the mapped hostname is not landing in a default site or a different WordPress installation.
Make one host-level change at a time, reload the server using the host’s supported procedure, and test both the mapped hostname and the original network hostname. If only the mapped name fails, leave the working network untouched while correcting the host route.
Free tools Windows power users keep installed
One-click scans. No signup required.
Separate routing failures from PHP, theme, and plugin errors
Once the server is passing requests to WordPress, use temporary debug logging to determine whether PHP fails after routing. WordPress’s documented configuration is:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Insert these definitions in wp-config.php before the line that says That’s all, stop editing!. With logging enabled, reproduce the failing URL and inspect wp-content/debug.log. A PHP fatal error, theme exception, or plugin warning in that file points to an application layer; an empty log together with an Apache 404 points back to routing.
Use a staging copy or a recent backup before enabling debug constants. WordPress cautions against leaving debug mode enabled on a live site. Keeping WP_DEBUG_DISPLAY false prevents notices and stack traces from being sent to visitors while you collect the log.
Use symptom-specific branches when the first fix is not enough
Every child-site permalink fails, but the network home works
- Confirm the root
.htaccessis in the document root serving the network. - Compare
RewriteBase, the child-prefix pattern, and the finalindex.phpfallback with the official subfolder pattern. - Verify
mod_rewriteandAllowOverride. - Save Settings → Permalinks and retest a fresh permalink.
Only /wp-admin fails
Check whether the request is missing the trailing slash. The subfolder rules include a redirect from child/wp-admin to child/wp-admin/. If the redirect points to an old hostname or loops, inspect the affected site’s siteurl and home values and the host mapping.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows 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 reinstallA mapped hostname fails while the network hostname works
Do not rebuild all permalinks first. Verify that DNS reaches the intended server, then inspect the Apache virtual host or Nginx server block for the mapped name, document root, TLS configuration, and PHP route. Confirm the Multisite site record uses the intended domain and path. This branch is a host-routing problem until proven otherwise.
One child site fails while its neighbors work
Compare that site’s registered domain/path and URL values with a working site. Look for an accidental path change, a stale mapped domain, or a redirect that points outside the network. Global rewrite rules are less likely when other child prefixes resolve correctly.
The error started immediately after moving the installation
Reconfirm the new document root, copy the network-level .htaccess to that root, and check that the virtual host points there. Then verify URL values and save permalinks. Do not perform a second search-and-replace or broad database URL update until the current values and backup are documented.
Common mistakes that prolong the outage
- Using subdomain rules for a subdirectory network: the host and path pattern no longer match the request.
- Putting the file in a child directory: the network front controller never sees sibling child prefixes.
- Assuming DNS is domain mapping: DNS identifies an address; the server block still determines which site receives the request.
- Changing database URLs before checking the host: this can create redirects and login loops while the original routing error remains.
- Testing only the home page: a home page can be served directly while pretty permalinks still bypass WordPress.
- Combining snippets from different WordPress eras: legacy Multisite examples can conflict with the WordPress 3.5+ subfolder pattern.
- Displaying debug errors publicly: use the log with display disabled and turn debugging off after diagnosis.
- Trusting a cached redirect: browser, page-cache, or CDN data can preserve an old hostname after the server is fixed.
Retest and document the successful fix
After each change, use a private browser window and clear the relevant page or CDN cache. Verify all of these requests:
- the network home page;
- a child-site home page;
- an existing child-site permalink;
- the child site’s
/wp-admin/, including the trailing slash; - static files under
wp-content; - the mapped hostname, if one is configured;
- the original network hostname, so the fix did not break the primary route.
Record the final document root, host block, rewrite-file location, WordPress version, and any URL values changed. Turn off temporary debug logging, remove any publicly exposed backup copies of configuration files, and keep the working rewrite file with the site’s deployment records.
When to involve the host
Escalate with the exact failing URL, timestamp, hostname, and test results when you cannot access the virtual-host configuration, Apache modules, Nginx server blocks, or database. Ask the host to answer four specific questions: Which document root served the request? Did the matching host permit overrides or apply its rewrite rules? Was the request handled by the intended PHP front controller? Did the server log show a rewrite, permission, or upstream error?
Those answers identify whether the next action belongs in .htaccess, the host configuration, WordPress’s URL data, or PHP debugging. They also prevent a support agent from treating a server-generated Object Not Found page as a content or plugin problem.
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.
Recommended Free Tools
