WordPress Too Many Redirects After Changing Site URL

The Problem

The browser error usually says there are too many redirects, but the real problem is disagreement. WordPress thinks the site belongs at one URL, the database may hold another URL, wp-config.php may force a third URL, and a CDN, host, server rule, or redirect plugin may be trying to enforce HTTPS or a preferred hostname at the same time.

This often appears after changing the WordPress Address or Site Address, moving from HTTP to HTTPS, switching from non-www to www, moving behind a proxy, enabling a CDN, restoring a backup to a new domain, or migrating from a subdirectory to the root. wp-admin may loop, the login form may reload, or the public site may bounce between two versions of the same URL.

Capture the Redirect Chain

• Test the exact failing URL in a private browser window and record whether the loop affects wp-admin, wp-login.php, the homepage, a specific page, or every URL.
• Use browser developer tools, curl, or a trusted header checker to list each 301, 302, or 307 step in order.
• Write down every version that appears: http, https, www, non-www, subdirectory, root domain, trailing slash, and any CDN or staging hostname.
• Check whether the loop happens only for logged-in users, only for visitors, or both.
• Note recent changes: URL fields, HTTPS setting, Cloudflare or CDN SSL mode, host panel redirects, .htaccess, Nginx config, redirect plugin rules, migration plugin settings, and cache rules.
• Keep one rollback option ready before editing wp-config.php, server rules, database values, or redirect plugin settings.

A redirect loop is easiest to fix when you can describe the actual bounce, such as `example.com` redirects to `example.com`, then WordPress redirects back to `example.com`, then the CDN repeats the first step.

Check WordPress URL Values

For a single-site WordPress install, the WordPress Address and Site Address control where WordPress is installed and where visitors should reach the site. After a URL change, the first job is to make sure those values match the canonical public URL you actually want.

1. If wp-admin is reachable, check Settings > General for WordPress Address (URL) and Site Address (URL).
2. If wp-admin is not reachable, inspect the `home` and `siteurl` rows in the options table through a safe database tool or WP-CLI.
3. Check wp-config.php for `WP_HOME` and `WP_SITEURL`; those constants can override database values and make Settings > General appear locked.
4. Use one canonical scheme and hostname. Do not mix http and https, www and non-www, or root and subdirectory paths unless WordPress is intentionally installed separately from the public site address.
5. Avoid adding a trailing slash to the WordPress Address or Site Address values.
6. On multisite, do not assume the single-site workflow applies; network and site tables need a more careful review.

Check HTTPS, Proxy, and CDN Ownership

Many site URL loops are HTTPS loops. WordPress needs to know whether the original request is secure. If a reverse proxy, load balancer, or CDN terminates SSL before the request reaches the origin server, WordPress may see the origin request as HTTP and redirect to HTTPS again.

• Confirm the public site has a valid HTTPS certificate and that the origin or host configuration supports the chosen HTTPS mode.
• Check whether the CDN SSL mode is compatible with the origin, especially after moving from HTTP to HTTPS.
• For reverse proxies, confirm the proxy forwards the scheme with headers such as `X-Forwarded-Proto` and that WordPress is configured to recognize HTTPS correctly.
• Review `FORCE_SSL_ADMIN` only after SSL is working at the server or proxy layer.
• Do not let the CDN force HTTPS, the host force HTTPS, a plugin force HTTPS, and WordPress force HTTPS in conflicting ways.
• If the loop affects only wp-admin or login, check cookies, admin HTTPS behavior, and whether cache rules accidentally cache logged-in redirects.

The clean setup usually has one canonical public URL and one clear owner for each redirect: HTTP to HTTPS, non-www to www or the reverse, and old domain to new domain.

Review Server and Plugin Redirect Rules

• Check .htaccess or Nginx rules for old-domain, www, HTTPS, trailing-slash, subdirectory, or maintenance redirects.
• Check host control-panel redirects and domain aliases, because they may run before WordPress loads.
• Temporarily disable redirect-plugin rules on staging if they duplicate server or CDN rules.
• Review security, SSL, cache, SEO, migration, and multilingual plugins for redirect features.
• Exclude wp-login.php, wp-admin, REST API, and cookie-based sessions from page cache where your cache stack requires it.
• Purge CDN and page cache only after the URL owner and redirect rules are corrected.

Avoid stacking redirects just because each one seems reasonable alone. A host rule that forces HTTPS, a CDN rule that forces www, and a plugin rule that forces non-www can create a loop even when none of the individual settings looks obviously wrong.

How Web Plura Diagnostics Helps

Web Plura Diagnostics is relevant here because the free plugin includes local Site Health-style checks, URL alignment checks, cache signals, hosting checks, and Front-end Response checks for home URL HTTPS, response code, redirect signal, cache-control, compression header, and REST API response.

Use it after the site is reachable enough to access wp-admin. It will not magically repair a redirect loop, and it does not replace server access, backups, CDN access, or host support. Its value is organizing local evidence into a safer handoff: what is wrong, why it matters, who likely owns the next action, and what should be checked first.

The free diagnostics workflow runs locally inside WordPress and does not require an external account for core scans, dashboard rendering, exports, scheduled scans, or support-safe snapshots. The plugin also provides JSON/CSV exports, WP-CLI output, Site Health visibility, Fix First prioritization, and customer-safe export/removal behavior.

Safe Recovery Order

1. Decide the final canonical URL: scheme, hostname, and path.
2. Align `home`, `siteurl`, `WP_HOME`, and `WP_SITEURL` with that canonical choice or document why they intentionally differ.
3. Make sure HTTPS is detected correctly at the origin, reverse proxy, or CDN boundary.
4. Remove duplicate or contradictory host, CDN, server, and plugin redirect rules.
5. Clear cookies for the domain if wp-admin or login loops continue after URL values are fixed.
6. Purge CDN and page cache after the redirect source is corrected.
7. Retest the exact original URL and confirm the redirect chain ends in one final 200 response.
8. Record the final owner of each redirect so the same loop does not return during the next migration, SSL change, or cache change.

Prevent the Next Redirect Loop

• Keep a migration note that lists the chosen canonical URL, old URL, CDN SSL mode, host redirects, server redirects, and WordPress URL values.
• Change one redirect owner at a time during HTTPS, www/non-www, domain, or subdirectory moves.
• Test wp-admin, wp-login.php, REST API, homepage, checkout, forms, account pages, and important landing pages after URL changes.
• Keep wp-admin and logged-in sessions out of full-page cache.
• Use staging for risky domain, HTTPS, CDN, proxy, and redirect-rule changes.
• Keep a recent backup and know whether rollback requires files, database, host config, CDN settings, or all of them.
• After the fix, keep the successful redirect chain in the maintenance notes.

The durable fix is not simply clearing cache. It is getting every layer to agree on the same public URL and giving each redirect a single owner.

Related WPlura Plugin Help

After you capture the redirect chain and regain enough access to use wp-admin, install the free Web Plura Diagnostics plugin from WordPress.org: download the free plugin on WordPress.org. Review product details and Free versus Pro fit here: WPlura product details.

1. Run the local diagnostics review to check Site Health-style signals, URL alignment, cache hints, hosting readiness, front-end response, REST response, and redirect signals.
2. Use Fix First prioritization to decide whether the next action belongs to the site admin, developer, host, CDN/DNS provider, or plugin owner.
3. Export a support-safe snapshot, JSON report, or CSV report when you need to involve a developer or hosting support without sending private logs.
4. After the manual fix, rerun the same checks and keep the before/after result with the migration or SSL-change notes.
5. For teams that need durable cloud history, portfolio monitoring, report delivery, alerting, cross-site prioritization, or hosted correlation, review the Pro path after the free local diagnostics review: WPlura Pro purchase and private download.

References

Frequently Asked Questions