HTTP to HTTPS Redirects: Fixing Mixed Content and Redirect Chains

Buying a certificate and turning on HTTPS is only half the job. If a visitor can still load the plain http:// version of your site, or if your page quietly pulls an image over an insecure connection, then the padlock is a false promise. This guide covers the three issues a redirect scan surfaces — incomplete redirects, redirect chains and mixed content — and how to fix each.

The HTTP to HTTPS redirect

When someone types your domain without https://, their browser tries plain HTTP first. Your server must respond with a permanent redirect to the secure version. The key word is permanent: use a 301, not a 302, so browsers and search engines remember it and stop attempting the insecure version.

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

Redirect chains: the hidden tax

A redirect chain is when one redirect points to another, which points to another, before the visitor finally lands on the real page. For example: http://example.com to https://example.com to https://www.example.com. Every hop costs time and a little security exposure, and search engines dislike them. The fix is to redirect straight to the final destination in a single hop, choosing one canonical hostname (with or without www) and sending everything there directly.

Mixed content: the broken padlock

Mixed content is when an HTTPS page loads a resource — an image, script, stylesheet or font — over plain HTTP. The browser flags it because that insecure resource could be tampered with in transit, undermining the encryption of the whole page. Active mixed content like scripts is often blocked outright, breaking your layout; passive mixed content like images shows a warning.

• Update hard-coded URLs in templates and the database from http:// to https://.
• Use protocol-relative or absolute HTTPS links for all assets, including third-party embeds.
• Add `Content-Security-Policy: upgrade-insecure-requests` to automatically rewrite insecure resource requests as a safety net.

Enforcing it permanently with HSTS

Once your redirects and mixed content are clean, add the Strict-Transport-Security header. From then on, browsers will refuse to even attempt an insecure connection to your domain, eliminating the brief HTTP request that a redirect still allows. It is the difference between fixing the problem and making it impossible to recur.

Real security lives in the details between a working certificate and a genuinely secure visit. Send every request to one canonical HTTPS address in a single hop, purge mixed content, lock it in with HSTS, and your padlock will finally mean exactly what your visitors assume it does.