HTTPS is no longer optional. Browsers warn users on HTTP pages, modern web platform features refuse to work without it, and Google has used HTTPS as a ranking signal for over a decade. But HTTPS is also where many SEO migrations go wrong — broken redirects, mixed content, expired certificates, and missing HSTS configuration cost real traffic. This guide covers certificate setup, HSTS, mixed content, security headers, and the HTTP-to-HTTPS migration playbook that protects rankings.
Why HTTPS Matters for SEO
- Ranking signal. Lightweight, but confirmed since 2014.
- Browser warnings. Chrome, Firefox, Safari all flag HTTP pages with "Not Secure" labels that destroy user trust.
- Modern web platform features. Service Workers, Web Push, geolocation, camera, Payment Request, WebAuthn — all require HTTPS.
- Referrer data. HTTPS-to-HTTP requests strip the Referer header, so HTTP destinations lose attribution from HTTPS sources.
- HTTP/2 and HTTP/3. Effectively HTTPS-only in major browsers, and meaningfully faster than HTTP/1.1.
Certificates
Domain validated (free)
Let's Encrypt issues free DV certificates with 90-day validity, auto-renewed by ACME clients (Certbot, acme.sh) or your hosting platform. Every major host, CDN, and platform (Cloudflare, Vercel, Netlify, AWS, GCP) handles Let's Encrypt automatically. This is the right choice for almost every site.
Organization validated (paid)
OV certificates include validated organization details. Modern browsers no longer display these distinctively, so the marketing benefit has largely disappeared. Use only when industry compliance or B2B procurement specifically requires it.
Extended validation (paid)
EV certificates went through enhanced identity verification. Browsers stopped showing the green EV company name in 2019-2020. Not worth the premium in 2026 for most use cases.
Wildcard and SAN
Wildcard certificates (*.example.com) cover all single-level subdomains. SAN (Subject Alternative Name) certificates list multiple explicit hostnames. Let's Encrypt issues both at no cost.
HSTS Configuration
HSTS (HTTP Strict Transport Security) is a response header that instructs browsers to always use HTTPS for your domain.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
max-age— how long the browser remembers (in seconds). 31536000 = 1 year.includeSubDomains— applies to all subdomains.preload— signals you want inclusion in the HSTS preload list shipped with browsers.
Ramp safely: start with max-age=300 (5 minutes), confirm nothing breaks, increase weekly to 3600, 86400, 604800, and finally 31536000. Once stable at 1 year, submit to hstspreload.org.
Caution: HSTS preload is essentially permanent — browsers cache it for a year, and removal from the preload list takes browser release cycles. Do not preload until you are committed to HTTPS for the foreseeable future.
Mixed Content
Mixed content is an HTTPS page loading HTTP resources. Browsers block active mixed content (scripts, iframes, stylesheets) entirely; passive mixed content (images, video) is loaded with console warnings.
Common mixed content sources
- Hard-coded
http://URLs in HTML, CSS, or JavaScript - Image and asset references in database content from before HTTPS migration
- Third-party embeds (videos, widgets, ads) served over HTTP
- CDN configurations not yet updated to HTTPS
- Old WordPress posts with hard-coded HTTP image URLs
Auditing for mixed content
- Open DevTools > Console — warnings flag mixed content on the active page.
- Crawl with Screaming Frog and filter for mixed content.
- Database search-and-replace tools (WP-CLI
search-replace, Better Search Replace plugin) for content stores. - Set
Content-Security-Policy: upgrade-insecure-requestsas a transitional defense — browsers auto-upgrade HTTP subresources to HTTPS.
Security Headers
Beyond HTTPS, modern sites benefit from a baseline of security headers — many indirectly improve trust signals search engines factor in.
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'; ...
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()
Cross-Origin-Opener-Policy: same-origin
X-Frame-Options: DENY (or CSP frame-ancestors)
Validate at securityheaders.com — target A or A+.
HTTP-to-HTTPS Migration Playbook
- Obtain and install the certificate on origin and CDN.
- Test HTTPS access on staging or as a separate URL; verify rendering.
- Update internal absolute links in templates, content, CSS, JS.
- Update database content with search-and-replace for HTTP image and asset URLs.
- Update canonical tags and sitemap to
https://URLs only. - Configure 301 redirects from every
http://URL to itshttps://equivalent. Preserve full URL paths and query strings. - Verify redirects with curl or a crawler — every HTTP URL should return 301 to HTTPS counterpart.
- Update Search Console — add the HTTPS property, verify ownership, submit the new sitemap.
- Update analytics, ad campaigns, social profiles, email signatures to HTTPS URLs.
- Monitor Search Console for crawl errors, indexed page counts, and ranking changes for 4-6 weeks.
- After stable operation (typically 4+ weeks), enable HSTS starting with a short max-age and ramping up.
Common Pitfalls
- Expired certificates. Set up monitoring (UptimeRobot, BetterStack) with alerts at 30 days before expiry. Auto-renewal scripts can fail silently.
- Redirect chains.
http://www.example.com→https://www.example.com→https://example.comshould be one hop, not two. - Missing redirects for subdomains or alternative entry points (with-trailing-slash, lowercase, etc.).
- Mixed content in third-party embeds — work with vendors or remove them.
- HSTS preload regret. Submitting before HTTPS is rock-solid leaves you stuck.
- Forgetting to update robots.txt and sitemap URLs from HTTP to HTTPS.
Configure Robots.txt for Your HTTPS Site
Generate a clean robots.txt referencing your HTTPS sitemap — a required step after migration.
Robots.txt Generator →