Back to Community
Home / Community / Core → Networking wordpress

Fixing WordPress Multisite Redirects: A Troubleshooting Guide

49 threads Sep 16, 2025 Core → Networking wordpress

Content

WordPress Multisite is a powerful tool for managing multiple websites from a single installation. However, one of the most common and frustrating issues users encounter is incorrect URL redirection. Instead of landing on the correct subsite, visitors—and even administrators—are often redirected to the main network site, a signup page, or a 404 error.

Why Do Multisite Redirects Happen?

Based on community reports, these redirect errors are rarely caused by a single "bug" in WordPress core. Instead, they typically stem from a misconfiguration in one of several areas:

  • Domain Mapping Setup: The built-in domain mapping feature requires precise configuration in WordPress and correct DNS records at your hosting provider.
  • www vs. non-www Mismatch: If a subsite's "Site Address (URL)" is set to https://www.example.com but a user visits https://example.com (or vice versa), WordPress may not recognize it as a valid site in the network and redirect to the main site.
  • Subdomain/Subdirectory Configuration: The entire network is defined at installation as either a subdomain or subdirectory setup. You cannot mix them; a subdomain network cannot host a subdirectory site without complex rewriting rules that often cause cookie and login loops.
  • Caching Issues: Aggressive object caching (e.g., Redis) or browser/DNS caching can serve old, incorrect redirects.
  • Manual Database Changes: Manually changing site URLs in the database without updating all necessary records can break the site's registration within the network.

Common Solutions to Try

1. Standardize Your www Usage

A recurring theme in the support threads is inconsistency with www. The solution is often to enforce one version.

  • In WordPress: Ensure the "Site Address (URL)" for every site in Network Admin -> Sites -> Edit Site uses the exact same protocol and www-preference (e.g., all https://www.example.com or all https://example.com).
  • In .htaccess (Apache): Use server-level redirects to enforce your chosen standard before the request is processed by WordPress. This is often the most reliable method.
# Force www
RewriteCond %{HTTP_HOST} ^example.com [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]

# Force non-www
RewriteCond %{HTTP_HOST} ^www.example.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

2. Verify Domain Mapping Configuration

If you are using WordPress's native domain mapping for a subsite:

  1. Set the DNS: Point your custom domain's A record to your server's IP address at your domain registrar. This is a critical step often missed.
  2. Set the Site Address: In Network Admin -> Sites -> Edit Site, change the "Site Address (URL)" to the full custom domain (e.g., https://mycustomdomain.com).
  3. Check the Server: Ensure your web server (e.g., Apache/Nginx) is configured to accept requests for that custom domain and direct them to the WordPress installation.

3. Clear All Caches

If a configuration change doesn't take effect immediately, clear these caches:

  • Browser Cache: Hard refresh (Ctrl+F5) or clear your browser's history and cached images.
  • DNS Cache: Flush your local DNS cache or use a different network to test.
  • Object Cache: If you use Redis or Memcached, flush it from your hosting panel or using a plugin.
  • WordPress Cache: Clear any caching plugin(s) you have running.

4. Check Your .htaccess File

An incorrect or outdated .htaccess file is a common culprit. For a subdomain Multisite install, ensure your file contains the standard WordPress Multisite rules. Do not add complex rewrite rules for subdomain-to-folder paths on a subdomain network, as this will cause conflicts.

5. Re-save Permalinks

Sometimes, a simple fix is to visit Settings -> Permalinks on the affected subsite and click "Save Changes" to refresh the rewrite rules.

When to Seek Further Help

If these steps don't resolve the issue, the problem may be more complex, such as a plugin conflict (e.g., a deprecated domain mapping plugin) or a deep database inconsistency. In these cases, enabling WP_DEBUG in your wp-config.php file can reveal underlying errors. The broader WordPress community, on forums or development blogs, can often provide guidance for these edge cases.

Related Support Threads Support