How to Fix a Site Not on HTTPS (No SSL)
Your audit flagged that this page loads over HTTP instead of HTTPS, so traffic between the visitor and your server is unencrypted and unauthenticated. This is a critical issue: Chrome labels HTTP pages "Not Secure," HTTPS is a confirmed Google ranking signal, and unencrypted pages can be intercepted or tampered with in transit. The fix is to install an SSL/TLS certificate (free ones work fine), serve everything over HTTPS, and add a permanent redirect so every HTTP request lands on the HTTPS version.
What this means
HTTP sends data between the browser and your server in plain text. HTTPS is the same protocol wrapped in TLS, so the connection is both encrypted and authenticated by a certificate. When your audit reports "site not on HTTPS," the page responded on http:// and either has no valid SSL/TLS certificate installed or isn't redirecting insecure requests to the secure version.
In a browser this shows up as a "Not Secure" label to the left of the URL, or a missing padlock. It's different from a mixed-content warning, where the page itself loads over HTTPS but pulls in some resources (images, scripts, stylesheets) over HTTP. Here the base document is insecure, which is the more serious of the two.
Two things have to be true to clear this: a valid certificate for your exact domain must be installed on the server, and HTTP requests must 301-redirect to HTTPS so there is one canonical secure address.
Why it matters
HTTPS has been a confirmed Google ranking signal since 2014. Google described it as lightweight relative to content quality, and it now functions as a baseline expectation rather than a bonus. A site still on HTTP competes at a disadvantage against secure competitors, and it loses users before ranking even matters.
The bigger cost today is trust and conversions. Since Chrome 68 (2018), every HTTP page is marked "Not Secure" in the address bar. Google is going further: in Chrome 147 (April 2026), "Always Use Secure Connections" is enabled by default for the users who have opted into Enhanced Safe Browsing, so they see a warning before Chrome loads a public HTTP site. In Chrome 154 (October 2026), that setting becomes the default for all users. A security warning on a checkout or contact page tanks conversions and pushes bounce rate up.
Security is the underlying reason all of this exists. Over HTTP, anyone on the network path (public Wi-Fi, a compromised router, an ISP injecting ads) can read passwords and form data or silently rewrite your page before it reaches the user. HTTPS closes that gap.
For AI answer engines and crawlers (ChatGPT, Perplexity, Google AI Overviews), HTTPS matters indirectly but concretely. These systems lean on content Google already indexes and trusts, and a page carrying a security liability is a weaker candidate for citation. Some fetch layers also refuse or downgrade insecure origins. If you want your content quoted as a source, serving it securely is table stakes.
How to fix it
- 1
Get an SSL/TLS certificate (free is fine)
You need a certificate issued for your exact domain by a trusted Certificate Authority. Let's Encrypt issues free, auto-renewing certificates and is the standard choice; most hosts also offer one-click free SSL. On a VPS or your own server, Certbot provisions the cert and edits your server config in one step:
sudo certbot --nginx -d example.com -d www.example.com(or--apache). It installs a renewal timer automatically, so the 90-day Let's Encrypt certificate renews without you touching it. Cover both the apex domain andwwwso neither version throws a certificate error. - 2
Enable HTTPS in your host or platform dashboard
On managed platforms you rarely touch a terminal. In cPanel, use AutoSSL or the SSL/TLS Status page to issue and install a certificate. On Shopify, Wix, and Squarespace, SSL is provisioned automatically once your domain's DNS is pointed correctly, so a missing certificate usually signals a DNS or domain-connection problem rather than a setting to toggle. Behind Cloudflare, set the SSL/TLS mode to Full (strict), not Flexible. Flexible leaves the Cloudflare-to-origin hop unencrypted and can cause redirect loops; Full (strict) requires a valid certificate on your origin and encrypts end to end.
- 3
Redirect all HTTP traffic to HTTPS with a 301
A certificate alone isn't enough; force every request onto HTTPS with a permanent redirect so search engines consolidate signals onto the secure URL. On Apache, add to
.htaccess:RewriteEngine On, thenRewriteCond %{HTTPS} offandRewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]. On Nginx, use a server block listening on port 80 withreturn 301 https://$host$request_uri;. On WordPress, the Really Simple SSL plugin does this in one click, and hosts like Kinsta and SiteGround have a Force HTTPS toggle. On Cloudflare, enable Always Use HTTPS under SSL/TLS then Edge Certificates. - 4
Update your canonical URL, sitemap, and internal links
Point everything at the HTTPS version. In WordPress, change both WordPress Address and Site Address under Settings then General to
https://. Confirm canonical tags outputhttps://(Yoast and Rank Math follow the site URL automatically once it's updated). Update hardcodedhttp://internal links and any absolute URLs in your XML sitemap. Leaving oldhttp://links around creates redirect chains that waste crawl budget and can trigger mixed-content warnings. - 5
Add HSTS once HTTPS works everywhere
After every page loads cleanly over HTTPS, add the HTTP Strict Transport Security header so browsers refuse to connect over HTTP at all:
Strict-Transport-Security: max-age=31536000; includeSubDomains. This removes the brief insecure request before the redirect fires and is a real hardening step. Add it only once you're certain HTTPS is solid across every subdomain, because HSTS is sticky in browsers and hard to walk back if something is still broken. - 6
Verify, then tell Google
Re-crawl the page and open it in an incognito window: you want a padlock, an
https://address, and no Not Secure label. In Google Search Console, add and verify the HTTPS property (it's separate from the HTTP one), submit your updated sitemap, and use URL Inspection to request re-indexing of key pages. Run a mixed-content check too, since fixing the base URL sometimes surfaces individual HTTP resources that still need updating tohttps://or protocol-relative paths.
Frequently asked
Yes. Google does not care who issued your certificate or what it cost, only that the connection is valid HTTPS. A free Let's Encrypt certificate delivers identical encryption strength and the same ranking benefit as an expensive one. Paid certificates mainly add organization validation, warranties, or support, none of which affect rankings. For most sites, a free auto-renewing certificate is the right choice.
Not if you do it correctly. The safe pattern is: install the certificate, 301-redirect every HTTP URL to its exact HTTPS equivalent, update canonicals and internal links, and add the HTTPS property in Search Console. Done this way, ranking signals transfer to the secure URLs and any dip is minor and temporary. Rankings only suffer when the migration is sloppy, such as redirecting everything to the homepage, creating redirect chains, or leaving mixed content behind.
The most common cause is that HTTP requests aren't being redirected to HTTPS, so visitors still land on the insecure version. Add a 301 redirect or enable your platform's Force HTTPS option. The second most common cause is mixed content: the page loads over HTTPS but pulls in images, scripts, or stylesheets over HTTP, which suppresses the padlock. Check the browser console for mixed-content warnings and update those resource URLs to https://.
Flexible encrypts only the browser-to-Cloudflare hop; the Cloudflare-to-origin hop stays plain HTTP, so your origin is still insecure and you can hit redirect loops. Full and Full (strict) encrypt both hops. Full (strict) additionally validates that your origin has a real, trusted certificate. Use Full (strict) with a valid certificate on your origin (Let's Encrypt or a free Cloudflare Origin CA cert). Avoid Flexible; it only papers over the problem.
Yes. Both http://example.com and http://www.example.com should redirect to your single preferred HTTPS version, for example https://example.com. Your certificate must cover both hostnames, or the one it doesn't cover throws a certificate error. Pick one canonical version, redirect all other combinations to it with 301s, and set that version as your site URL so you don't split ranking signals across four addresses.
Does your site have this issue?
Run a free, AI-powered audit and we’ll flag this and 150+ other checks in about a minute. No signup.