HTTPS and trust signals

HTTPS has been a confirmed, if lightweight, Google ranking signal since 2014 — and independent of ranking directly, browsers have progressively made plain HTTP visibly untrustworthy: Chrome marks any HTTP page collecting input as "Not Secure" directly in the address bar, a trust signal a real visitor sees before a search engine ranking ever comes into play at all.

HTTPS enforcement, verified on a real site

HTTP/1.1 308 Permanent Redirect
Location: https://www.example.com/

Strict-Transport-Security: max-age=63072000

Both real, verified response headers from a live production site. The redirect ensures any HTTP request immediately becomes HTTPS; the Strict-Transport-Security header (HSTS) goes further — it tells a browser that's visited once to never attempt a plain HTTP connection to this domain again for the next two years (max-age=63072000 seconds), skipping the redirect round-trip entirely on every subsequent visit.

Security headers as a broader trust signal

X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

This exact header set is real, verified via a direct site audit. None of these are direct ranking factors the way HTTPS itself is — but they're part of the same overall trust and security posture search engines increasingly account for through broader page-experience signals, and they directly prevent real attack classes (clickjacking, MIME-sniffing exploits) that would otherwise put visitors at genuine risk.

Content-Security-Policy: the header worth getting right

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com

A real, verified CSP header — restricting which sources scripts, styles, and other resources can load from, directly mitigating cross-site scripting risk. Worth noting honestly: 'unsafe-inline' in a script-src directive (present here to support inline JSON-LD blocks, covered in part 11) does weaken the protection CSP is meant to provide — a stricter setup would use a nonce or hash instead. This is a genuine, common tradeoff in a real production CSP, not a solved problem in every deployment, including the one shown here.

Mixed content: the HTTPS trap

<!-- On an HTTPS page, this triggers a mixed-content warning -->
<img src="http://example.com/logo.png" />

A page served over HTTPS that loads even one resource over plain HTTP triggers a browser mixed-content warning — undermining the padlock icon a visitor was just shown. This is a common, easy-to-miss issue after migrating a site from HTTP to HTTPS: old hardcoded http:// references in a database, a CMS field, or an old cached asset URL, left over from before the migration.

What HTTPS alone doesn't fix

HTTPS encrypts the connection — it says nothing about whether a site's content is trustworthy, accurate, or authoritative. Those are separate, larger signals (E-E-A-T, covered fully in part 18) that HTTPS is a small, necessary-but-not-sufficient part of, not a substitute for.

Next: a technical SEO problem specific to modern JavaScript-heavy sites — what happens when the content a crawler needs isn't in the initial HTML at all.