How WordPress Subdomains on a Shared Host Began Showing ERR_TOO_MANY_REDIRECTS After a Plugin Update and the Cookie Domain Fix I Applied

Recently, I encountered a frustrating issue that brought down several of my WordPress subdomain sites hosted on a shared server. The error message “ERR_TOO_MANY_REDIRECTS” appeared out of nowhere shortly after a routine plugin update. This situation not only disrupted user access but affected search engine indexing and credibility. After some investigation, I found the culprit and applied a cookie domain fix that resolved the problem across all subsites.

TL;DR

WordPress subdomains under a single multisite installation began returning the ERR_TOO_MANY_REDIRECTS browser error after a plugin update. The issue was traced to how cookies were being handled, especially regarding domain scope. By updating the cookie domain definition in wp-config.php, the redirect loop stopped. If you’re seeing recurrent redirects on WordPress subsites, check your cookie domain settings first.

Understanding the Problem

My hosting environment involved a few WordPress installations, one of which was a multisite setup using subdomains (like sub1.example.com, sub2.example.com, etc.) rather than subdirectories. Everything was running smoothly until I updated several plugins across the network.

Soon afterward, all subdomains started throwing the ERR_TOO_MANY_REDIRECTS error in Chrome and similar messages in other browsers. Clearing browser cookies and caches didn’t help. Eventually, even the dashboard became inaccessible on those subdomains.

Initial Troubleshooting

I began checking system logs, browser developer tools for redirect chains, and .htaccess rules, suspecting an accidental rewrite or misconfiguration. Here are the steps I took:

• Disabled all plugins via WP-CLI and verified the main domain worked.
• Confirmed that SSL certificates were valid and no mixed content was causing infinite redirects.
• Reviewed wp-config.php and .htaccess for improper redirects or custom login flows.

After isolating the problem to plugin-related changes, I tried re-enabling the plugins one-by-one. Eventually, I discovered that a popular security plugin introduced cookie security enhancements in the update, which interfered with my multisite cookie behavior.

The Underlying Cause: Bad Cookie Domain Handling

WordPress uses cookies for authentication sessions. When you’re managing a multisite network with subdomains, cookie scoping becomes critical. Normally, WordPress sets its auth-related cookies like so:

Set-Cookie: wordpress_logged_in_HASH=...; path=/; domain=.example.com

This line tells the browser to send the cookie to all subdomains of example.com. However, after the plugin update, the plugin forced WordPress to reset the cookie domain to sub1.example.com, which broke the expected behavior across the network.

The result was a perpetual redirect loop: a user visited sub1.example.com, the cookie didn’t validate properly, redirect rules tried to force logins or redirect back, and the cycle repeated. That’s when the browser finally gave up and threw the redirect error.

Additional Observations

Chrome developer tools showed up to 20 chained 302 redirects. Also, Apache logs contained numerous entries with status code 302 for the same endpoint, revealing the loop’s path.

The Fix: Define COOKIE_DOMAIN Explicitly

Understanding that the cookies were being scoped improperly, I corrected the behavior by explicitly setting the COOKIE_DOMAIN and COOKIEPATH in the wp-config.php file for the affected WordPress installation.

I added the following lines above the comment that says, “That’s all, stop editing!”:

define('COOKIE_DOMAIN', '.example.com');
define('ADMIN_COOKIE_PATH', '/');
define('COOKIEPATH', '/');
define('SITECOOKIEPATH', '/');

These definitions ensure that authentication and session cookies work uniformly across all subdomains. The dot before example.com in COOKIE_DOMAIN is essential, as it enables subdomain access where needed.

Why the Plugin Update Triggered This

The plugin that caused the issue made changes to enhance cookie security enforcement, specifically to block third-party cookie usage. It attempted to isolate cookies to single domains, assuming the site wasn’t multisite-enabled with subdomains. That mismatch caused the new cookies to be inaccessible to other subsites, corrupting login states and breaking access loops.

Even though such security enhancements are generally good practice, the plugin didn’t account for multisite use with subdomains—a critical edge case for large installations.

Lesson Learned

• Always review changelogs and documentation for plugins before updating on critical environments.
• Test in a staging environment before pushing updates to a live multisite network.
• Cookie behavior is foundational in WordPress for login and session management—know how it works!

Alternate Workaround: Network Admin vs Regular Admin Sessions

As a temporary measure before applying the config fix, I was able to log into the main network dashboard at example.com/wp-admin/network, which had a different cookie scope due to the non-subdomain path. From there, I managed plugin settings and disabled the offending module until the permanent fix could be applied.

Additional Considerations

If you are using services like Cloudflare, some caching or redirect rules might further exaggerate the problem. Review any Page Rules or SSL settings (especially “Always Use HTTPS” or “Auto HTTPS Rewrites”) that might interfere with redirects or cookie persistence.

Also, if you’re dealing with HTTPS-only sites, consider whether secure flags are being set correctly on cookies. A missing or incorrect secure cookie may cause the browser to ignore it entirely if the site’s served over HTTPS.

Preventing Future Recurrences

I implemented several changes to ensure this issue doesn’t crop up again:

• Locked plugin versioning with composer.lock in development.
• Enabled automatic testing of plugin updates using WP-CLI in a dockerized staging environment.
• Documented cookie and redirect behavior handling in the project’s internal wiki.

Lastly, I made it a point to contribute feedback to the plugin developer’s support forum, explaining the problem in detail and requesting better subdomain multisite handling or at least a toggle for using custom cookie domain logic.

Conclusion

Redirect loops like ERR_TOO_MANY_REDIRECTS can bring down WordPress subsites and are often caused by subtle misconfigurations. In my case, a plugin update changed cookie behavior without accounting for multisite subdomain setups. By explicitly defining the COOKIE_DOMAIN and fellow constants in wp-config.php, I quickly restored order. Understanding the anatomy of WordPress cookie handling is crucial—especially when managing complex multi-domain setups under a shared host architecture.

If you’re facing similar redirect errors after a plugin update on multisite WordPress with subdomains, your first area of inspection should be cookie domain settings. Don’t overlook the tiny config constants—they might just prevent a giant headache.