Provider repair guideReviewed 2026-08-07By HostWithShery technical editorial

Fix a WordPress redirect loop behind Cloudflare

Use a valid origin HTTPS configuration, choose a compatible Cloudflare SSL mode, and remove duplicate WordPress/plugin/server redirect rules.

Start with evidence from your own domain before changing DNS, SSL or mail settings.
Check your own configuration

SSL Certificate Checker

This page is preconfigured with the SSL Certificate Checker that best matches this problem.

No accountPublic evidence only
Live public check
No account · Public configuration only
On this page

Fix a WordPress redirect loop behind Cloudflare: when this repair path applies

Use a valid origin HTTPS configuration, choose a compatible Cloudflare SSL mode, and remove duplicate WordPress/plugin/server redirect rules. Use these steps when WordPress and Cloudflare keep redirecting between incompatible URL or HTTPS states, but first run the embedded diagnostic so the TLS, certificate and HTTPS evidence supports this provider-specific path rather than a neighboring DNS, TLS, application or mail cause.

Find the authoritative setting before editing

Cloudflare DNS > Records for DNS changes, and SSL/TLS or Rules only when the diagnosis specifically points to those layers. For Fix a WordPress redirect loop behind Cloudflare, confirm the active nameservers and exact service owner before changing confirm WordPress Site URL and Home URL use the intended HTTPS hostname. A DNS-looking screen at cloudflare has no public effect when another provider is authoritative for the zone.

Evidence to save for Fix a WordPress redirect loop behind Cloudflare

Record the current public state for confirm WordPress Site URL and Home URL use the intended HTTPS hostname, confirm the origin serves HTTPS directly, use a Cloudflare SSL mode compatible with the origin. This gives the repair a before/after comparison and prevents a cached answer or a separate working service from being confused with the configuration that produced the symptom.

  • Confirm WordPress Site URL and Home URL use the intended HTTPS hostnameRecord the public status, final URL and relevant response headers. A working DNS answer does not prove that the application is serving a genuine website response.
  • Confirm the origin serves HTTPS directlyRecord the public status, final URL and relevant response headers. A working DNS answer does not prove that the application is serving a genuine website response.
  • Use a Cloudflare SSL mode compatible with the originTest the hostname actually requested, its certificate dates and SAN coverage, and the TLS handshake. Root and www can serve different certificates.
  • Disable duplicate redirect plugins or server rulesFollow every hop rather than checking only the final page. The conflicting rule is usually visible where the chain changes scheme, hostname or destination repeatedly.
  • Run the redirect checker againFollow every hop rather than checking only the final page. The conflicting rule is usually visible where the chain changes scheme, hostname or destination repeatedly.

Repair steps in cloudflare

Use a valid origin HTTPS configuration, choose a compatible Cloudflare SSL mode, and remove duplicate WordPress/plugin/server redirect rules.

  • 1. Confirm WordPress Site URL and Home URL use the intended HTTPS hostname. After this step, check the public value tied to confirm wordpress site url and home url use the intended https hostname before changing another unrelated setting.
  • 2. Confirm the origin serves HTTPS directly. After this step, check the public value tied to confirm the origin serves https directly before changing another unrelated setting.
  • 3. Use a Cloudflare SSL mode compatible with the origin. After this step, check the public value tied to use a cloudflare ssl mode compatible with the origin before changing another unrelated setting.
  • 4. Disable duplicate redirect plugins or server rules. After this step, check the public value tied to disable duplicate redirect plugins or server rules before changing another unrelated setting.
  • 5. Run the redirect checker again. After this step, check the public value tied to run the redirect checker again before changing another unrelated setting.

Why this order matters for cloudflare

The sequence begins with the provider/authority decision, then moves through confirm WordPress Site URL and Home URL use the intended HTTPS hostname, confirm the origin serves HTTPS directly, use a Cloudflare SSL mode compatible with the origin. That keeps the change scoped to the failed TLS, certificate and HTTPS path and avoids replacing nameservers, mail authentication or another healthy service just to make a provider dashboard indicator change.

Verify Fix a WordPress redirect loop behind Cloudflare

HTTPS should complete for the exact hostname, the certificate should be valid for that hostname, and root/www should follow the intended canonical redirect without a TLS error. Compare the same confirm WordPress Site URL and Home URL use the intended HTTPS hostname and confirm the origin serves HTTPS directly evidence used before the change; a repair is complete when the public result agrees, not merely when the cloudflare interface reports that a save succeeded.

If cloudflare and the public result disagree

Check whether the edited zone is authoritative, whether the exact root/www/subdomain was changed, whether a proxy state alters the visible endpoint, and whether a prior TTL can still exist in recursive caches. Do not add a second conflicting confirm WordPress Site URL and Home URL use the intended HTTPS hostname value to force validation.

Mistakes to avoid for this repair

Do not copy tenant-specific or region-specific values from another account, delete working email records during a website repair, change nameservers as a shortcut, or alter SSL/proxy modes without evidence from the origin. Fix a WordPress redirect loop behind Cloudflare should change only the settings required by this diagnosis.

Technical references

These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.