HTTPS is no longer optional. Browsers label plain HTTP sites as “Not secure”, search engines prefer secure pages, modern browser features require it and visitors are understandably wary of entering anything into a site without the padlock. Free certificates mean cost is no longer an excuse.
Most WordPress sites are already on HTTPS, but I still regularly see problems from switches done halfway: padlock warnings caused by images loading over HTTP, redirect loops behind CDNs, HTTP versions of pages still indexed in Google and certificates that silently expired because renewal broke.
Here’s how to move a WordPress site to HTTPS properly, and how to make sure it stays that way.
What HTTPS does
HTTPS encrypts the connection between a visitor’s browser and your server using TLS. It protects:
- Confidentiality: passwords, form submissions and personal data can’t be read in transit.
- Integrity: content can’t be modified on the way, such as by networks injecting ads.
- Authenticity: the certificate confirms the visitor is talking to your domain, not an impostor.
The term SSL is still widely used, but modern connections use TLS. The terms are often used interchangeably.
Step 1: Get a certificate
Free certificates
Let’s Encrypt provides free, automatically renewed certificates trusted by all major browsers. Most hosts integrate Let’s Encrypt into their control panels, so enabling HTTPS may be a single click.
On your own server, Certbot obtains and installs certificates:
Certbot can configure Nginx or Apache automatically and sets up renewal.
CDN certificates
If you use a CDN that proxies your site, it provides a certificate for the connection between visitors and the CDN. You still need a certificate on your origin server for the connection between the CDN and your server, so traffic is encrypted all the way.
Paid certificates
Paid certificates with organisation or extended validation exist, but browsers no longer display them differently from free certificates. For most websites, free certificates are perfectly adequate.
Step 2: Make sure HTTPS works before switching
Before telling WordPress to use HTTPS, visit https://yourdomain.com in a browser and confirm the certificate is valid and the page loads. Check that both the www and non-www versions are covered by the certificate.
Step 3: Update WordPress URLs
In Settings, then General, change both the WordPress Address and Site Address to start with https. Or use WP-CLI:
Since WordPress 5.7, Site Health can detect when HTTPS is available and offers a button to switch, which also enables automatic rewriting of insecure URLs to the site’s own domain in content as it’s displayed. That’s helpful, but I still prefer updating stored URLs permanently, as described next.
Step 4: Fix URLs stored in content
Your database contains many URLs with http, in post content, image links, widget settings and plugin options. Update them with a serialisation-safe search and replace, after taking a backup:
Run it again for the www version if your old URLs used www. Then flush caches.
Avoid running plain text find and replace on SQL exports. WordPress stores serialised data with string lengths, and changing http to https changes those lengths, corrupting the data.
Step 5: Redirect HTTP to HTTPS
Every HTTP URL should redirect permanently to its HTTPS equivalent. Do this at the server level for speed and reliability.
On Nginx:
On Apache, in .htaccess above the WordPress rules:
Use 301 redirects, which tell search engines the move is permanent. Combine the HTTPS redirect with your preferred www or non-www choice, so visitors reach the final address in a single redirect, not a chain.
Step 6: Fix mixed content
Mixed content happens when an HTTPS page loads resources, like images, scripts, stylesheets or iframes, over plain HTTP. Browsers block insecure scripts and frames and may show warnings or remove the padlock for insecure images.
Find it
- Open the browser console on key pages; mixed content warnings list each insecure resource.
- Use a crawling tool that reports insecure resources across the site.
- Check page source for http:// references.
Common sources in WordPress
- Hard-coded URLs in theme files or custom code.
- Images and links inserted into content before the switch, fixed by the database search and replace.
- Widget and Customizer settings.
- Page builder data.
- Third-party embeds and scripts referenced with http.
- CSS files with background images using absolute http URLs.
Fix it
Update URLs to https or use relative URLs for your own resources. For third-party resources that don’t support HTTPS, find alternatives; any reputable service supports HTTPS today.
The Content-Security-Policy directive upgrade-insecure-requests tells browsers to load HTTP resources over HTTPS automatically. It’s a useful safety net, but fix the underlying URLs too.
HTTPS behind a proxy, load balancer or CDN
When a CDN or load balancer handles HTTPS and forwards requests to your server over HTTP, WordPress may think requests are insecure. Symptoms include redirect loops, admin login problems and mixed content.
Fixes:
- Use HTTPS between the CDN and your origin, with a valid certificate on the origin. Avoid “flexible” SSL modes that use HTTP to the origin.
- If your proxy passes an X-Forwarded-Proto header, tell WordPress to trust it, but only when requests genuinely come through your proxy:
Place this near the top of wp-config.php. Make sure your server only accepts traffic from the proxy, so visitors can’t fake the header.
Step 7: Force HTTPS in the admin
Add this to wp-config.php to ensure logins and the admin always use HTTPS:
Step 8: Enable HSTS
HTTP Strict Transport Security tells browsers to only ever connect to your site over HTTPS, even if someone types http or clicks an old link. It protects against attacks that try to downgrade connections.
Important cautions:
- Only enable HSTS once HTTPS works perfectly, everywhere.
- includeSubDomains applies to every subdomain. If any subdomain doesn’t support HTTPS, it will become unreachable for visitors who have seen the header.
- Start with a short max-age, like a few minutes or a day, then increase to a year once you’re confident.
- HSTS preload lists, built into browsers, are a further step. Removal from preload lists is slow, so only submit your domain if you’re sure every subdomain will support HTTPS permanently.
Step 9: Update external references
- Google Search Console: verify the HTTPS version, ideally with a domain property, which covers both. Submit your HTTPS sitemap.
- Analytics: update the site URL setting if needed.
- Social profiles and directory listings: update links to use HTTPS.
- Ad campaigns and email templates: update links.
- Canonical tags and sitemaps: make sure they use HTTPS. SEO plugins handle this automatically when the site URL changes.
Step 10: Keep certificates renewing
Let’s Encrypt certificates are short-lived and renew automatically, but renewal can break: changed DNS, firewall rules blocking validation, a moved site or a misconfigured web server. An expired certificate makes your site effectively unreachable, because browsers show full-page warnings.
- Test renewal on your own server: certbot renew –dry-run.
- Set up certificate expiry monitoring, which many uptime services include.
- If you use CAA DNS records, make sure they allow your certificate authority.
A common HTTPS mistake I still see
The most frequent HTTPS problem I fix is a site that works on HTTPS but still has HTTP URLs stored throughout the database, relying on plugins or browser upgrades to hide them. Everything appears fine until a plugin changes, a CDN setting is modified or a resource loads from a context that doesn’t upgrade, and suddenly mixed content warnings appear. Running a proper search and replace once, with a backup, removes the problem permanently.
Check HTTPS after every migration
Host moves, CDN changes and domain changes are when HTTPS problems most often appear. After any of them, check the certificate, redirects and the browser console for mixed content on your key pages.
Frequently asked questions
Does HTTPS help SEO?
HTTPS is a lightweight ranking signal, and more importantly, it’s expected by browsers and visitors. Sites without it face warnings that drive people away.
Why does my site still show “Not secure” after installing SSL?
Usually mixed content: some resources still load over HTTP. Check the browser console and update the URLs.
Will switching to HTTPS hurt my rankings?
Not if you use 301 redirects, update internal links and canonical tags and keep content the same. Minor fluctuations are normal during the transition.
Is a free certificate as secure as a paid one?
For encryption, yes. Free and paid certificates provide the same level of encryption. Paid options mainly differ in validation and support.
Final thoughts
A clean HTTPS setup involves more than installing a certificate. Get a trusted certificate, update WordPress URLs, fix stored content with a safe search and replace, redirect all HTTP traffic in one step, remove mixed content, configure proxies correctly, add HSTS carefully and monitor renewals. Done properly, HTTPS is invisible to visitors, apart from the reassuring padlock, and that’s exactly how it should be.
