Home › Blog › Article

HTTPS for WordPress: Certificates, Mixed Content, Redirects

HTTPS for WordPress: Certificates, Mixed Content, Redirects

To set up HTTPS on WordPress in 2026 you issue a TLS certificate (Let’s Encrypt via Certbot 2.8 or your host panel), point both WordPress Address and Site Address to https://, force 301 redirects at the web server level, then rewrite any http:// asset URLs to https:// or protocol-relative so no mixed content remains. You know it worked when the browser padlock is green, DevTools Console shows zero mixed-content warnings, every internal URL returns 301 to HTTPS, and an SSL Labs test rates A or higher. This hands-on tutorial walks through preparation, execution, verification and rollback.

Preparation Before You Touch HTTPS

Back up files and database first. Use WP-CLI 2.9 or newer: wp db export backup.sql and archive wp-content with tar -czf content.tar.gz wp-content. Confirm DNS resolves correctly and port 443 is open. Check your current site URL with wp option get home and wp option get siteurl. If you run a staging clone, verify it separately so you do not redirect production traffic by accident; see our notes on setting up a WordPress staging environment safely to keep environments isolated.

Issuing and Renewing Certificates

In 2026 the standard free certificate authority is Let’s Encrypt, and Certbot 2.8 is the reference client. Install it with Snap or your package manager, then request a certificate for your domain and the www variant. Use the webroot plugin so you do not stop Nginx or Apache during issuance.

Issue with Certbot

sudo certbot certonly --webroot -w /var/www/html 
  -d example.com -d www.example.com 
  --agree-tos -m admin@example.com --no-eff-email

Certificates land in /etc/letsencrypt/live/example.com/ with fullchain.pem and privkey.pem. Renewal is automatic because Certbot installs a systemd timer; test it with sudo certbot renew --dry-run. If you use a commercial certificate instead, generate a CSR with OpenSSL 3.2 and install the bundle the same way. Common pitfall: forgetting the www SAN leads to certificate-name-mismatch errors; fix by reissuing with both names. Rollback: move the old certificate files back or temporarily set the server to serve the previous cert path, then re-run Certbot with corrected domains.

Step-by-Step WordPress HTTPS Setup Process

  1. Install or renew the TLS certificate for all hostnames.
  2. Point virtual host to certificate and key files, then reload.
  3. Update WordPress Address and Site Address to https in wp-admin or via WP-CLI.
  4. Add a forced 301 redirect rule for HTTP to HTTPS.
  5. Scan and rewrite mixed content in the database and theme files.
  6. Purge caches and re-verify with browser tools and SSL Labs.

Get a Quote

Email + requirement + budget range — we reply with a quote within 24 hours.

Finding Mixed Content

Mixed content happens when an HTTPS page loads CSS, JS, images or iframes over http://. Open Chrome DevTools, go to Console, and load a page; blocked requests appear as "Mixed Content: The page at … was loaded over HTTPS but requested an insecure …". For a full-site audit use the WordPress plugin Really Simple SSL 8.0 or run a database search.

Database search and replace

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

Remove --dry-run once counts look right. Also grep your theme for hardcoded URLs: grep -r "http://" wp-content/themes/your-theme/. Replace them with esc_url( home_url( '/path' ) ) or protocol-relative //example.com/path. Pitfall: serialized data can break if you use a naive SQL replace; WP-CLI handles serialization correctly. Rollback: restore the backup SQL with wp db import backup.sql and revert theme edits from version control.

Site URL and Forced Redirect

Update the core options so WordPress generates correct links. In wp-admin go to Settings → General and set both fields to https, or run wp option update home 'https://example.com' and wp option update siteurl 'https://example.com'. Then enforce HTTPS so every request is upgraded before it reaches PHP.

Nginx redirect

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

Apache redirect

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

Reload with sudo systemctl reload nginx or sudo systemctl reload apache2. Verify with curl -I http://example.com; the response must be HTTP/1.1 301 Moved Permanently and a Location: https://... header. Pitfall: redirect loops occur if you also set a plugin-level redirect while behind a proxy; disable plugin redirects when handling it at the server layer. Rollback: comment out the redirect block, reload, and set the options back to http temporarily. Teams planning a move often pair this with our guide on migrating WordPress to a new host to avoid URL regressions.

Behind a Reverse Proxy

When WordPress sits behind Cloudflare, an ELB or Nginx reverse proxy, the origin often receives plain HTTP on port 80 while the client sees HTTPS. WordPress then generates http links and may loop on redirects. Fix it by trusting the forwarded protocol header.

Detect HTTPS behind proxy

// In wp-config.php above the "stop editing" line
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) 
     && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}

Also set the proxy to send X-Forwarded-Proto: https. In Nginx as a proxy use proxy_set_header X-Forwarded-Proto $scheme;. Verify by loading the site and checking that wp_login_url() outputs https. Pitfall: trusting X-Forwarded-Proto from any client is a spoofing risk; only trust it if the proxy overwrites the header. Rollback: remove the wp-config block and revert the proxy header rule.

Verification Checklist

Verification Checklist
  • Run curl -I https://example.com and confirm HTTP/2 or HTTP/3 200 with valid cert.
  • Open DevTools Console on ten key pages; zero mixed-content warnings.
  • Test curl -I http://example.com returns 301 to https.
  • Submit the domain to SSL Labs; target rating A or higher in 2026.
  • Check wp option get home and siteurl both start with https.

Rollback Plan

If the site breaks: restore the database from backup.sql, revert theme and wp-config edits from Git, remove server redirect blocks, reload the web server, and switch DNS or proxy settings back to the pre-change state. Keep the old certificate path noted so you can serve the previous cert within minutes. Always test rollback on staging first using the same procedure described in our WordPress pre-launch checklist.

Action Checklist

  • Issue or renew the certificate with Certbot and confirm auto-renewal.
  • Update home and siteurl to https and force 301 at the server.
  • Replace http asset URLs and eliminate mixed content.
  • Configure proxy headers if behind a reverse proxy.
  • Verify with curl, DevTools and SSL Labs, then document rollback.

Need expert help implementing this? Our team handles certificate automation, mixed-content cleanup and proxy-aware redirects every day. Explore our custom WordPress development services to get HTTPS done right.

Frequently asked questions

How long does a WordPress HTTPS setup take?

For a standard site with Certbot and WP-CLI access, expect 30 to 60 minutes including verification. Complex multisite or proxy setups take longer.

Will forcing HTTPS hurt my SEO?

No. Search engines prefer HTTPS and a proper 301 redirect preserves rankings. Broken mixed content that blocks assets can hurt crawling, so fix those URLs.

What if my certificate expires by mistake?

Re-run certbot renew --force-renewal or restore the previous certificate files and reload the web server, then investigate why the timer failed.

References & further reading

Need WordPress Development?

Free proposal and quote within 24 hours — we serve clients worldwide.

QQ