Defaults.Exposed › Fixes › HTTPS & forced-secure redirect

How to fix HTTPS & forced-secure redirect

HTTPS is the padlock in the browser bar — it encrypts everything that travels between your website and your customers so it can't be read or tampered with in transit. The forced-secure redirect makes sure visitors land on that encrypted version automatically, even when they type your address without 'https://'. Together they are the single most basic thing a website needs to be considered safe at all.

Bottom line for your business: Without HTTPS, every password, card number and message a customer sends you crosses the internet as readable text, and Chrome, Edge, Safari and Firefox all stamp your site 'Not secure' for every visitor before they read a word. Without the redirect, even sites that have a certificate leave the very first visit unprotected. Both cost you trust, sales and search ranking — and both are free to fix in minutes.

What this can cost you

• A first-time visitor sees a big 'Not secure' warning the moment your page loads. Most assume the site is fake, broken or unsafe and leave for a competitor — and you never even know the sale was lost.
• A customer enters their card details or logs in over an unencrypted connection from a café, hotel or airport. Someone on the same WiFi reads it in plain text, and the fraudulent charges that follow get blamed on you.
• A larger client's procurement or security team runs a quick scan before signing, sees no HTTPS or a missing forced-secure redirect, and parks the contract until you can prove it's fixed.
• Google ranks you below competitors who serve HTTPS, so you quietly lose search traffic for years without ever connecting it to this gap.
• A regulator or your payment provider treats sending personal or card data unencrypted as a reportable failure, turning a five-minute free fix into a compliance problem.

Why it matters. HTTPS is the floor, not the ceiling, of web security — it is what makes the padlock appear and what stops everything your customers send from being read or altered on the way. The forced-secure redirect closes the gap that a certificate alone leaves open: people almost never type 'https://', so without a redirect their first request travels unprotected before the secure version ever loads. A site missing either of these looks unsafe to visitors, ranks lower in search, and exposes real customer data — which is why this is the heaviest-weighted single failure we score.

What this is, in plain words

HTTPS is the secure, encrypted version of your website — the one that shows a padlock in the address bar. When a visitor is on HTTPS, everything that passes between their browser and your site (the pages they see, the forms they fill in, their passwords, their card details) is scrambled so that nobody in between can read it or change it. The plain version, HTTP, sends all of that as readable text that anyone on the same network can intercept.

There are two parts to getting this right, and we check both:

• Is HTTPS available at all? Does your site have a working security certificate so that the secure, padlocked version exists? This is the more serious of the two — without it there is no encryption at all.
• Does your site force visitors onto it? Almost nobody types “https://” by hand. If someone types just your domain name, their browser tries the plain HTTP version first. A forced-secure redirect automatically bounces that request to the encrypted version. Without it, the first moments of every visit are unprotected even when you do have a certificate.

You want both. A certificate with no redirect is a locked front door that visitors can simply walk around.

The business stakes

This is the most basic signal of whether a website is safe — and crucially, it’s one your customers can see for themselves. Every modern browser (Chrome, Edge, Safari, Firefox) labels a site without HTTPS as “Not secure” right in the address bar, and shows a warning if anyone tries to type into a form. Your visitors don’t need to know what a certificate is to react to that word.

Beyond the visible warning, this affects three things owners care about directly: trust (people abandon sites that look unsafe), search ranking (Google has used HTTPS as a ranking signal for years and favours secure sites), and real exposure (data sent over plain HTTP genuinely can be read by others on the same network). It’s also the kind of thing a bigger client’s security team checks in seconds during due diligence — and missing it can stall a deal.

What this can cost you

• The silent bounce. A potential customer clicks through from a search result or an ad, and the page loads with a grey “Not secure” badge — or worse, a full-screen warning. They don’t email you to ask why; they just close the tab and click the next result. You paid for that visit and lost it before they read a word, and nothing in your analytics tells you why.
• An intercepted login or payment. A customer signs in or checks out while on shared WiFi at a hotel or café. Because the connection isn’t encrypted, someone nearby captures their password or card number in plain text. The fraud that follows gets reported as your breach, and you’re the one fielding the angry calls and the chargebacks.
• The deal that stalls. A larger prospect is ready to sign, but their procurement process includes a quick security check of your website. It comes back flagging no HTTPS, or a missing forced-secure redirect. Suddenly you’re explaining a basic security gap instead of closing — and the contract waits, or quietly goes to a competitor who passed the check.
• The slow ranking leak. Two businesses offer the same thing; one serves secure HTTPS and one doesn’t. Search engines nudge the secure one higher. Over months you lose a steady trickle of free traffic and never connect it to this one setting.
• Injected content you never wrote. On an unencrypted connection, anyone in the middle — a dodgy public network, a compromised router — can insert fake pop-ups, scam offers or malware into your pages as a visitor loads them. To that visitor, it looks like your site did it.

What it actually is

When a browser connects to a website over HTTPS, two things happen. First, the site presents a certificate — a credential issued by a trusted authority that proves the site is who it claims to be. Second, the browser and the server agree on an encryption key and use it to scramble everything they exchange. Our first check, HTTPS available, simply asks: can we make a secure TLS connection to your site on the standard secure port (443) and get a valid certificate back? If yes, the padlock can appear and encryption is on. If no, there is no secure version of your site at all — and that’s the single heaviest failure we score.

The second check, the forced-secure redirect, covers a gap the certificate alone leaves open. People type “yourbusiness.com”, not “https://yourbusiness.com”. That bare request goes to the plain HTTP version first. A redirect is a one-line instruction that says “send anyone who arrives on the insecure version straight to the secure one.” Our check asks: when we request your plain HTTP address, does your site bounce us to HTTPS? If it does, every visitor ends up protected no matter how they typed your address. If it doesn’t, that first unprotected hop carries whatever the browser sends — cookies, form data — in the clear.

What “good” looks like: a valid, trusted certificate so the padlock shows on every page, and every plain-HTTP request automatically redirected to the HTTPS version (ideally with a permanent “301” redirect, which also passes your search ranking cleanly to the secure address).

How to fix it (free, ~15 minutes)

Hand this section to your IT person or your hosting provider’s support — the fix is free. Both parts of this cost nothing: trusted certificates are free and renew themselves, and turning on the redirect is a single setting on most platforms. There is no paid product needed to pass this.

There are two things to switch on. On most modern hosting, doing the first often makes the second a one-click toggle.

1. Get a certificate so HTTPS works (the padlock).

• Cloudflare: if your site is behind Cloudflare, SSL is handled for you. Set the SSL/TLS mode to “Full” (or “Full (strict)” if your origin server also has a certificate).
• Website builders and managed hosting (Squarespace, Wix, Shopify, Webflow, GoDaddy Website Builder, most Microsoft 365 / Google Workspace web hosting): HTTPS is provided automatically; just make sure it’s enabled in your site/domain settings — there’s usually nothing to install.
• cPanel hosting: open SSL/TLS Status and run AutoSSL, which issues a free Let’s Encrypt certificate.
• Your own server (VPS): install Let’s Encrypt with Certbot — sudo certbot --nginx -d yourdomain.com (or --apache). It fetches and installs a free certificate and sets up auto-renewal.
• Anything else: contact your hosting provider’s support and ask them to “enable a free SSL certificate for my domain.” Almost all offer this at no cost.

2. Force every visitor onto HTTPS (the redirect).

• Cloudflare: SSL/TLS → Edge Certificates → turn on “Always Use HTTPS.” That’s the whole job.
• Website builders (Squarespace, Wix, Shopify, etc.): look for a “Force HTTPS” or “Secure (HTTPS)” toggle in your site settings and switch it on.
• Nginx: add a server block on port 80 that returns a permanent redirect — return 301 https://$host$request_uri;.
• Apache (.htaccess): enable rewriting and redirect any non-HTTPS request — RewriteEngine On, RewriteCond %{HTTPS} off, RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301].
• IIS (Windows hosting): install the URL Rewrite module and add an “HTTP to HTTPS” redirect rule.

After both are on, test it: type your address with plain http:// in front and confirm the browser jumps to the padlocked https:// version automatically, and that the padlock shows on your main pages.

Common mistakes

• Certificate installed, but no redirect. The most common gap. You see the padlock when you visit your own site (because your browser remembered HTTPS), so you assume it’s done — but new visitors who type the bare domain still land on HTTP first. Always test the plain http:// version explicitly.
• Mixed content. Your page loads over HTTPS but pulls in an image, script or font from an old http:// address. Browsers either block it or downgrade the padlock to a warning. Update those references to https:// (or to relative links). Most platforms have a “mixed content” or “insecure content” report that finds them.
• A temporary (302) redirect instead of a permanent (301) one. A 302 works for visitors but tells search engines the move is temporary, so ranking value doesn’t transfer cleanly to your secure address. Use a permanent 301.
• Redirecting only the bare domain, not “www” (or vice versa). Make sure both yourdomain.com and www.yourdomain.com end up on HTTPS, otherwise one path is still exposed.
• Letting a certificate expire. A lapsed certificate throws a full-screen browser error that stops visitors cold. Free Let’s Encrypt certificates auto-renew; if you bought one manually, set a calendar reminder well ahead of its expiry.

FAQ

See the questions above — they cover the non-technical “can I do this myself,” the difference between having a padlock and forcing the redirect, certificate cost and renewal, whether brochure sites need it, and how this relates to HSTS.

FAQ