WordPress: fix HTTPS and WWW redirects and redirect loops
Your WordPress site loops or redirects to the wrong address? Check the site addresses, plugins, .htaccess and Cloudflare.
Common symptoms
The browser shows “Too many redirects”, an HTTP address comes back after an HTTPS redirect, or the site keeps switching between www and non-www. Several components may try to redirect the same request: WordPress settings, an SEO or SSL plugin, the web server and the CDN.
Step 1 — Check the WordPress addresses
In Settings → General, look at both fields:
- WordPress Address (URL): where the WordPress files live.
- Site Address (URL): the public address visitors use.
On a standard install at the root, both are often the same, for example https://example.com. Do not make them identical blindly if WordPress is installed in a subdirectory or if your host requires a specific setup. Do not change these settings before confirming that the certificate and redirects work: you could lock yourself out of the admin area.
If the fields are locked, look for the WP_HOME and WP_SITEURL constants in wp-config.php. Back up before changing anything.
Step 2 — Find conflicting rules
- Check plugins that handle redirects, HTTPS or the Cloudflare connection.
- Review the
.htaccessrules added by your host and those added by hand. On Apache or LiteSpeed, a custom rule usually goes before the standard WordPress rules. - If Cloudflare is active, check SSL/TLS → Overview, Always Use HTTPS, Redirect Rules and the SSL/TLS mode used with the origin server.
Common mistake: in “Flexible” mode, Cloudflare talks to the origin server over HTTP. If WordPress or the server immediately redirects to HTTPS, a loop forms. “Full (strict)” mode, with a valid certificate on the origin, is usually better when available.
Step 3 — Keep a single redirect strategy
Pick one HTTPS destination, with or without www, and decide which layer enforces it. Avoid having a plugin, Apache and Cloudflare all enforce different destinations at the same time. A permanent 301 or 308 redirect suits a lasting change.
Step 4 — Check SEO after the fix
- Internal links and the sitemap should point to the final addresses.
rel="canonical"tags should name the right addresses.- An important public page should not keep an accidental
noindexfrom the staging site. - After a domain change, keep the mapping between old and new pages as much as possible.
To replace links in the database, use a tool that handles WordPress serialized data, and back up first. A raw SQL replace can damage some options.
Step 5 — Test
Check your domain in Redirect Audit, then open /wp-login.php and an important inner page in your browser. Make sure you have created neither a loop nor an admin lockout.
These examples are a starting point: adapt them to your setup and test them before applying them to a live site.