Redirect Chain Contains HTTP: How to Fix It

What the warning means

A redirect chain is a series of redirects a visitor passes through before reaching a page that loads. The warning redirect chain contains http means at least one step in that series is an insecure http:// address, even though the request started on, or ends up at, a secure https:// one. The classic pattern is:

https://example.com/about    301  →  http://example.com/about/
http://example.com/about/    301  →  https://example.com/about/
https://example.com/about/   200

The visitor asked for a secure page and was sent back to the insecure version for one hop before being sent forward again. Three things go wrong:

• Security. The http request travels unencrypted. On a shared or hostile network it can be read or altered, and someone in the middle can stop the visitor being sent back to https at all. Cookies without the Secure flag are sent in the clear.
• Speed. Each hop costs a round trip, and the jump between http and https often needs a new connection. On mobile networks two extra hops can add several hundred milliseconds before the page starts loading, which counts towards LCP.
• Crawling. Googlebot follows up to 10 redirect hops, so a short chain still works, but every hop wastes crawl effort and makes it harder for search engines to settle on the right URL. Long chains are also where loops start.

Browsers can also show a warning when a form on a secure page submits to an address that redirects through http, which stops sign-ups and checkouts.

Where the http hop comes from

The fifth cause catches many people out. If Cloudflare, a load balancer or a reverse proxy handles https and talks to your server over plain http, the server thinks every request is http. Any redirect it builds with an absolute address, such as adding a trailing slash to a directory, will therefore start with http://.

How to trace the chain

Use curl rather than a browser, because browsers cache permanent redirects and apply HSTS silently, both of which hide hops. This prints every status line and Location header in order:

curl -sIL https://example.com/about | grep -iE '^(HTTP/|location:)'

Typical output for the problem looks like:

HTTP/2 301
location: http://example.com/about/
HTTP/1.1 301 Moved Permanently
Location: https://example.com/about/
HTTP/2 200

The protocol switch from HTTP/2 to HTTP/1.1 is a clue: the middle hop was served over plain http. To see just the hop count and the final address:

curl -sIL -o /dev/null -w '%{num_redirects} redirects, final: %{url_effective}\n' https://example.com/about

Test every starting variant, because each can have its own chain:

for u in http://example.com/about https://example.com/about \
         http://www.example.com/about https://www.example.com/about; do
  echo "== $u"; curl -sIL "$u" | grep -iE '^(HTTP/|location:)'
done

Once you know which hop writes http, look at the response headers for that hop. A Server: cloudflare or cf-ray header means Cloudflare answered; x-redirect-by: WordPress or a plugin name means the CMS did; a plain Server: nginx or Apache points at the server configuration.

The key configuration changes

Apache and .htaccess

Force https and the preferred host in a single rule, placed before any other redirects:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

Then search the rest of the file for any target starting http:// and change it to https, or to a relative path such as /new-page/. The Apache redirects guide covers ordering in more detail.

nginx

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.com;
    absolute_redirect off;
    # trailing slash rule, now pointing at https
    rewrite ^([^.]*[^/])$ https://$host$1/ permanent;
}

absolute_redirect off makes the redirects nginx generates itself, such as directory slashes, use a relative Location, so they cannot pick up the wrong scheme. On Plesk, put these rules in Additional nginx directives; see redirects on Plesk.

WordPress

Check and correct the site address with WP-CLI, then rewrite old links in the database, always with a dry run first:

wp option get home
wp option get siteurl
wp option update home 'https://www.example.com'
wp option update siteurl 'https://www.example.com'
wp search-replace 'http://www.example.com' 'https://www.example.com' --skip-columns=guid --dry-run

If WordPress sits behind a proxy that ends TLS, add this to wp-config.php above the line that says to stop editing, so it knows the request was secure:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Cloudflare

Set the SSL/TLS mode to Full (strict) rather than Flexible, so Cloudflare connects to your server over https and the origin sees secure requests. Check any Redirect Rules for targets that begin with http. The Cloudflare redirects guide explains rule order.

A worked example

An audit flags https://example.com/about as a redirect chain containing http. Tracing it with curl shows three hops ending at https://www.example.com/about/, with the first hop going to http://example.com/about/.

The nginx configuration contains this trailing-slash rule, written years ago when the site ran on http:

rewrite ^([^.]*[^/])$ http://$host$1/ permanent;

Its target is hard-coded to http, so the server sends secure visitors to the insecure address, the http server block sends them to https on www, and only then do they reach the page. The rule is changed to send visitors to the final address in one hop:

rewrite ^([^.]*[^/])$ https://www.example.com$1/ permanent;

After nginx -t and a reload, curl shows one 301 from https://example.com/about straight to https://www.example.com/about/, then a 200. The same mistake in Apache usually appears as a RewriteRule with an http:// target, and the fix is the same: point it at the final https URL.

The fix, step by step

Edge cases worth knowing

• Your browser shows no http hop, but the audit does. If HSTS is already on, the browser upgrades the http step internally, shown in DevTools as a 307 Internal Redirect. First-time visitors and crawlers without that HSTS entry still go through the real http hop.
• The chain only happens on some paths. Directory URLs, uploaded files and old campaign paths often have separate rules. Test a sample of each type, not just the home page.
• Other hosts. The www host, old domains and parked domains all need their own direct redirects to the final https address.
• Canonical tags and sitemaps on http. These do not create a redirect, but they tell search engines the http URL is preferred, which keeps crawlers starting at the wrong address. Update them along with internal links.
• Mixed content. Images and scripts with http addresses can also redirect through http. The mixed content redirects guide covers those.

Keeping redirects clean

When every hop is https and each old URL reaches its destination in one step, lock the result in:

1. Add an HSTS header once https works across the whole site, starting with a short max-age and raising it to a year when you are confident: Strict-Transport-Security: max-age=31536000; includeSubDomains. See HSTS missing from an https server.
2. Write new redirects with relative targets such as /new-page/ where your platform allows, so they always keep the current scheme and host.
3. Keep redirects in one place, either the server, the CMS or the CDN, not spread across all three.
4. Re-run a redirect check after any hosting move, CDN change or plugin update. The redirect chains guide covers longer chains of every kind.