HTTPS Done Right: Certificates, Redirects and Mixed Content

Most WordPress sites “have SSL”. Far fewer have HTTPS done right: one canonical redirect, zero mixed content, HSTS on top. The difference shows up as a broken padlock, browser warnings, blocked scripts — and a quiet SEO leak, since HTTPS has been a ranking signal for a decade and browsers now shame anything less.

Here’s the full path, in order.

1. The certificate

Let’s Encrypt is free, automated and universally trusted; every decent host issues and renews it in one click. Paying extra for a basic DV certificate in 2026 buys you nothing technical. Just confirm auto-renewal works — an expired certificate takes your site down as effectively as a server crash. (Renewal monitoring is part of maintenance that protects.)

2. One canonical redirect

Your site has four possible addresses: http://, https://, with and without www. Exactly one should survive; the other three must 301-redirect to it in a single hop.

First, set both WordPress Address and Site Address to the https:// version (Settings → General). Then redirect at the server:

NGINX:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Apache (.htaccess):

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

Chained redirects (http → https → https+www) waste crawl budget and add latency on every first visit — check yours with a redirect tracer or our analyzer, which reports the redirect count.

3. Mixed content: the padlock killer

Mixed content is an HTTPS page loading any resource over http://. Browsers block insecure scripts outright (breaking functionality) and flag insecure images (breaking trust). On WordPress it comes from two places:

Hardcoded URLs in the database. Years of content built on http:// leave thousands of absolute URLs in posts and options. Fix them with a proper search-replace that handles serialized data — WP-CLI is the clean way:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --precise

(Backup first. Never raw SQL on wp_options — serialized strings will corrupt.)

Theme and plugin files. Search your theme for http:// in enqueued scripts, fonts and embeds. Use protocol-relative or explicit https:// URLs. Third-party embeds that only exist on http don’t belong on your site anyway.

After cleanup, open DevTools → Console on your key pages: any “Mixed Content” warnings list the exact offending URLs. Our Site Analyzer also counts insecure http:// references in the page source, so you can verify from outside.

4. Lock it in with HSTS

Once — and only once — everything loads cleanly over HTTPS:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Now browsers refuse to ever try http:// for your domain, which closes the downgrade window on public Wi-Fi. HSTS is one of the six headers in our security headers guide — add the other five while you’re in the config.

5. The SEO checklist after migration

If you’ve just moved to HTTPS (or fixed a messy setup):

• Canonical tags point to https:// URLs — one place to check, big duplicate-content insurance.
• The XML sitemap lists https:// URLs only.
• Search Console has the https:// property, and it’s the one you monitor.
• Internal links in menus/widgets use relative or https:// URLs — no needless internal 301s.

The five-minute audit

Run the free analyzer: it verifies HTTPS on the final URL, counts redirects, flags mixed-content references and checks HSTS — the whole chapter in one scan. Green across those four means you’re not leaking trust, speed or rankings on transport-level basics — and you can spend your energy where WordPress actually gets attacked: the plugin layer.