How to Fix the Too Many Redirects Error on WordPress

Understanding Redirect Loops: The Complete Technical Picture

The error message varies slightly across browsers, but the underlying cause remains the same. Different browsers use different error codes and messages to communicate the same redirect-loop problem to users, which can confuse the root cause.

Why Redirect Loops Lock You Out of Your Admin Area

When a redirect loop activates on your WordPress site, your browser typically cannot access the WordPress admin dashboard or login page either. This occurs because the browser gets stuck in the redirect loop before WordPress core files even load. Server-level redirect rules fire before WordPress processes any requests, so you can’t log into the admin panel to fix URL settings through the graphical interface.

Instead, you must access your hosting control panel, use SFTP to edit files directly, or use command-line tools to modify the WordPress configuration. This access requirement is why understanding the different layers where redirects can occur- browser cache, WordPress plugins, WordPress settings database, server-level Apache configuration files, content delivery networks, and SSL certificate settings- becomes so valuable.

Niya Digital’s support team has observed that most redirect loops emerge within 48 to 72 hours after a site migration, an SSL certificate installation, or a major plugin update. These are precisely the moments when multiple redirect configuration layers are transitioning at the same time and may conflict with one another. The likelihood of redirect issues increases dramatically when site owners make changes without verifying that all redirect layers remain aligned afterward.

How Redirect Loops Manifest Across Different Browsers and Contexts

Different web browsers display redirect loop errors with different wording and error codes, though the underlying issue remains identical. While the exact message varies, the fundamental problem is always the same: a circular redirect pattern that the browser cannot resolve. This variation in error messages can make it unclear whether the problem originates in the browser, the operating system, or the server. In reality, redirect loops are purely server-side issues. The browser is merely reporting that the server configuration is sending contradictory redirect instructions.

WordPress Pricing Plans

Choose the WordPress hosting plan that fits your website needs, with reliable performance, security, storage, backups, and tools to help your site grow.

WordPress Basic

$8.99 per month

A great way to get started.

• 1 website
• 10 GB NVMe storage
• Unmetered bandwidth
• Free SSL Certificate *
• WordPress pre-installed
• Weekly backups
• Web Application Firewall
• Daily malware scans
• One-time malware removal

Order Now

WordPress Deluxe

$11.99 per month

Improve your site performance with Cloudflare CDN.

• 1 website
• 20 GB NVMe storage
• Unmetered bandwidth
• Free SSL Certificate *
• WordPress pre-installed
• Daily backups
• Web Application Firewall
• Daily malware scans
• One-time malware removal
• Up to 2x faster performance with global Cloudflare CDN **
• Enhanced security with DDoS protection
• Staging site

Order Now

WordPress Ultimate

$15.99 per month

Add online marketing with more sites, storage and security.

• 1 website
• 30 GB NVMe storage
• Unmetered bandwidth
• Free SSL Certificate *
• WordPress pre-installed
• Daily + on-demand backups
• Web Application Firewall
• Daily malware scans
• Unlimited malware removal
• Up to 2x faster performance with global Cloudflare CDN **
• Enhanced security with DDoS protection
• Staging site
• WordPress code optimizer
• Smart WordPress plugin manager
• Sell online with WooCommerce

Order Now

The WordPress Address and Site Address Settings: Foundation of Proper Configuration

The “WordPress Address (URL)” specifies the exact filesystem path where your WordPress core files are located on your hosting server. The “Site Address (URL)” specifies the public-facing URL that visitors type into their browser to reach your website. In most standard WordPress installations, both fields contain identical URLs.

Identifying and Correcting URL Setting Mismatches

Before attempting more complex troubleshooting, verify that both URL fields in your WordPress settings are correct. If you can still access your WordPress admin dashboard (you’re lucky; many redirect loops prevent this), navigate directly to Settings > General. Examine both fields carefully. The WordPress Address should match exactly where your WordPress files live on your server, and the Site Address should match the domain that your web server is configured to serve, including the correct protocol (https:// if you have an SSL certificate installed, http:// only if you genuinely don’t have SSL). Both fields must also account for any subdirectory structure; if WordPress is installed in a /blog/ subdirectory, both fields should reflect this: https://yourdomain.com/blog.

If you’ve recently migrated your WordPress installation to a new server or domain, these fields are among the most common culprits behind redirect loops. During migrations, these settings often point to temporary staging domains, the previous host’s configuration, or test environments that no longer exist. After migration, the URLs must be updated to reflect the new permanent location. Similarly, if you’ve just installed an SSL certificate and switched from HTTP to HTTPS, update both fields to use https:// instead of http://. Many redirect loops occur when the certificate is active but WordPress hasn’t been updated to reflect the protocol change.

Accessing URL Settings When Locked Out of the Dashboard

If you cannot access your WordPress admin area because of the redirect loop, you’ll need to change these critical settings through alternative methods. You can edit the WordPress configuration directly through your hosting provider’s database management tool (typically phpMyAdmin, which provides a graphical interface to your MySQL database).

Locate the wp_options table within your WordPress database. Find the rows labeled “siteurl” and “home” and update their values to match your actual domain and protocol. Alternatively, you can access your files via SFTP and edit the wp-config.php file, adding hard-coded constants for WP_HOME and WP_SITEURL. This method ensures WordPress uses your specified URLs regardless of database settings. However, it prevents you from changing these settings through the WordPress dashboard until you remove the constants.

Common WordPress URL Misconfigurations and Their Effects

Each row in this table represents a scenario that either prevents redirect loops or directly causes them. The most important principle is that both fields must match in domain name, protocol, and any subdirectory structure; they must match what your web server is configured to serve.

WordPress Plugin Conflicts: Identifying Problematic Extensions

Plugin conflicts are also more likely when multiple plugins try to manage the same type of redirect. For example, if you’re running both an SEO plugin and a dedicated “Redirection” plugin, they may both try to manage URL redirects, creating competing rules. Additionally, a poorly coded plugin update can introduce bugs in how the plugin handles redirects, sometimes creating loops that didn’t exist before the update was installed.

Systematic Plugin Testing to Isolate the Culprit

The most reliable method to determine whether a plugin is causing your redirect loop is to disable all plugins systematically, then re-enable them individually while testing your site after each change. This binary-search approach for identifying problematic software is an industry-standard troubleshooting technique. Begin by connecting to your hosting server via SFTP (Secure File Transfer Protocol) and navigating to the wp-content directory. Rename the plugins folder from “plugins” to “plugins-old”. WordPress will deactivate all installed plugins instantly (the plugins remain intact and aren’t deleted; they just aren’t loaded). Now attempt to access your website. If the redirect loop vanishes, you’ve confirmed that one of your plugins is the cause. If the loop persists, the issue lies elsewhere.

If renaming the plugins folder resolved the loop, rename it back to “plugins” and begin selective testing. Using SFTP, rename individual plugin folders one by one. For example, rename “really-simple-ssl” to “really-simple-ssl-disabled”, then test your site. When the loop returns after renaming a specific plugin, you’ve identified the culprit. This systematic approach is time-consuming but highly reliable. Keep detailed notes of which plugins you’ve tested and which one causes the loop. Once identified, you can check whether the plugin has a known issue, look for conflicting settings, update to a newer version, or replace it with an alternative.

Understanding SSL Plugin Interactions with Server Configuration

SSL and HTTPS plugins warrant special attention because they operate at multiple configuration layers simultaneously. These plugins add redirect rules to your .htaccess file (the Apache server configuration file), which means they compete with any server-level HTTPS redirects your hosting provider may have already configured. If your hosting provider is already forcing HTTPS at the server level and you’ve also installed an SSL/HTTPS plugin, two separate redirect rules targeting the same outcome can create a loop. Disable the plugin and rely exclusively on your server’s built-in HTTPS configuration. Most managed WordPress hosting providers handle HTTPS redirects at the server layer, making dedicated SSL plugins redundant and potentially problematic.

Browser Cache and Cookies: The Fastest Troubleshooting Step

This layer is especially deceptive because it can make it seem like the server-side issue persists even after you’ve fixed it. You make a configuration change, verify that it should work, but when you reload your browser, you still see the redirect loop. You assume the fix didn’t work. In reality, your browser is serving you cached data from before the fix. You can avoid this frustration by clearing your cache before testing any redirect-related fixes.

Clearing Cache Across Different Browser Interfaces

Different browsers organize their cache-clearing functions in different places, but the underlying principle remains the same across all modern browsers. Most browsers provide keyboard shortcuts to open the cache-clearing dialog. Use Ctrl+Shift+Delete on Windows systems or Cmd+Shift+Delete on Mac systems in most browsers. This opens the “Clear Browsing Data” or “Clear History” dialog. You should select “All time” or “Everything” to ensure you’re clearing cache from well before your redirect loop started. Check both the boxes for “Cookies and other site data” and “Cached images and files” to ensure you’re removing both cached pages and the cookies that might be storing redirect preferences. Click the “Clear” button to remove the cached data.

After clearing the cache, close your browser entirely and reopen it before testing your site again. Some browsers maintain cache data in memory until you fully close them. By closing and reopening, you ensure that your browser reloads everything fresh from the server without relying on any previously cached data. This gives you the most accurate test of whether your server-side fix actually works.

Testing with Incognito or Private Browsing Windows

A faster way to test whether the server-side issue is genuinely fixed, without waiting for cache clearing to complete, is to open an incognito window (Google Chrome) or a private window (Firefox, Safari, Edge). These modes don’t access your browser’s cache. They don’t use cookies. They don’t maintain any stored preferences from previous browsing. Type your domain into the address bar in the incognito window and press Enter.

If your site loads successfully in the incognito window but still shows the redirect loop in your regular browser window, this confirms that your server-side configuration is fixed. Your normal browser cache still contains stale redirect data. Return to your regular browser window, clear the cache as described above, and you’re done. If the redirect loop appears even in an incognito window, the problem persists on the server, and you need to keep troubleshooting your server configuration.

Why Cache Persists and How It Affects Visitors

Browser cache has configurable expiration times. Cache can persist for hours, days, or weeks depending on how the server configured the cache headers. This means visitors to your site might encounter the cached redirect loop long after you’ve fixed the server configuration, if they visited your site while the loop was active. If many visitors encountered the loop before you fixed it, they’re carrying cached redirect data that will make them see the loop again on their next visit.

The only way to clear their cached data is to wait for it to expire naturally or for them to clear it manually. This is why fixing redirect loops quickly is important; every hour the loop persists adds more visitors to the pool of people carrying cached redirect data.

SSL Certificates and HTTPS Configuration: The Hosting-Layer Foundation

For HTTPS to work correctly, four distinct layers must be aligned:

(1) A valid SSL certificate installed on your server and listening on port 443;

(2) Your web server (Apache, nginx, or LiteSpeed) configured to return a 301 redirect from HTTP to HTTPS for every request;

(3) WordPress configured to use HTTPS in its URL settings and to force HTTPS for all requests; and

(4) All internal site links using HTTPS consistently rather than mixing HTTP and HTTPS URLs.

If any one of these four layers contradicts the others, a redirect loop results. Understanding this alignment requirement is crucial for preventing HTTPS-related redirect loops.

Verifying Your SSL Certificate Is Installed and Active

Before making any HTTPS-related configuration changes in WordPress, verify that your SSL certificate is installed and working. Open your web browser and navigate directly to https://yourdomain.com (note the https:// protocol). Does the page load successfully? Does your browser display a padlock icon or green security indicator in the address bar? If both answers are yes, your SSL certificate is installed, active, and properly configured. If your browser shows a warning message (such as “not secure,” “certificate not valid,” or a mismatch warning), your SSL certificate has an issue that must be resolved before you configure WordPress to use HTTPS.

If your SSL certificate is not yet installed, do not enable “Force HTTPS” in WordPress or install an SSL enforcement plugin. Doing so creates an immediate redirect loop: WordPress redirects to HTTPS, the server can’t handle HTTPS and redirects back to HTTP, and WordPress tries HTTPS again. You’ll trap yourself in a loop and lose access to your WordPress dashboard. Contact your hosting provider to install or activate your SSL certificate first. Only after verifying that https:// works in your browser should you enable HTTPS enforcement in WordPress.

Configuring WordPress HTTPS Settings Correctly

Once you’ve verified your SSL certificate is active, you can safely enable HTTPS in WordPress. Navigate to Settings > General in your WordPress dashboard. Locate the “WordPress Address (URL)” and “Site Address (URL)” fields. Both should begin with https:// instead of http://. If they currently show http://, click into each field, add the “s” to make them https://, and save your changes. WordPress will now serve all pages over HTTPS and redirect any HTTP requests to HTTPS.

Alternatively, you can use an SSL/HTTPS plugin to force HTTPS, but do this only after verifying that your certificate is active and only if you’re confident the plugin won’t conflict with server-level HTTPS redirects. Your hosting provider may have already configured server-level HTTPS redirects in the Apache configuration or .htaccess file. If the plugin adds another HTTPS redirect, two rules targeting the same outcome can create a loop. Most managed WordPress hosting providers handle HTTPS enforcement at the server level, making dedicated HTTPS plugins unnecessary and potentially problematic.

Detecting and Resolving .htaccess HTTPS Conflicts

Your hosting provider may maintain a server-level HTTPS redirect in your .htaccess file or in the web server configuration. If you then install an SSL/HTTPS plugin, it adds another HTTPS redirect to .htaccess. Two separate rules trying to force HTTPS can sometimes create a loop, especially if the rules use slightly different conditions or are placed in conflicting order within the .htaccess file.

To test whether .htaccess is the culprit, rename your .htaccess file temporarily (rename it to .htaccess_old via SFTP), clear your browser cache, and attempt to access your site. If the redirect loop disappears, your .htaccess file contained conflicting rules. Delete the renamed .htaccess_old file. Visit your WordPress dashboard and re-save your Permalink settings (Settings > Permalinks > Save Changes). WordPress will create a fresh .htaccess file with only the essential WordPress rewrite rules, without any conflicting HTTPS redirects.

Inspecting and Repairing Your .htaccess File: Server-Level Configuration

The .htaccess file is hidden by default on most systems (filenames beginning with a period are hidden in Unix-like systems). You must explicitly enable the display of hidden files in your SFTP client or file manager before you can see it. Most SFTP clients include a setting or menu option to “Show hidden files” or “View hidden files”.

Safely Accessing and Backing Up .htaccess

Before making any changes to your .htaccess file, download a backup copy to your computer. Use SFTP or your hosting control panel’s file manager to access the file, right-click on .htaccess, select “Download,” and save it to your computer. If something goes wrong with your edits, you can easily restore the original file from this backup. This precaution prevents catastrophic mistakes that could render your site inaccessible.

Open your .htaccess file in a plain-text editor (Notepad, VS Code, Sublime Text, not Microsoft Word or other word processors that add formatting). Examine the file for patterns related to redirects: RewriteCond and RewriteRule statements, Redirect directives, or conditions related to HTTP_HOST, REQUEST_URI, or SSL. Common redirect conflicts involve www normalization, HTTP-to-HTTPS enforcement, or trailing slash normalization.

Identifying and Resolving Conflicting Redirect Rules

Look carefully for contradictory rules. For example, you might find rules like this:

This rule forces the non-www version to redirect to the www version. If you also see:

These two rules directly contradict each other. The first sends non-www to www; the second sends www back to non-www. They create a loop. To resolve this, keep only the rule that matches your WordPress Address setting. If you want your canonical URL to be www.yourdomain.com, delete the second rule. If you want non-www.yourdomain.com, delete the first rule. The key principle is to have only one rule governing www normalization, not multiple conflicting rules.

The Safe .htaccess Reset Method

If you’re uncertain which rules are causing the loop, or if your .htaccess file is too complex to diagnose safely, the safest approach is to reset .htaccess to WordPress defaults. Rename your current .htaccess to .htaccess_old via SFTP. Then, access your WordPress dashboard and navigate to Settings > Permalinks. Without making any changes, click the “Save Changes” button. WordPress will automatically generate a fresh .

htaccess file containing only the essential WordPress rewrite rules, without any custom or conflicting rules. Test your site. If the redirect loop is gone, your old .htaccess file definitely contained a conflict. If the loop persists, the issue lies elsewhere, and you can restore your old .htaccess file by renaming .htaccess_old back to .htaccess, knowing the .htaccess file wasn’t the culprit.

CDN and Proxy Configuration: When Third-Party Services Interfere

A Content Delivery Network (CDN) sits between your visitors and your origin server, caching your content on servers worldwide and delivering it from locations nearest each visitor. CDNs improve performance and security, but they add complexity to redirect configuration.

Identifying CDN Involvement and Configuring Correct SSL Settings

If you’re using a CDN service, access your CDN provider’s dashboard and look for SSL/TLS configuration settings. Search for something labeled “Encryption Mode,” “SSL Mode,” “SSL/TLS,” or “Security.” CDN providers typically offer several options: “Off” (no encryption), “Flexible” (HTTPS from visitor, HTTP to origin), “Full” (HTTPS both directions), and “Full (Strict)” (HTTPS both directions with certificate validation). If your origin server has a valid SSL certificate installed and is configured to use HTTPS, set your CDN to “Full” or “Full (Strict)”. Never use “Flexible” if your origin server also forces HTTPS.

After changing your CDN’s SSL setting, clear your browser cache and test your site. CDN settings changes can take time to propagate globally (typically 15 to 30 minutes, but potentially up to several hours). If the redirect loop persists after a reasonable wait period, the CDN configuration wasn’t the issue. If the loop disappears after your CDN propagates the new settings, you’ve found and fixed the problem.

Managing Multiple Proxy Layers and Advanced Configurations

Some enterprise hosting setups use reverse proxies or load balancers between the CDN and your origin server, adding complexity. Reverse proxies (such as nginx proxying to Apache backends) can intercept requests and modify headers or protocols. Load balancers distribute traffic across multiple servers. In these advanced setups, the $_SERVER[“HTTPS”] PHP variable, which WordPress uses to detect whether the current request arrived via HTTPS, might not be set correctly if the proxy layer doesn’t properly pass through protocol information. WordPress checks this variable to decide whether to enforce HTTPS or allow HTTP. If the variable is incorrect, WordPress’s redirect logic becomes wrong, causing redirect loops.

These advanced configuration issues require coordination with your hosting provider’s technical team. Contact your hosting provider and provide them with specific details: the exact URL where the loop occurs, a list of any plugins you’ve disabled during testing, your WordPress Address and Site Address settings, and confirmation of your CDN configuration. Your hosting provider can inspect server logs to trace the redirect chain and identify where the misconfiguration exists within their infrastructure.

WordPress Site Cache: When Optimization Becomes a Problem

Server-side caching plugins improve WordPress performance dramatically by storing copies of your pages so the WordPress application doesn’t need to rebuild them for every single visitor request. This is separate from browser cache, which stores data on each visitor’s computer. WordPress cache stores data on your server. If a redirect loop generates a cached response before you fix the underlying issue, that cached loop persists in your server cache.

Complete Redirect Loop Troubleshooting Workflow

Clearing WordPress Cache Through the Dashboard

If you can still access your WordPress dashboard despite the redirect loop, most caching plugins provide a cache-clearing button or option. Navigate to the settings for your caching plugin. WP Super Cache places its settings under Settings > WP Super Cache. W3 Total Cache places them under Performance. LiteSpeed Cache places them under LiteSpeed Cache. Look for a button labeled “Delete Cache,” “Empty Cache,” “Flush Cache,” or similar. Click that button. This removes all cached pages from your server, forcing WordPress to rebuild pages from scratch on the next visitor request. With the cache cleared, pages will be built based on your current (corrected) configuration rather than stale cached data.

Disabling Cache Plugins When Locked Out

If you cannot access your WordPress dashboard due to the redirect loop, you’ll need to disable the caching plugin directly to bypass the cache. Connect to your server via SFTP and navigate to wp-content/plugins. Rename your caching plugin’s folder (for example, rename “wp-super-cache” to “wp-super-cache-disabled”). WordPress will immediately deactivate the plugin. The next page load will bypass the cache entirely and build fresh pages based on your current configuration. Once you’ve confirmed that your redirect loop is fixed, you can rename the plugin folder back to its original name to re-enable caching if desired.

Cache and CDN Interaction Coordination

If you’re using both a server-side caching plugin and a CDN service, ensure their caching behaviors don’t conflict. Some caching plugins include built-in CDN integration features that can interfere with how your CDN caches content. These integration features may cause the CDN and your caching plugin to disagree about cache expiration times or content freshness, potentially creating redirect-related problems. Disable cache integration features in your caching plugin and let your CDN handle all caching. Configure your caching plugin to be a performance tool for non-cached requests without CDN integration. This separation of concerns prevents the two caching layers from conflicting.

Server Configuration and Load Balancers: Escalation Points for Complex Issues

Advanced hosting setups that use reverse proxies, load balancers, or multi-server architectures introduce additional complexity to redirect configuration beyond what WordPress or .htaccess can handle. Load balancers distribute incoming traffic across multiple identical servers to share the load. Reverse proxies (such as nginx) sit in front of your actual WordPress server and handle SSL termination or request routing.

Recognizing When Server Configuration Is the Issue

Several signs indicate that your redirect loop originates from server configuration rather than WordPress settings or plugins. First, the loop persists after you’ve verified that WordPress URL settings are correct, cleared browser cache, disabled all plugins, cleared server cache, and verified your SSL certificate is active. Second, the loop appears context-specific, only on admin pages, only on certain URLs, or only intermittently. Third, access to your hosting provider’s control panel or SFTP works fine, but WordPress admin access fails. Fourth, testing in incognito mode still shows the loop, confirming it’s server-side. These signs suggest the misconfiguration exists at the hosting infrastructure level.

When to Escalate to Your Hosting Provider

At this point, escalate the issue to your hosting provider’s technical support team. Provide them with comprehensive information: the exact URL(s) where the loop occurs, the complete error message you see, a list of plugins you’ve disabled during testing and confirmation that the loop persists even with all plugins disabled, your WordPress Address and Site Address settings as currently configured, confirmation that your SSL certificate is active (show them the https:// loads successfully), and a description of when the loop started (after a migration? after a specific change?).

Your hosting provider’s technical team can access server logs to inspect HTTP status codes and the complete redirect chain. They can identify whether the misconfiguration exists in their load balancer, reverse proxy, web server configuration, or elsewhere in their infrastructure.

Preventing Future Redirect Loops: Proactive Best Practices

Once you’ve resolved a redirect loop, the most valuable step is implementing practices that prevent the same issue from happening again. Most redirect loops emerge during periods of great server-side change: site migrations to new servers or domains, SSL certificate installations or renewals, major plugin updates, or extensive WordPress core updates. These are precisely the moments when multiple configuration layers are in transition and most likely to conflict.

Site Migration Best Practices and Planning

Migrations are the most common trigger for redirect loops because URL settings, server configuration, SSL certificate status, and DNS records all change at the same time. The complexity multiplies when you consider that changes at each layer may take different amounts of time to propagate. DNS changes can take 24 to 48 hours to propagate globally. SSL certificate provisioning might take 15 minutes to several hours. WordPress configuration changes take effect immediately. This cascading timeline creates windows where some layers have updated, but others haven’t, causing temporary misconfigurations that trigger redirect loops.

Before initiating a migration, document your current setup comprehensively: screenshot your WordPress Address and Site Address settings; note your current SSL certificate details (issuer, expiration date, domain coverage); document any custom redirect rules in your current .htaccess file; list any redirect-related plugins you have installed and their settings; and note any CDN configuration or domain routing rules. After migrating to your new server, before directing DNS and traffic to it, verify everything matches this documentation.

Ensure the new server has an SSL certificate installed and active. Ensure WordPress URL settings match the new domain. Ensure any redirect rules in .htaccess are appropriate for the new server. Run through each troubleshooting step from this guide to verify that no redirect loops exist. Only after this verification should you direct traffic to the new server. Niya Digital’s managed WordPress hosting includes migration support to coordinate these complex changes and verify alignment before DNS cutover, substantially reducing redirect risk.

SSL Certificate Installation and Renewal Procedures

SSL certificate installation and renewal are the second-most common redirect loop trigger because they involve changes to server-layer configuration (the certificate itself), WordPress-layer configuration (the HTTPS setting), and potentially .htaccess-layer configuration (redirect rules). After your SSL certificate is installed, verify it’s active by visiting https://yourdomain.com in your browser and confirming the padlock appears. Only after this verification should you enable HTTPS in WordPress. If you enable HTTPS before the certificate is active, you’ll immediately create a redirect loop and lock yourself out. When renewing an expiring certificate, follow the same procedure: verify the new certificate is active, then enable HTTPS if it wasn’t already.

Ongoing Monitoring and Proactive Maintenance

Implement ongoing monitoring for redirect chains on your site. Several browser extensions and online tools (such as redirect-chain checkers and HTTP status code inspectors) can reveal redirect patterns before they escalate into problems. If you notice more redirects or redirect chains forming, investigate and clean them up before they create a loop. Keep your WordPress installation, plugins, and theme up to date. Plugin updates sometimes introduce bugs that affect redirects. Test redirects after each significant update to catch problems early. Maintain regular backups of your WordPress database and files. If a redirect loop occurs despite these precautions, backups let you quickly restore a known-good configuration.

Frequently Asked Questions

What exactly is ERR_TOO_MANY_REDIRECTS and why does it happen?

ERR_TOO_MANY_REDIRECTS is a browser error code indicating your site is stuck in a redirect loop. In this circular pattern, URL A redirects to B, B redirects back to A or to another URL that eventually points back to A. Your browser follows these redirects until it exceeds its built-in limit (typically 20-30 redirects) and displays this error. The loop is a server-side configuration problem, not an issue with the visitor’s browser or device, so it affects all visitors the same way. Redirect loops occur when multiple configuration layers (WordPress settings, plugins, server files, SSL certificates, or CDN services) disagree about where to redirect requests.

Why can’t I log into my WordPress admin dashboard when experiencing a redirect loop?

A redirect loop occurs before WordPress even loads on your server. Your web server processes redirect rules at the Apache/nginx level before WordPress core files execute. Since the redirect happens during the server-level request processing, your browser never reaches the WordPress login page. You’re stuck in a loop, redirecting between URLs before WordPress can respond. This is why you must edit WordPress settings through your database (phpMyAdmin) or configuration files (wp-config.php via SFTP) rather than through the WordPress dashboard when a redirect loop prevents admin access.

Can a redirect loop cause permanent data loss or site damage?

No. A redirect loop is purely a configuration issue that prevents access; it doesn’t delete or corrupt your content, database, or files. Your WordPress installation, all your posts, pages, users, and data remain completely intact and unchanged. Once you fix the misconfiguration causing the loop, your site loads normally and all your data is immediately available. However, maintaining regular backups is always recommended as a best practice for any WordPress site, regardless of redirect issues.

How long does it typically take to fix a redirect loop myself?

Simple fixes like clearing browser cache or correcting WordPress URL settings take seconds to minutes if you already have access to your WordPress dashboard. Testing all plugins for conflicts takes 10-30 minutes depending on how many plugins you have installed. Inspecting and fixing .htaccess files typically takes 15-30 minutes. Advanced server-level troubleshooting that requires contact with your hosting provider might take 1-2 hours or more. The range depends entirely on where the misconfiguration exists and whether you have the technical knowledge to identify and fix it.

If I incorrectly change my WordPress Address, will I definitely create a redirect loop?

Changing WordPress Address to an incorrect URL usually creates a mismatch that triggers a redirect loop, though not always immediately. If you change it to a domain that doesn’t match your actual server configuration, doesn’t match your SSL certificate, or uses the wrong protocol (http vs. https), you create the conditions for a loop. WordPress tries to redirect to the incorrect domain, your server redirects back, and a loop forms. Always verify your domain name and protocol (https:// if SSL is active) before saving changes.

Can a caching plugin cause a redirect loop by itself, or only after caching a bad response?

A caching plugin typically won’t cause a redirect loop on its own unless its redirect-management features conflict with other plugins or server configuration. However, if your site enters a redirect loop for another reason while caching is active, the caching plugin may cache the redirect response, perpetuating the loop even after you fix the root cause. That is why clearing the WordPress cache matters after server-side configuration changes. The cache needs to refresh so pages rebuild based on the corrected configuration.

What’s the real difference between WordPress Address and Site Address settings?

WordPress Address is the file-system location where your WordPress core files are installed on the server. Site Address is the public-facing URL that visitors type into their browsers. In standard single-site installations, both are identical. They differ only in special setups: when WordPress is installed in a subdirectory, but you want visitors to access it from the root domain, or in multisite networks. For troubleshooting redirect loops, treat them as fields that must match your actual server configuration and domain. Both must use the same domain name, protocol, and subdirectory structure.

If I force HTTPS in WordPress before my SSL certificate is installed, what exactly happens?

WordPress will redirect every HTTP request to HTTPS. Your server, lacking an SSL certificate, cannot complete the HTTPS connection. The browser shows a certificate error and falls back to HTTP. WordPress sees the HTTP response and redirects to HTTPS again. This endless cycle creates a redirect loop you can’t escape from your browser, and you’ll lose dashboard access because the browser can’t reach the login page. The fix requires accessing your database or wp-config.php file directly to turn off the HTTPS setting. Always verify your SSL certificate is active and working before enabling HTTPS enforcement in WordPress.

How do I know definitively whether my SSL certificate is properly installed and working?

Open your browser and navigate to https://yourdomain.com (with the https:// protocol). If the page loads successfully and your browser displays a padlock icon or green security indicator in the address bar, your SSL certificate is installed and working. If your browser shows a certificate warning (“not secure,” “certificate mismatch,” or similar), the certificate may not be installed, may not be valid for your domain, or may have another issue. Contact your hosting provider if you see warnings. Never enable HTTPS in WordPress or install an SSL-forcing plugin if your certificate shows warnings.

Can a CDN service cause a redirect loop, and how do I know if mine is the culprit?

Yes, if a CDN’s SSL/TLS encryption mode is misconfigured, particularly if set to “Flexible” mode while your origin server forces HTTPS, it can create a redirect loop. The CDN accepts HTTPS from visitors but forwards HTTP to your origin; your origin redirects to HTTPS; the CDN converts it back to HTTP; the loop continues. Test by logging into your CDN’s dashboard and changing SSL/TLS mode to “Full” or “Full (Strict)” (assuming your origin has a valid SSL certificate). Wait 15-30 minutes for the change to propagate, then clear your browser cache and test your site. If the loop disappears, your CDN’s SSL setting was misconfigured.

What should I do if the redirect loop starts immediately after updating a WordPress plugin?

The plugin update likely introduced a bug or changed how the plugin handles redirects. Disable that plugin using SFTP (rename its folder to “disabled-plugin-name”) to deactivate it. Test your site. If the loop disappears, the updated plugin is definitely the culprit. Contact the plugin developer, check for a newer version that fixes the issue, or find an alternative plugin. If the loop persists even with the plugin disabled, the plugin wasn’t the cause despite the timing.

If I restore a backup of my WordPress installation, will that definitely fix my redirect loop?

Only if you restore from a backup taken before the redirect loop started. Restoring a backup before the misconfiguration occurred will restore a working configuration. However, if the redirect loop was caused by a current setting (incorrect WordPress Address, active plugins, or server configuration), restoring a backup older than the problem won’t fix the current misconfiguration unless you also make the required configuration corrections. Backups are valuable recovery tools, but they don’t automatically fix every problem.

Is my hosting provider responsible for redirect loops, or is it always my fault?

Redirect loops usually involve both factors: misconfigured WordPress settings or plugins (your responsibility) conflicting with server-level configuration (your hosting provider’s responsibility). Most often, the WordPress-layer issue is the primary cause, but proper hosting configuration should make these misconfigurations fail safely rather than creating loops. Shared hosting providers often have less control over server-level redirect configuration than managed WordPress hosting providers, which is why redirect loops are more common on shared hosting. The fairest answer: it’s rarely entirely one party’s fault.

Can I use an online .htaccess generator tool to fix my .htaccess file safely?

Proceed with extreme caution. Generic .htaccess generators create rules based on typical WordPress installations but may not account for your specific server setup, CDN configuration, or custom redirect requirements. Using a tool-generated .htaccess could introduce new problems while trying to fix the current one. If you use a generator, absolutely back up your current .htaccess first, apply changes carefully, test thoroughly, and be ready to restore the backup if problems emerge. Generally, manually editing .htaccess or resetting it to WordPress defaults is safer than using third-party generators.

If my site loads in an incognito window but not in my regular browser, what does that tell me?

This specific combination means your server-side configuration is actually fixed, the redirect loop is resolved. The difference between browsers is that incognito windows don’t use cached data. Your regular browser is serving you cached redirect data from before you fixed the problem. Clear your browser’s cache and cookies, close the browser completely, reopen it, and test again. After clearing the cache, your regular browser should load your site successfully, as the incognito window does.

Glossary

• Redirect Loop (Infinite Redirect): A circular pattern where a URL redirects to another URL, which redirects back to the original or to another URL in the chain, eventually pointing back to the starting URL. The visitor’s browser follows these instructions repeatedly until it exceeds its redirect limit and displays an error. The loop prevents the browser from reaching the final destination resource.
• ERR_TOO_MANY_REDIRECTS: A browser error code and message indicating the browser has exceeded its maximum allowed number of redirects (typically 20-30 per browser specifications) and cannot complete the request. Different browsers display this error with slightly different wording but the same underlying meaning: a redirect loop has occurred.
• .htaccess File: A server-side configuration file used exclusively by Apache web servers and Apache-compatible servers (LiteSpeed, for example). Stored in your WordPress root directory, it contains rewrite rules and redirect rules that the web server processes before requests reach WordPress. Changes to .htaccess take effect immediately but require correct syntax; syntax errors can break your site entirely.
• SSL Certificate: A cryptographic credential installed on your web server that enables HTTPS (secure, encrypted HTTP). The certificate is issued by a trusted Certificate Authority and validates that your domain actually controls the server. Without an SSL certificate, you cannot use HTTPS. Many redirect loops stem from a mismatch between WordPress HTTPS settings and SSL certificate installation status.
• HTTPS Protocol: The secure version of HTTP that encrypts data transmitted between visitor browsers and your web server. Requires a valid SSL certificate installed on your server. The “S” stands for “Secure.” If your WordPress settings force HTTPS but no SSL certificate is installed, you create a redirect loop: WordPress forces HTTPS, the server redirects back to HTTP (no certificate available), WordPress redirects to HTTPS again.
• CDN (Content Delivery Network): A service consisting of servers distributed globally that caches and delivers your website’s content from locations geographically near your visitors. CDNs improve performance and security but introduce additional configuration layers. Improper CDN SSL/TLS settings can conflict with your origin server’s HTTPS configuration, creating redirect loops.
• WordPress Cache (Server-Side Cache): Server-side storage of your WordPress pages and posts to improve performance. Separate from browser cache, which lives on visitors’ computers. WordPress cache lives on your server; clearing it requires accessing your WordPress dashboard or hosting control panel. If a redirect loop is cached, visitors see the loop even after you fix the server configuration.
• Reverse Proxy: A server (like nginx) positioned between visitors and your actual WordPress server that accepts requests and forwards them to backend servers. Used for load balancing, SSL termination, or request routing. Reverse proxies can intercept and modify requests, potentially creating redirect conflicts if not configured to pass protocol information correctly to backend servers.
• Load Balancer: A service or device that distributes incoming requests across multiple identical servers to share processing load. Common in enterprise hosting. Load balancers require careful configuration to ensure all servers understand protocol information (HTTP vs. HTTPS) consistently; misconfiguration creates context-specific redirect loops.
• WP_HOME and WP_SITEURL Constants: PHP constants that can be defined in wp-config.php to hard-code your site’s URLs, overriding the database settings. Used as an emergency measure when redirect loops prevent dashboard access. Define WP_HOME and WP_SITEURL to the correct URLs, and WordPress will use these values regardless of database settings until you remove the constants.