Google confirmed HTTPS as a ranking signal in 2014 and has steadily increased its weight since. In 2025, serving content over HTTP is no longer a neutral configuration choice — it is an active negative signal, a trust barrier for visitors, and a source of browser warnings that reduce conversion. But HTTPS is not simply ‘install a certificate and forget it.’ The details matter, and mixed content in particular can silently undermine the security of a site that believes it completed its migration years ago.
Why HTTPS Is a Ranking Signal
Google has been explicit: HTTPS is a lightweight ranking factor used as a tiebreaker between otherwise equivalent pages. In practice, a well-optimized HTTP page can still outrank a poorly-optimized HTTPS page — content quality and relevance are stronger signals. But between two pages with similar content and authority signals, HTTPS wins. The more important effect is on user trust: Chrome marks HTTP pages as ‘Not Secure’ in the address bar, which affects click-through rate from search results and conversion rates on the page. The indirect SEO impact of reduced trust and higher bounce rates is larger than the direct ranking signal in most competitive situations.
Getting the Certificate Right
Free certificates from Let’s Encrypt are standard now and adequate for most sites. Paid EV (Extended Validation) certificates no longer display the green address bar in modern browsers — Chrome removed it in 2019 — so there is no visual trust indicator that justifies the additional cost for typical marketing sites. Get a certificate that covers your domain and the www subdomain, or use a wildcard certificate if you have subdomains. Renew before expiration — an expired certificate blocks visitors with a full-page browser error and will be flagged immediately in any crawl. Set up automatic renewal; Let’s Encrypt certificates expire every 90 days by design.
The 301 Redirect Structure
Migrating from HTTP to HTTPS requires 301 redirects from every HTTP URL to its HTTPS equivalent. The critical detail: the redirect should go directly from http:// to https:// in a single hop, not through multiple intermediate redirects (http://example.com → http://www.example.com → https://www.example.com). Each additional redirect hop adds latency and dilutes link equity that passes through the chain. Audit your redirect structure with a crawl tool — multi-hop redirect chains from pre-migration URL patterns are common and easy to fix once identified.
After setting up redirects, update all internal links throughout the site to point directly to HTTPS URLs rather than relying on the redirect to handle them. Internal links that hit a redirect still work, but they waste crawl budget and are a sign of an incomplete migration that any thorough technical SEO audit will flag.
Mixed Content: The Silent Problem
Mixed content occurs when an HTTPS page loads resources — images, scripts, stylesheets, iframes — over HTTP. Browsers handle mixed content differently depending on the resource type:
- Passive mixed content (images, audio, video loaded over HTTP): Chrome loads it but shows a warning indicator. No functional block, but the connection is no longer fully secure and users on security-conscious browsers may see warnings.
- Active mixed content (scripts, stylesheets, iframes loaded over HTTP): Chrome blocks it entirely. JavaScript that fails to load silently breaks functionality. Visitors see a broken page without necessarily understanding why the buttons do not work or the form does not submit.
Mixed content typically survives an HTTPS migration because it lives in places that are easy to miss: hardcoded HTTP URLs in the database stored in post content and widget settings, external scripts loaded via HTTP from third-party providers, old CDN configurations that still serve assets over HTTP, and embedded iframes from services that had not yet migrated at the time the embed was created.
Fixing Mixed Content in WordPress
For WordPress, the most common source of mixed content is hardcoded HTTP URLs written into the database before the migration. The Better Search Replace plugin handles this without requiring direct SQL access — search for http://yourdomain.com and replace with https://yourdomain.com across all tables. Also update the WordPress Address URL and Site URL fields in Settings to HTTPS. Check your CDN configuration if you use one: asset URLs delivered by the CDN need to be HTTPS as well, not just the page HTML.
After making these changes, audit for residual mixed content using the Chrome DevTools Security panel or the WhyNoPadlock tool. The Security panel shows exactly which resources are loading over HTTP and from which URL — it is the most precise diagnostic for tracking down the last remaining mixed content sources.
HTTP Strict Transport Security (HSTS)
HSTS is an HTTP response header that instructs browsers to always connect to your domain over HTTPS, even if the user types http:// manually or follows an old HTTP link. It eliminates the brief insecure HTTP connection that occurs before the 301 redirect fires. Set an HSTS header with a max-age of one year once you are confident the HTTPS setup is working correctly across the entire site. The important caveat: do not set it prematurely. Browsers that have cached the HSTS directive will refuse HTTP connections for the full max-age duration. If you need to revert to HTTP for any reason during that window, users with the cached directive will be locked out.
Canonical Tags After Migration
After migrating to HTTPS, audit your canonical tags to confirm all of them reference HTTPS URLs. A canonical pointing to an HTTP URL tells Google the HTTPS version is a duplicate of an insecure page — the opposite of what you want. Canonical mismatches after HTTPS migrations are a common oversight when canonical tags are generated dynamically or hardcoded across many templates. Check them systematically with a crawl rather than spot-checking a few pages manually.
Search Console Property Setup
Google treats http:// and https:// as entirely separate properties in Search Console. Verify both, and ensure your primary HTTPS property is the one receiving your sitemap submission and is set as the preferred domain if you use that setting. Historical data from the HTTP property will not migrate automatically — but going forward, the HTTPS property is what matters for monitoring crawl health, indexation, and performance. If you see a sudden drop in impression data, confirm you are looking at the right property.
HTTPS is one of the foundational technical health checks that a full website audit covers. Mixed content issues and redirect chains surface alongside crawl and indexation problems — finding them together in one audit is more efficient than diagnosing them separately when something breaks. For the broader technical picture, indexation issues and technical SEO fundamentals are closely related areas worth reviewing alongside your HTTPS configuration.