HTTPS & Site Security

HTTPS has been a confirmed Google ranking signal since August 2014, and Chrome started shaming HTTP-only sites in 2018. By 2026, the conversation is no longer “should we use HTTPS” — it is whether your TLS configuration, HSTS preload, and security headers are doing the quiet work of keeping rankings safe. The penalties for getting this wrong run from “browser warning kills your CTR” to “site removed from index after a hack.”

TL;DR

• HTTPS is binary, then it is not. A valid certificate gets you the ranking signal; modern TLS, HSTS, and CSP keep you from losing it during incidents.
• HSTS preload is a permanent commitment. Once your domain is on the Chrome HSTS preload list, removing it takes weeks and the browsers refuse plain HTTP in the meantime.
• Hacked sites lose rankings in days. Google Safe Browsing flags compromised pages within 24 hours, and Search Console “Security Issues” suppresses the listing until you remediate and request review.

The mental model

HTTPS is like the lock on a hotel room door. The lock itself (a valid certificate) gets you a room — table stakes. HSTS is the rule that says guests can’t even try the wrong door; CSP is the policy that decides which staff can enter once you’re inside. Each layer fails differently: a missing lock means anyone walks in; a misconfigured policy means you locked yourself out.

The SEO consequence sits at every layer. A missing certificate means Chrome shows “Not Secure” in the address bar and CTR drops. A misconfigured certificate (expired, hostname mismatch, weak cipher) shows a full-page browser interstitial that suppresses traffic to zero. Mixed content (HTTPS page loading HTTP assets) breaks pages and silently signals a compromised security posture to crawlers.

The thing most teams underweight: search engines treat security incidents as quality signals. A site flagged by Safe Browsing, even briefly, can take weeks to recover its CrUX baseline and its impressions in Search Console. The cost of preventing an incident is always less than the cost of recovering from one.

Deep dive: the 2026 reality

The minimum acceptable TLS configuration in 2026:

Setting	2026 minimum	Notes
TLS version	TLS 1.2 minimum, TLS 1.3 preferred	TLS 1.0/1.1 disabled by all major browsers since 2020
Certificate authority	Let’s Encrypt, ZeroSSL, Cloudflare, AWS ACM	Free options are equivalent to paid for ranking
Key type	ECDSA (secp256r1 or secp384r1) preferred over RSA	ECDSA handshakes are 30–40% faster
HSTS	max-age=31536000; includeSubDomains; preload	Submit to hstspreload.org once stable
OCSP stapling	Enabled	Removes one DNS + TCP round-trip per session
Cipher suites	Modern only (no CBC, no RC4, no 3DES)	Test at ssllabs.com/ssltest — target A+

Google does not publicly enumerate every security header it considers, but the ones that demonstrably affect either ranking, CrUX measurement, or incident-recovery speed are:

• Strict-Transport-Security (HSTS) — confirms the site is HTTPS-only; required for Chrome HSTS preload.
• Content-Security-Policy (CSP) — limits where scripts, images, and frames may load from. CSP violations are an early warning signal during a compromise.
• X-Frame-Options / frame-ancestors — prevents your pages being embedded in malicious iframes (clickjacking).
• X-Content-Type-Options: nosniff — stops browsers MIME-sniffing responses, closes a class of XSS vectors.
• Referrer-Policy: strict-origin-when-cross-origin — preserves analytics referrer data without leaking paths.
• Permissions-Policy — disables unused browser features (camera, microphone, geolocation) that no longer need to be exposed.

HSTS preload is permanent in practice. Submitting your domain to hstspreload.org bakes the HTTPS-only rule into Chrome, Firefox, Safari, and Edge at compile time. Removing the entry requires a separate request and a multi-week update cycle through browser releases. Do not preload until you are certain every subdomain you serve is HTTPS-capable, including legacy www, mail, dev, and staging.

Mixed content is the modern compatibility tax. A page served over HTTPS that references an HTTP image, script, or stylesheet either gets the asset blocked (active mixed content like scripts) or downgraded with a warning (passive mixed content like images). Modern browsers auto-upgrade HTTP image URLs to HTTPS, but the auto-upgrade silently fails if the asset host doesn’t support HTTPS — and the broken image counts against LCP and CLS.

The 2024–2026 incident pattern that takes whole sites out of the index: compromised WordPress installations injecting cloaked spam links visible only to Googlebot. Google’s spam systems detect this within hours and demote or remove the affected URLs. Recovery requires removing the malware, hardening WordPress (admin password rotation, plugin updates, WAF rules), and a manual reconsideration request. Expect 4–12 weeks of suppressed traffic even after remediation.

Visualizing it

flowchart TD
  A[User requests example.com] --> B{Browser has HSTS for this host?}
  B -->|Yes preload or cached| C[Force HTTPS, no plaintext attempt]
  B -->|No| D[Try HTTP first then redirect]
  D --> E[Server responds 301 to HTTPS]
  E --> F[TLS handshake: cert, cipher, OCSP]
  F --> G{Cert valid + cipher modern?}
  G -->|No| H[Browser interstitial, blocks page]
  G -->|Yes| I[HTTPS page served]
  I --> J[Browser enforces CSP, frame rules]
  J --> K{All assets HTTPS?}
  K -->|No| L[Mixed content blocked or warned]
  K -->|Yes| M[Page renders, CrUX records visit]
  C --> F

Bad vs. expert

The bad approach

# HTTP and HTTPS both serve content; no HSTS, no security headers
server {
  listen 80;
  listen 443 ssl;
  server_name example.com www.example.com;

  ssl_certificate /etc/ssl/example.com.crt;
  ssl_certificate_key /etc/ssl/example.com.key;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

  root /var/www/example.com;
  index index.html;
}

<!-- HTTPS page with HTTP-loaded assets and inline scripts -->
<!DOCTYPE html>
<html>
  <head>
    <link rel="stylesheet" href="http://cdn.example.com/style.css" />
    <script src="http://analytics.example.com/track.js"></script>
  </head>
  <body>
    <img src="http://images.example.com/hero.jpg" />
    <script>
      eval(getQueryParam('cb'));
    </script>
  </body>
</html>

This is the worst common combination. HTTP is served alongside HTTPS, so search engines index two versions of every URL. TLS 1.0 and 1.1 are enabled, downgrading cipher quality. There is no HSTS, no CSP, no X-Frame-Options. The HTML loads scripts and styles over HTTP, which Chrome blocks for active content and warns on for passive. The inline eval(getQueryParam(...)) is a textbook reflected-XSS vector. Each issue compounds: the duplicate-content cost, the security-warning cost, the broken-asset CLS cost.

The expert approach

# Force HTTPS, modern TLS, HSTS preload, full security header set
server {
  listen 80;
  listen [::]:80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}

server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name www.example.com;
  ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
  return 301 https://example.com$request_uri;
}

server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name example.com;

  ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

  # Modern TLS only
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305";
  ssl_prefer_server_ciphers off;
  ssl_session_cache shared:SSL:10m;
  ssl_session_tickets off;
  ssl_stapling on;
  ssl_stapling_verify on;

  # HSTS — only enable preload after testing on subdomains
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

  # CSP — start in Report-Only, then enforce
  add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'sha256-AbCd...' https://www.googletagmanager.com; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; font-src 'self' data:; connect-src 'self' https://www.google-analytics.com; frame-ancestors 'self'; base-uri 'self'; form-action 'self'" always;

  add_header X-Content-Type-Options "nosniff" always;
  add_header Referrer-Policy "strict-origin-when-cross-origin" always;
  add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), interest-cohort=()" always;

  root /var/www/example.com;
  index index.html;
}

<!-- All assets served over HTTPS, no inline eval, integrity hashes on third-party scripts -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <link rel="stylesheet" href="https://cdn.example.com/style.css"
          integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
          crossorigin="anonymous" />
    <script src="https://analytics.example.com/track.js" defer
            integrity="sha384-Qvs1Q6vC2P8GZL1cT4jt8nUg4pK9b7gKrWCv2N5aJv3y7sM7rH2vJmq0F4xN1Lfn"
            crossorigin="anonymous"></script>
  </head>
  <body>
    <img src="https://images.example.com/hero.avif" alt="Hero" width="1280" height="720" />
  </body>
</html>

The HTTP server now redirects to HTTPS canonical (no www), and the www host redirects to apex — only one indexed origin. TLS 1.2/1.3 with modern ciphers, OCSP stapling enabled, session tickets off (forward secrecy). HSTS with includeSubDomains and preload — only flip preload after auditing every subdomain. CSP locks scripts to your origin plus a single GTM exception. Subresource Integrity (integrity=) on third-party scripts means a compromised CDN cannot silently swap in malware. No inline eval, no mixed content, no surplus permissions.

Do this today

1. Run Qualys SSL Labs test at ssllabs.com/ssltest. Anything below grade A is technical debt; anything below B is actively shedding traffic. The remediation report is your immediate punch list.
2. Open Mozilla Observatory at observatory.mozilla.org and scan your domain. It scores every security header and gives you the exact add_header directive for what’s missing.
3. In Google Search Console, open Security & Manual Actions → Security Issues. If anything is listed, stop everything else and remediate; nothing else matters until that page reads “No issues detected.”
4. In Cloudflare (or your edge), enable Always Use HTTPS, set SSL/TLS encryption mode to Full (strict), enable HSTS under Edge Certificates with max-age=31536000, includeSubDomains, and Preload unchecked until step 6.
5. Crawl your site with Screaming Frog SEO Spider and run Reports → Insecure Content. Every HTTP asset listed must be replaced with the HTTPS equivalent or moved to a host that supports it.
6. Audit every subdomain (mail, dev, staging, blog, shop) for HTTPS support. Once all pass, submit your apex to hstspreload.org and check Preload in Cloudflare. Expect 6–12 weeks for the entry to land in Chrome stable.
7. Roll out Content-Security-Policy in Report-Only mode first. Set Content-Security-Policy-Report-Only with a strict policy and report-to endpoint, watch real violations for 14 days, then promote to enforced.
8. Configure CAA DNS records restricting which CAs can issue certificates for your domain — 0 issue "letsencrypt.org" is the minimum; this prevents a compromised registrar from issuing rogue certs.
9. Set up certificate expiry monitoring in UptimeRobot, Cronitor, or your APM. Most outages are expired Let’s Encrypt renewals; alert at T-14 days.
10. Save the Google Search Console reconsideration request URL in your incident runbook so a hacked-site recovery doesn’t waste the first hour hunting for it: search.google.com/search-console/security-issues.