HTTPS and SSL Setup Basics: Getting the Padlock Right

Having an SSL certificate isn't the same as your whole site actually using it. To get the padlock right you need four things: a certificate installed (free and automatic on any decent host), every visitor redirected from HTTP to HTTPS, no "mixed content" — insecure resources loaded on a secure page — and your site's own configuration pointing at the HTTPS address. Miss any of them and browsers show a "not secure" warning even though a certificate exists. The good news is that on a modern host most of this is close to automatic.

Step 1: Install the certificate (usually already done)

On any reputable host, a free certificate from Let's Encrypt is installed and auto-renewed for you, often the moment your domain points at the server. Check your hosting control panel's SSL section to confirm a valid certificate is active for your domain and any subdomains. If it isn't, most panels have a one-click "issue Let's Encrypt certificate" button. You should not have to buy anything at this step — if a host is pushing a paid certificate for a normal site, that's a flag, as explained in free SSL explained.

Step 2: Force HTTPS with a redirect

A certificate does nothing for a visitor who arrives at the plain HTTP version of a page. You need a redirect that sends all HTTP traffic to HTTPS automatically, so nobody can load the insecure version. Many hosts have a "force HTTPS" toggle in the control panel; if not, it's a short rule in your site's configuration. On WordPress, setting both the site address and home URL to the https:// version, plus a simple redirect, handles it. After you enable it, visit your site at the http:// address and confirm it jumps to https:// — that round-trip test is the fastest way to know the redirect works.

Step 3: Fix mixed content

Mixed content is the most common reason a site with a valid certificate still shows "not secure." It happens when a secure (HTTPS) page loads a resource — an image, script, stylesheet or font — over insecure HTTP. Browsers flag the page because that one insecure resource can be tampered with in transit. The fix is to make every resource load over HTTPS: update hard-coded http:// links in your content and theme, and use protocol-relative or https:// URLs. Your browser's developer console lists exactly which resources are the problem, and on WordPress a database search-and-replace from http:// to https:// on your own domain usually clears the bulk of it in one pass.

Step 4: Update your site's own settings

Finally, make sure the site knows it lives at the HTTPS address. Update your CMS's configured site URL, update any hard-coded absolute links, and update analytics and search-console properties to the HTTPS version so your data stays intact. If you use a CDN or Cloudflare in front of the site, set its SSL mode to "Full" (ideally "Full (strict)") so the connection is encrypted all the way to your origin, not just to the edge — the weaker "Flexible" mode can leave the origin leg unencrypted and cause redirect loops. These settings are what make HTTPS consistent rather than partial.

Optional: HSTS for the extra mile

Once HTTPS is solid, you can add HTTP Strict Transport Security (HSTS), a response header that tells browsers to only ever connect to your site over HTTPS, closing a small window where a first visit could be downgraded. It's a genuine hardening step, but enable it only after you're confident everything works over HTTPS, because it's sticky — browsers remember it — and turning it back on and off is awkward. For most sites, getting steps one to four right is the important part; HSTS is a sensible finishing touch, not a starting point.

None of this requires a paid certificate or a security expert — it's configuration, and a good host makes most of it one-click. If you're choosing a host, free auto-renewing SSL and a simple "force HTTPS" option should be standard; every host in our most secure web hosting ranking includes them.

Common HTTPS mistakes to avoid

A few mistakes trip people up repeatedly. Using Cloudflare's 'Flexible' SSL mode when your host already has a certificate causes redirect loops and leaves part of the path unencrypted — use Full (strict) instead. Issuing a certificate for example.com but forgetting www or a subdomain produces name-mismatch warnings on those addresses. Hard-coded http:// links in a theme or in old content reintroduce mixed content after you think you're done. And forgetting to update your CDN, analytics and search-console properties to the https:// version quietly loses data or serves stale, insecure assets. Work through each one after switching, because 'the padlock shows on the homepage' doesn't mean every page and subdomain is clean.

Why getting HTTPS right matters beyond security

HTTPS isn't only about encryption anymore; it's about trust and visibility. Browsers label plain HTTP pages 'not secure', which visibly undermines confidence, especially on any page with a form. Search engines have treated HTTPS as a lightweight ranking signal for years, and some modern browser features and APIs simply won't run on an insecure origin. Practically, that means HTTPS should be in place before you launch, not bolted on later, and it should be complete — every page, every subdomain, every resource — rather than partial. The effort is small and mostly one-time on a good host, and the payoff is a site that looks trustworthy, ranks a touch better, and doesn't scare away the visitor who's about to type in their email.

One more setup detail closes the loop: pick a canonical version of your domain — with or without www — and redirect the other to it, so you're not maintaining two addresses and your certificate, internal links and analytics all agree. Whichever you choose, make sure the SSL certificate covers both forms so neither throws a warning. It's a small thing, but a mismatch here is a common cause of the 'secure on one URL, not secure on the other' confusion, and fixing it once keeps every visitor on a single, properly encrypted address.