Fix library

How to fix a site still on HTTP

The Brimm team · grounded in the docs

You fix a site still on HTTP by installing a certificate, then 301-redirecting every HTTP URL to its HTTPS twin and cleaning up mixed content. Google has treated HTTPS as a ranking factor since 2014, when it announced “we're starting to use HTTPS as a ranking signal” on the official Search blog. The signal is light. The trust cost of HTTP is not. Browsers stamp your site “Not secure,” and machines read the same warning.

The symptom: the browser calls your site Not secure

Every major browser puts a “Not secure” label in the address bar of an HTTP page. Your customers see it before they see your headline. Forms on the page trigger harsher warnings still. In search, Google has counted HTTPS on its side of the scale since 2014, and its page experience documentation lists serving pages securely among the questions it asks of every site.

There is a quieter symptom too. If both http:// and https:// versions of your pages respond, you are running two copies of your site, and engines have to guess which one is real. Links split between them. The canonical picture blurs. Google's own canonicalization guidance says it prefers HTTPS pages over equivalent HTTP pages, so the version you keep linking internally may not be the version Google keeps.

The cause: the site never migrated, or migrated halfway

Full HTTP sites still exist, usually because they were built before certificates were free and nobody has touched the hosting since. But the more common case in 2026 is the half migration. A certificate got installed at some point, so https:// works, and then nobody finished the job:

No redirect. Both protocols serve 200s, so the duplicate-site problem above is live.
Mixed content. The page is HTTPS but loads images, scripts, or stylesheets over http://, so browsers block assets or downgrade the padlock.
Stale plumbing. Canonical tags, sitemap URLs, and internal links still say http://, quietly voting for the wrong version on every page.
An expired certificate, which is worse than none. Visitors get a full-screen browser warning and most of them leave.

The fix: certificate, redirect, then clean the references

First, get the certificate. This costs nothing. Let's Encrypt issues free certificates and most hosts and CDNs now provision one with a single setting. If your host wants to charge you for basic TLS, that is a reason to question the host, not a reason to stay on HTTP.

Second, redirect. Every HTTP URL must answer with a 301 to the exact same path on HTTPS. Site-wide, not just the homepage, so every old link and bookmark lands on the secure twin:

# nginx: send every HTTP request to its HTTPS twin
server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}

<!-- Then update the plumbing on every page -->
<link rel="canonical" href="https://example.com/page" />

Third, clean the references. Search your templates and content for hardcoded http:// and update them: image sources, script tags, stylesheets, internal links. Update the canonical tag on every page to the HTTPS URL. Regenerate the sitemap so it lists only HTTPS URLs, since a sitemap full of redirecting addresses is its own problem, covered in our guide to XML sitemap errors. Finally, add the HTTPS version as a property in Search Console, because Google treats it as a separate site and your data lives there now.

Be honest: HTTPS will not rescue bad content

We will not oversell this fix. Google's 2014 announcement called HTTPS a lightweight signal affecting fewer than 1% of global queries at the time, carrying less weight than content quality. That is still the honest read. Moving to HTTPS does not push a thin page past a good one, and anyone promising a rankings jump from a certificate is selling folklore. The real stakes are trust and access. Browsers warn users away from HTTP. Payment forms on HTTP are close to malpractice. And the machine readers now deciding what to cite, from Googlebot to the AI crawlers, live in an HTTPS-default web where an HTTP-only site reads as abandoned. Fix it because it is 2026 and the fix is free, not because it is magic.

Verify: check the redirect, the padlock, and the plumbing

Test the redirect directly. Request an HTTP URL and confirm a single 301 hop to the same path on HTTPS, with no chains. Load a few pages and confirm the padlock shows with no mixed-content warnings in the browser console. Then spot-check the plumbing: canonicals say https://, the sitemap lists https://, internal links resolve without a redirect.

Then verify it the way the engines will. Re-run an audit on the live URL and confirm the whole chain reads clean. You can do this by hand, or paste your link into the full Brimm audit and we will follow the redirects, read the canonical, and flag any http:// still hiding in the plumbing. If your site is secure and still absent from AI answers, the causes usually sit deeper, and our guide on why your site is not in AI search walks the full list, as does the rest of the fix library.