WordPress Redirect Loop Recovery Playbook

Quick Answer

WordPress redirect loop recovery should start by preserving the loop path before changing settings. The best fit is a short incident register: affected URL, first report time, browser symptom, redirect hop pattern, WordPress Address and Site Address owner, HTTPS or proxy state, CDN or edge redirect owner, plugin or server redirect owner, recent change, smallest rollback option, and recheck date. Choose WordPress URL repair when the dashboard or database points to the wrong host or scheme. Choose HTTPS or proxy repair when the origin and edge disagree about HTTP versus HTTPS. Choose plugin, server, or CDN repair when two redirect layers keep rewriting the same request in opposite directions.

Redirect Loop Decision Table

Signal	Better operator choice	Evidence to capture
Browser shows too many redirects on every page	Treat it as an availability incident and map the first hop pattern	Affected host, first report time, and redirect trace owner
Only admin or login loops	Review WordPress URL settings, HTTPS admin handling, cookies, and proxy protocol handling	Login URL, scheme changes, admin access owner, and recovery route
HTTP and HTTPS bounce between each other	Separate origin HTTPS rules from CDN or edge HTTPS rules	HTTP sample, HTTPS sample, edge setting owner, and origin rule owner
Old slug redirects into another redirect	Use the slug redirect register before editing canonical or sitemap signals	Old URL, target URL, chain length, and final destination
Loop began after plugin, theme, cache, CDN, or host work	Review the changed layer first and keep rollback narrow	Change window, component owner, and one public retest URL
Search or crawl tools report redirect error	Compare live public behavior with report timing before rewriting content	Tool sample, live HTTP result, and follow-up date

Who Should Use This Playbook?

Use this playbook when a WordPress publisher, editor-operator, creator business, small technical team, or site owner sees a "too many redirects" browser error, a login loop, an uptime alert for a redirect loop, a crawl report that cannot reach a final URL, or a public page that keeps bouncing between HTTP, HTTPS, host variants, old slugs, CDN rules, server rules, and WordPress plugins.

This is WordPress site-operations guidance, not professional security consulting, legal advice, privacy compliance advice, hosting support, incident-response representation, Search Console account management, Bing Webmaster Tools management, Google AdSense account guidance, payment advice, tax advice, affiliate guidance, sponsored-content guidance, or a promise that fixing redirects will improve rankings, approval, revenue, or traffic. It does not change WordPress settings, edit databases, install certificates, modify DNS, edit CDN accounts, update Search Console, alter Bing Webmaster Tools, change Google AdSense, touch payment settings, touch tax settings, inspect private dashboards, or claim production testing.

The operating risk is making the loop harder to diagnose. A redirect loop can come from WordPress Address and Site Address mismatch, HTTPS admin handling, reverse proxy headers, canonical redirect behavior, a redirect plugin, server rewrite rules, a CDN "always use HTTPS" setting, host-level canonical rules, or an old slug redirect that points back to itself. Recovery should name the owner before changing the stack.

Step 1: Preserve The Loop Before Fixing It

Start with the symptom, not the settings screen. A loop often disappears temporarily after a cache purge or plugin toggle, but the same conflict can return because the root owner was never recorded.

Use this incident register:

• [ ] Affected URL and whether it is the home page, post, page, archive, login, admin, sitemap, feed, or old slug.
• [ ] First report time and source: browser, uptime monitor, crawler, Search Console, server log, or editor report.
• [ ] Visible symptom: browser "too many redirects," repeated login prompt, crawl redirect error, or unavailable page.
• [ ] First few hop owners, if a private trace exists: HTTP, HTTPS, www, non-www, old slug, new slug, login, or canonical URL.
• [ ] Recent change: WordPress URL setting, HTTPS migration, plugin update, redirect rule, CDN toggle, cache rule, host migration, theme change, or permalink edit.
• [ ] Current recovery route: working admin session, SSH, host panel, file manager, backup, staging copy, or owner contact.
• [ ] Next public retest URL and who owns the retest.

Do not publish private redirect traces, cookies, admin URLs, account identifiers, server paths, IP addresses, tokens, or control-panel screenshots in the article. A safe public note can say which class of evidence an operator should keep without exposing the private infrastructure.

Step 2: Separate Loop Classes

WordPress HTTPS documentation warns that reverse proxy HTTPS setups can create infinite redirects when WordPress does not recognize the original HTTPS request. WordPress General Settings documentation explains the WordPress Address and Site Address fields. Cloudflare documentation describes redirect loops when edge HTTPS settings and origin redirects conflict. Those are different loop classes, even when the browser message looks the same.

Use this classification pass:

Loop class	Typical pattern	First owner to inspect
Scheme loop	HTTP redirects to HTTPS, then HTTPS redirects back to HTTP	HTTPS, origin, proxy, and edge redirect owners
Host loop	www redirects to non-www, then returns to www	Host canonical rule, WordPress URL settings, CDN rule
Admin loop	/wp-admin/ or /wp-login.php never settles	WordPress URL settings, HTTPS admin, cookies, and proxy protocol
Slug loop	Old post path redirects to a target that redirects back	Redirect plugin, server rule, old slug register, canonical target
Canonical loop	WordPress canonical behavior disagrees with another rewrite layer	Canonical redirect, permalink, theme/plugin, and server rule owner
Cached loop	A fixed rule still appears in public output	Cache, CDN, browser cache, and sampled retest path

The better choice is not the broadest fix. If the loop only affects an old slug, do not begin by changing the site's HTTPS mode. If the loop affects every HTTPS page, do not start by editing one article link. Match the repair to the loop class.

Step 3: Check WordPress URL Ownership

WordPress General Settings separates the WordPress Address from the Site Address. Site Health can also surface home and site URL information in a private dashboard context. Those fields matter because WordPress can generate redirects, links, login flows, and canonical behavior around the stored site URLs.

Use this WordPress-side checklist:

• [ ] Confirm whether WordPress Address and Site Address use the intended scheme and host.
• [ ] Confirm whether WP_HOME or WP_SITEURL constants override dashboard settings.
• [ ] Confirm whether the public host uses www or non-www, and do not let another layer choose the opposite.
• [ ] Confirm whether admin and login URLs are supposed to run on the same final HTTPS host.
• [ ] Review Site Health privately for relevant HTTPS, loopback, REST, server, or configuration warnings.
• [ ] Keep a rollback route before editing URL settings, because a bad URL edit can lock out normal admin access.

Use Site Health as an evidence surface, not as a public screenshot dump. The operator note only needs the checked field, mismatch, owner, and action. It should not expose admin email, server modules, private paths, user lists, or diagnostic exports.

Step 4: Inspect HTTPS And Proxy Boundaries

WordPress HTTPS guidance describes HTTPS administration and reverse proxy cautions. Cloudflare documentation explains redirect-loop cases around edge HTTPS features, encryption mode, origin redirects, and evaluating existing redirects. For a publisher, the practical point is that one layer may believe the request is HTTP while another layer believes it already upgraded to HTTPS.

Use this boundary check:

Boundary	What to verify	Bad repair pattern
Browser to CDN or edge	Does HTTP become HTTPS once, on the intended host?	Edge forces HTTPS while origin sends HTTPS back to HTTP
Edge to origin	Does the origin expect HTTP or HTTPS from the edge?	Changing WordPress URLs before origin TLS behavior is known
Origin to WordPress	Does WordPress see the original scheme correctly behind a proxy?	Forcing SSL admin without proxy protocol handling
WordPress to plugin	Does a redirect plugin add a second host or scheme rule?	Leaving duplicate plugin and server rules for the same target
Cache to public visitor	Does cached HTML or cached redirect response reflect old rules?	Declaring success from a logged-in uncached session only

Choose the repair owner where the conflict is created. If edge settings and origin redirects disagree, changing post content will not resolve the loop. If WordPress URL settings disagree with the final public host, adding another CDN rule may hide the symptom while leaving future admin, sitemap, and canonical behavior unstable.

Step 5: Review Redirect And Canonical Rules

Google Search documentation distinguishes redirect types and explains how redirects help route users and search systems to replacement URLs. WordPress has canonical redirect behavior that can route requests toward a preferred form. Redirects and canonical behavior are useful when they agree with the site plan; they become fragile when several layers try to correct the same URL in different directions.

Use this redirect review:

• [ ] Identify one final destination for the affected URL.
• [ ] Check whether the old URL, HTTP variant, host variant, and trailing-slash variant all converge on that destination.
• [ ] Remove or pause duplicate rules only when the operator owns the rollback.
• [ ] Avoid redirecting old posts to the home page unless the home page is truly the reader-relevant replacement.
• [ ] Keep slug redirects in a redirect register, not only inside a plugin screen.
• [ ] Confirm sitemap and canonical signals use the final URL after the loop is fixed.

A loop closeout is not complete when the browser error disappears once. The operator should know which rule changed, why it changed, and which related rules remain in place.

Step 6: Repair In A Reversible Order

Redirect loops can create pressure to toggle everything at once. That makes the incident faster to hide and harder to learn from. Use the smallest reversible repair that matches the evidence.

Recovery path	Use this when	Evidence after recovery
Revert one recent redirect rule	The loop began after a known rule change	Old rule, new rule, owner, and passing public URL
Correct WordPress URL settings	WordPress Address or Site Address points to the wrong host or scheme	Checked setting source, recovery route, and login retest
Adjust proxy or HTTPS handling	Edge and origin disagree about the request scheme	Edge setting, origin expectation, and HTTP/HTTPS samples
Disable one duplicate plugin rule	Plugin and server both redirect the same path	Rule ID or private note, old target, final target, and retest
Repair old slug mapping	Old content URL redirects through a chain or back to itself	Redirect register row, final replacement, and internal link update
Restore from backup or staging	A broad change broke public pages and ownership is unclear	Restore point, changed surface, and post-restore verification

Do not combine URL setting edits, CDN HTTPS changes, plugin deactivation, server rewrite edits, sitemap changes, and cache purges unless the site is in a declared outage and a qualified operator owns the rollback. One scoped change creates better evidence than a noisy recovery.

Step 7: Verify Reader, Editor, And Crawler Surfaces

After a redirect-loop repair, verify the surfaces that can regress separately. A home page can recover while /wp-admin/ still loops. An admin page can recover while an old article slug still loops. A public browser can pass while a stale crawl report still reflects the old state.

Use this closeout checklist:

• [ ] The affected public URL reaches one final destination for a logged-out visitor.
• [ ] HTTP, HTTPS, www, and non-www variants behave according to the chosen host policy.
• [ ] /wp-admin/ and /wp-login.php do not loop, if they were part of the incident.
• [ ] Old slug redirects land on the intended replacement without returning to the old URL.
• [ ] Sitemap and canonical samples point at the final URL after live behavior is stable.
• [ ] Cache or CDN was sampled after the fix when cached redirects could have persisted.
• [ ] Search Console, crawl, or uptime follow-up is scheduled with the report date separated from the live retest date.
• [ ] The incident note names cause class, changed layer, rollback option, owner, and next review date.

If Google Search Console or a crawl tool still shows a redirect error after live behavior is fixed, record the live check and recheck window instead of repeatedly changing stable rules. If live behavior still loops, reopen the incident with current evidence and avoid treating the report as stale.

What Should A WordPress Redirect Loop Recovery Include?

A WordPress redirect loop recovery should include the affected URL, symptom source, first report time, redirect class, WordPress URL setting owner, HTTPS or proxy state, CDN or edge redirect owner, plugin or server rule owner, recent change, chosen repair, public retest, admin or login retest when relevant, cache retest, crawl follow-up date, and rollback note. Choose WordPress URL repair when stored site URLs disagree with the final host, HTTPS or proxy repair when scheme handling conflicts, and redirect-rule repair when plugin, server, CDN, or old-slug rules fight each other.

Common Questions

Is every WordPress redirect loop an HTTPS problem?

No. HTTPS and proxy settings are common causes, but old slug maps, host canonical rules, redirect plugins, server rewrites, cached responses, and WordPress URL settings can also create loops. Classify the loop before repairing it.

Should I clear cache first?

Clear cache only when cache is part of the evidence or after a rule has changed. Clearing every cache first can hide the original loop path and make the next recurrence harder to explain.

Can a redirect loop affect Google crawling?

Yes. A crawler that cannot reach a final URL may report redirect or availability problems. Use live public behavior and official source notes before deciding whether the crawl report is current, stale, or caused by an unresolved loop.

Should a small publisher install another redirect plugin?

Choose a plugin only when dashboard-managed redirects are the best fit for the operating workflow. If the loop is caused by duplicate plugin, server, and CDN rules, another plugin adds risk instead of clarity.

Does this playbook claim Yolkmeet tested a private WordPress site?

No. This article is source-derived analysis from official WordPress, Google, and Cloudflare documentation. It does not claim access to a private WordPress dashboard, production URL, server log, CDN account, Search Console property, Google AdSense account, billing screen, payment setting, tax setting, or user data.

AdSense And Policy Fit

This playbook supports AdSense-safe operator publishing because it improves public page availability, reader trust, crawl hygiene, source-note discipline, and incident evidence without encouraging artificial traffic, ad-click behavior, click exchange, refresh bots, proxy traffic, copied troubleshooting content, scraped article bodies, affiliate placement, sponsored claims, unsafe account changes, private-account disclosure, or unsupported approval promises. WordPress redirect loop recovery is a site-operations workflow, not a shortcut to rankings, approval, revenue, traffic, or monetization.

Source Notes

• https://developer.wordpress.org/advanced-administration/security/https/ checked 2026-06-21; used for source-derived analysis of WordPress HTTPS administration, reverse-proxy redirect-loop risk, SSL admin boundaries, and why HTTPS state must be separated from WordPress content edits.
• https://wordpress.org/documentation/article/settings-general-screen/ checked 2026-06-21; used for source-derived analysis of WordPress Address and Site Address fields and why URL ownership matters during redirect-loop recovery.
• https://wordpress.org/documentation/article/site-health-screen/ checked 2026-06-21; used for source-derived analysis of Site Health as a private operator surface for home URL, site URL, server, HTTPS, and configuration review.
• https://developer.wordpress.org/reference/functions/redirect_canonical/ checked 2026-06-21; used for source-derived analysis of WordPress canonical redirect behavior and why canonical routing should be considered alongside server and plugin rules.
• https://developers.google.com/search/docs/crawling-indexing/301-redirects checked 2026-06-21; used for source-derived analysis of redirect types, final destination choice, and why redirect rules should route users and search systems consistently.
• https://developers.google.com/crawling/docs/troubleshooting/http-status-codes checked 2026-06-21; used for source-derived analysis of separating live HTTP behavior, redirect outcomes, crawl errors, and stale report timing.
• https://developers.cloudflare.com/ssl/troubleshooting/too-many-redirects/ checked 2026-06-21; used for source-derived analysis of edge and origin HTTPS conflicts that can produce too-many-redirects failures.
• https://developers.cloudflare.com/ssl/edge-certificates/encrypt-visitor-traffic/ checked 2026-06-21; used for source-derived analysis of evaluating existing redirects before enforcing HTTPS at an edge layer.

No private WordPress dashboard, editor screen, database, server log, redirect plugin screen, CDN account, host panel, Search Console property, Bing Webmaster Tools account, Google AdSense account, billing screen, payment setting, tax setting, analytics export, production URL, customer record, or user account was inspected for this article. If a future operator adds screenshots, curl output, redirect traces, Site Health exports, CDN logs, host logs, Search Console samples, or server configuration excerpts, keep secrets and private identifiers out of the public article and narrow public claims to the verified evidence.

Internal Link Notes

Link to wordpress-https-migration-checklist when the loop belongs to HTTPS migration or proxy handling. Link to wordpress-canonical-url-checklist when canonical behavior, host variants, or sitemap signals conflict. Link to wordpress-redirect-checklist-for-slug-changes when an old post URL or slug map is part of the loop. Link to wordpress-mixed-content-recovery-playbook when HTTPS pages load but assets or canonical signals still point to HTTP. Link to wordpress-site-health-review-checklist when Site Health is the first private diagnostic surface. Link to wordpress-debug-log-checklist when server-side warnings need private evidence. Link to uptime-monitoring-for-wordpress when the loop caused an availability alert. Link to wordpress-backup-restore-drill-playbook and wordpress-plugin-update-recovery-playbook when the loop started after maintenance and a rollback path must be named.

Update Note

Review this playbook every 60 days. Recheck official WordPress HTTPS, General Settings, Site Health, and canonical redirect documentation, plus Google redirect and crawling documentation and Cloudflare redirect-loop documentation before changing claims. Refresh earlier after a WordPress core release, HTTPS migration, CDN change, proxy change, host canonical change, redirect plugin update, permalink change, Search Console redirect-report change, reader correction, or repeated redirect-loop incident.