Encountering 404 errors on your WordPress multisite subsites right after activating a network plugin can be both confusing and frustrating. One moment, all your permalinks are working perfectly across the network—and the next, your child sites return “Page Not Found” errors, rendering the content inaccessible. Thankfully, this issue is often more of a configuration hiccup than a deeper structural problem, and there are tried-and-true solutions that can restore your subsites back to proper functioning.
TL;DR
WordPress multisite 404 errors after activating a network plugin are often due to changes in permalink structure, .htaccess rules, or missing network settings. A quick reset of permalinks, checking and correcting your .htaccess file, and reviewing your network’s rewrite rules are essential repair steps. Often, the plugin may override certain settings that you can manually fix to restore site functionality. Scroll down for a comprehensive guide.
Understanding the Problem
WordPress Multisite is a powerful feature that allows you to run multiple websites on a single WordPress installation. However, it relies heavily on precise server rules and permalink structures. When you activate a plugin at the network level, especially one that modifies rewrite rules or deals with post types, it can accidentally interfere with the way subsites load their content.
The result? Suddenly every subsite returns a 404 error when you try to visit a post or page—even though the dashboard and homepage might still work just fine.
Common Symptoms of the Issue
- Subsites show 404 errors for all pages except the homepage
- Admin panels remain accessible
- Permalink settings are greyed out on subsites (in multisite, only super admins can change them)
- Error appeared immediately after activating a new plugin
Step 1: Reset the Network Permalinks via Main Site
Because subsite permalink settings are centrally controlled in a multisite network, one of the first things you should attempt is to “flush” the rewrite rules. Here’s how:
- Login to your main site admin (typically
example.com/wp-admin). - Navigate to Settings > Permalinks.
- Don’t change anything—just click Save Changes.
This forces WordPress to regenerate and flush the rewrite rules that control how your URLs resolve to actual pages. If a network plugin made changes to rewrite rules behind the scenes, this can usually resolve it.
Step 2: Manually Check Your .htaccess File
Sometimes the .htaccess file, critical for managing rewrite rules, gets overwritten or changed by the plugin. This file lives in the root directory of your WordPress installation and controls how URLs are translated behind the scenes.
Here’s what a default multisite .htaccess file should look like for subdirectory installs:
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
# Add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule . index.php [L]
If you’re using a subdomain install, it will be slightly different. Be sure to match it with the configuration WordPress recommends. If your plugin changed this file or removed these rules, manually restoring them could solve the 404 issues immediately.
Step 3: Network-Deactivate the Problematic Plugin
If the issue occurred right after activating a new plugin, especially one that handles SEO, custom post types (like CPT UI), or redirection functionality, it’s likely to be the culprit.
Here’s what to do:
- Go to the Network Admin > Plugins.
- Find the recently activated plugin and click Deactivate Network.
- Visit one of the subsites and check if the 404 errors persist.
If the errors go away, the plugin is either not multisite-compatible or is incorrectly handling rewrite rules across the network.
Step 4: Regenerate Rewrite Rules Customally
If the permalink flush didn’t work, and .htaccess looks fine, you may need to flush rewrite rules programmatically. You can add the following code temporarily to your theme’s functions.php file on the main site or use a custom mu-plugin:
function restore_multisite_rewrite_rules() {
global $wp_rewrite;
$wp_rewrite->flush_rules(true);
}
add_action('init', 'restore_multisite_rewrite_rules');
Important: This should be removed after it runs once, or else it can cause performance issues.
Step 5: Check Network Settings & Domain Mapping (if applicable)
If you’re using domain mapping or custom domains for your subsites, the plugin may have altered how domains are routed through your server. Inspect the following:
- Verify that DNS settings still point to your network’s IP address
- Check Site URLs in Network Admin > Sites > All Sites, especially if subsites use subdomains
- Ensure SSL redirect plugins aren’t interfering with how URLs resolve
If you’re using plugins like WP Multisite Domain Mapping, disable that plugin temporarily to test if routing returns to normal.
Step 6: Check .htaccess Conflicts from Other Plugins
Some plugins, like caching tools (W3 Total Cache, WP Super Cache) or security plugins (Wordfence, iThemes Security), modify the .htaccess file and add their own rules. These might unintentionally disrupt the expected flow of requests in a multisite environment.
To isolate the issue:
- Backup your current
.htaccessfile - Replace it temporarily with only the default WordPress multisite rules
- See if the 404 errors go away
- If they do, add back plugin-specific rules one section at a time
This investigative process can help identify a specific conflicting directive.
Step 7: Browser Caching & CDN Conflict
If everything seems fine but problems persist on the front end, check if a caching or CDN solution is delivering outdated or broken page caches:
- Clear your WordPress cache (via plugin if installed)
- Clear your browser cache and cookies
- Flush your CDN (like Cloudflare or BunnyCDN) to push a fresh version of rewrites
Sometimes changes do not propagate immediately, especially when external caching is involved.
Step 8: Debug with WP-CLI
Advanced users can use the WP-CLI tool to dig deeper. A quick command will flush rewrite rules without logging into the dashboard:
wp rewrite flush --network
This can be very effective in environments where the admin panel is hard to navigate or inaccessible.
Final Thoughts and Best Practices
Dealing with 404 errors across WordPress multisite can feel daunting, particularly when the network appears to “break” suddenly. However, most of these issues are related to how plugins interact with WordPress’s rewrite system and how servers interpret URL structures via the .htaccess file. With a methodical approach—starting from permalinks, checking .htaccess integrity, and identifying problem plugins—you can typically restore access without major headaches.
To prevent such issues in the future:
- Always test network-wide plugin activations on a staging environment first
- Keep a backup of your
.htaccessfile and wp-config.php - Document and track changes after network plugin activations
With these practices in place, you’ll be prepared to tackle any future 404 anomalies like a pro.
