SSL and HTTPS for WordPress: Setup, Mixed Content and Renewals

Setting up WordPress SSL properly takes about an hour, costs nothing on most hosting, and yet roughly half the sites that land on my desk have it half-done: a certificate that works but a padlock that disappears on random pages, an http version of the site quietly competing with the https one in Google, or a renewal that fails silently until the Saturday morning the whole site shows a full-screen browser warning. HTTPS has been table stakes for years – browsers mark plain http pages as “Not secure”, Google treats it as a ranking signal, and no payment provider will talk to a site without it – so the question is no longer whether to do it but whether it is actually done.

This guide is the complete, honest version: what SSL and TLS actually protect (less than most people think, and also more), which certificate type you really need (almost always the free one), how to get a certificate and force HTTPS without redirect loops, how to find and permanently fix mixed content, how to survive the every-90-days renewal cycle, and what HTTPS means for SEO, forms and payments. I have moved hundreds of WordPress sites to HTTPS over 12+ years, including plenty that were “already on HTTPS” but leaking http URLs everywhere, and the same dozen problems account for nearly all of the pain.

Table of contents

• What SSL and TLS actually protect – and what they do not
• Certificate types honestly: free vs DV, OV and EV
• Getting a certificate: host one-click, certbot and Cloudflare
• Forcing HTTPS properly: site URL, 301s and HSTS
• Mixed content: finding it and fixing it for good
• Renewals and monitoring: the every-90-days reality
• SSL and SEO: killing the http duplicate
• Forms, payments and what the rules require
• Common SSL errors and what they actually mean
• How to check your setup properly
• When the padlock still does not mean “safe”
• Frequently asked questions

What SSL and TLS actually protect – and what they do not

First, the naming: SSL is technically the old protocol, TLS is the modern replacement, and everyone still says “SSL certificate” anyway. I will too. What the certificate and the encrypted connection give you is three concrete things:

• Encryption in transit. Everything between the visitor’s browser and your server – passwords, card details, form entries, session cookies – travels encrypted. Anyone sitting on the network in between (public Wi-Fi, a compromised router, an ISP) sees noise, not data.
• Integrity. The page cannot be modified on the way. Without HTTPS, a hotel or airport network can (and some do) inject adverts or tracking into your pages. With it, what your server sends is what the visitor sees.
• Authentication of the domain. The certificate proves the browser is talking to the real example.com and not an impostor answering for it on the network level.

Just as important is what SSL does not do, because this is where site owners get a false sense of safety. It does not make your site secure. A WordPress site with an outdated plugin, an admin password of “Company2019” and no backups is exactly as hackable over HTTPS as over http – the attack simply travels encrypted. It does not protect data at rest: if your database is breached, the certificate is irrelevant. And it says nothing about who runs the site – a point I will come back to at the end, because phishing sites have padlocks too. SSL is one layer in a security stack, alongside the basics I cover in common WordPress security mistakes. Necessary, nowhere near sufficient.

Certificate types honestly: free vs DV, OV and EV

Certificate vendors have a strong commercial interest in making this complicated. It is not. There are three validation levels, and for almost every WordPress site the free option is the correct one:

• DV (Domain Validation) proves you control the domain. That is what Let’s Encrypt and ZeroSSL issue for free, and what your host’s one-click SSL almost certainly is. The encryption is exactly the same strength as on any paid certificate.
• OV (Organisation Validation) adds a check that a registered company is behind the domain. The visitor sees no difference in the browser – the company name is buried in certificate details nobody opens.
• EV (Extended Validation) is a deeper company vetting. Browsers used to show the company name in a green bar; they removed that years ago because it demonstrably did not help users make better decisions. EV now looks identical to DV in the address bar.

The honest summary: encryption strength does not vary by price, browsers no longer reward EV visually, and Google does not care which type you use. Paid certificates make sense when a corporate compliance document demands OV/EV, when you need a specific warranty on paper, or when a legacy setup cannot automate renewals and you would rather buy a one-year certificate than script anything. For everyone else – small business sites, blogs, agencies, WooCommerce stores taking payments through Stripe or PayPal – free DV with automated renewal is not the budget option. It is the industry default.

One genuinely useful variant is the wildcard certificate (*.example.com), which covers unlimited subdomains. Let’s Encrypt issues those free too, though they require DNS-based validation, which is slightly more setup. If you run a multisite network on subdomains, you want one.

Getting a certificate: host one-click, certbot and Cloudflare

There are three realistic routes, and which one you use is mostly decided by your hosting – a topic with its own trade-offs, covered in how to choose WordPress hosting.

• Host one-click (most sites). Every decent host – shared or managed – has a “free SSL” or “Let’s Encrypt” toggle in the panel (cPanel calls it AutoSSL, Plesk has an extension, managed WordPress hosts do it silently). Enable it, wait a few minutes for issuance, done. Renewal is the host’s problem. If a host in 2026 charges extra for basic SSL, that tells you something about the host.
• Certbot on your own server (VPS). On a VPS you install certbot, run it against your web server config, and it obtains the certificate, edits the config and installs a renewal timer. The whole process is a few minutes; the important part is verifying that the automatic renewal actually works, which I cover below.
• Cloudflare (with one big caveat). If your DNS runs through Cloudflare, you get HTTPS between the visitor and Cloudflare automatically. The caveat is the SSL mode setting, and it matters enormously.

The Cloudflare “Flexible” trap deserves its own paragraph. In Flexible mode, the visitor connects to Cloudflare over HTTPS – padlock visible, everyone happy – but Cloudflare connects to your server over plain http. The leg of the journey across the open internet between Cloudflare and your host is unencrypted. Your visitors see a padlock; their data still travels in the clear for part of the trip. Flexible mode also causes the single most common redirect-loop error in WordPress (more on that under errors). The fix is always the same: install a certificate on your origin server (Let’s Encrypt, or Cloudflare’s free Origin CA certificate, which lasts up to 15 years) and set the SSL mode to Full (strict). Flexible is a temporary crutch for servers that cannot host a certificate at all, and almost no server fits that description any more.

Forcing HTTPS properly: site URL, 301s and HSTS

A certificate being installed does not mean your site uses it. WordPress will happily keep generating http links forever until you tell it otherwise. The order of operations matters, so here it is as I actually do it on client sites:

1. Back up first. Full files and database. The database step below rewrites thousands of rows; you want an undo button.
2. Confirm the certificate works by loading https://your-domain.com directly. Ignore styling errors for now – you only care that the connection is valid, with no browser warning.
3. Change both URLs in Settings > General. “WordPress Address” and “Site Address” both switch from http:// to https://. From this moment WordPress generates https links for pages, feeds, canonicals and enqueued assets.
4. Add a site-wide 301 redirect from http to https at the server level – a few lines in .htaccess on Apache or a server block on Nginx, and most hosting panels have a “Force HTTPS” toggle that does it for you. A 301 is a permanent redirect, which is what search engines need to transfer the http URLs’ standing to their https twins. Make it a single hop: http://example.com/page should go straight to https://example.com/page, not bounce through the homepage or through http://www first. Every extra hop wastes crawl budget and milliseconds.
5. Rewrite old URLs in the database – the mixed content step, big enough to get its own section below.
6. Only then consider HSTS. HSTS (HTTP Strict Transport Security) is a response header that tells browsers: for the next N seconds, never even attempt http for this domain. It closes the small window where the first request travels over http before the redirect. It is a good header – but it is a commitment. Once a browser has seen it, it will refuse http for your domain until the timer expires, so if your certificate breaks, there is no “proceed anyway” for visitors. Start with a short max-age like 300 to test, raise it to six months or a year once renewals have proven reliable, and only add the preload directive if you genuinely understand that getting off the preload list takes months.

Plugins like Really Simple SSL automate steps 3-5 and are fine for a quick fix – but understand what they do: most of them fix mixed content at runtime by filtering the page output on every request, which is a plaster, not a cure. On sites I maintain, I fix the actual URLs and redirects at the source so the site does not depend on a plugin for its padlock. If the plugin route gets a site secure today, take it – then do the permanent fix when you can.

Mixed content: finding it and fixing it for good

Mixed content is the classic half-done symptom: the page loads over HTTPS but something inside it – an image, a stylesheet, a script, a font – is still requested over http. Browsers respond in two ways. “Passive” content like images gets loaded but the padlock is downgraded or a warning shown. “Active” content like scripts and stylesheets is blocked outright, which is why a mixed-content site is not just insecure-looking but often visibly broken – missing styles, dead sliders, forms that do nothing. One single http asset is enough to lose the padlock on an otherwise perfect page.

Finding it is straightforward. Open the affected page, press F12 for the browser console, and look for “Mixed Content” warnings – each one names the exact http URL being requested. For a site-wide view, crawl the site with a tool that reports insecure content per page, or simply search your database for “http://your-domain.com” and see what comes back. In my experience the culprits are nearly always the same short list:

• Upload URLs in old content. Every image inserted before the switch has its full http URL stored in the post content. This is usually 90% of the problem by volume.
• Hardcoded URLs in widgets, menus and theme options – logos, background images and buttons configured years ago with absolute http links.
• Theme or plugin code that enqueues assets with a hardcoded http URL instead of the proper WordPress functions. Cheap themes love this.
• CSS files with http background-image URLs – invisible in the HTML, found only by searching the stylesheets themselves.
• External embeds – old map iframes, tracking pixels, fonts or badges from services that either moved to https long ago (change the URL) or no longer exist (remove them).
• A CDN or proxy still serving http – or the Cloudflare Flexible setup above quietly rewriting things back.

Fixing it properly means a search-replace on the database: every occurrence of http://your-domain.com becomes https://your-domain.com. The right tool is WP-CLI’s search-replace command or the Better Search Replace plugin – both handle serialized data, which matters because theme options and page-builder content store URLs inside serialized arrays where a naive SQL query would corrupt the data. Run it as a dry run first, look at the counts, then run it for real (you took that backup, remember). Hardcoded theme URLs get fixed in the code; external http embeds get updated or deleted. After the pass, click through your key templates with the console open – a clean console on the home page, a post, a product and the checkout is the finish line. This is exactly the same discipline as a domain move, which is why the process overlaps so much with migrating a website without losing SEO rankings.

Renewals and monitoring: the every-90-days reality

Let’s Encrypt certificates last 90 days by design – short lifetimes limit the damage of a stolen key and force everyone to automate. The industry as a whole is following: maximum lifetimes for all public certificates have been shrinking for years, so “buy one and forget it for three years” is dead regardless of vendor. That leaves automation, and automation fails silently, which is why expired certificates remain one of the most common outages I get emergency calls about – always on a weekend, somehow.

What a sensible renewal setup looks like:

• On managed and shared hosting: renewal is the host’s job, and good hosts do it invisibly. Your job is only to notice if they fail – see monitoring below.
• On a VPS with certbot: certbot installs a timer that attempts renewal twice a day once the certificate is within 30 days of expiry. Test that the whole chain works with a dry-run renewal, and remember that renewing the certificate is not enough – the web server has to reload to pick it up, so make sure a reload hook is configured.
• Know what breaks renewals: the validation request has to reach your server over plain http on the /.well-known/ path. Aggressive redirect rules, firewalls, security plugins blocking “suspicious” paths, or a DNS change (moving to a proxy, changing hosts) are the usual suspects when a renewal that worked for two years suddenly fails.
• Monitor independently. Do not rely on the system that renews the certificate to also tell you it failed. An external uptime monitor that checks certificate expiry and emails you at 21, 14 and 7 days before expiry costs nothing and turns a Saturday outage into a Tuesday-afternoon ticket. This is part of my standard monitoring on every maintenance client’s site.

The failure mode to appreciate: when a certificate expires, browsers do not show your site with a small warning. They show a full-page interstitial that most visitors cannot or will not click through – and if you enabled HSTS, they cannot click through it at all. An expired certificate is a total outage with extra reputational damage, because the error page says the word “security” in red.

SSL and SEO: killing the http duplicate

HTTPS has been a Google ranking signal since 2014 – a small one. The real SEO story around SSL is not the ranking boost; it is the damage a sloppy migration does. After the switch, every URL on your site exists in up to four versions: http, https, www and non-www. If more than one of them answers with content instead of redirecting, you have duplicate content splitting your link equity, and crawlers wasting budget on copies.

• One canonical version, 301s from the other three. Pick https + www or https + non-www and redirect everything else to it in a single hop. Test all four versions of your homepage and a deep URL by hand.
• Canonical tags and sitemap must agree. After the site URL change, WordPress SEO plugins regenerate both with https automatically – verify rather than assume, especially if any URLs are hardcoded in the SEO plugin’s settings.
• Search Console treats https as a separate property. Add the https version (or use a Domain property, which covers all variants), resubmit the sitemap, and watch coverage move from the old property to the new over the following weeks.
• Update the references you control: Google Business Profile, social profiles, email signatures, ad destination URLs. External links to http will follow the 301 and pass nearly all their value, so no panic there – but links you control may as well point at the real URL.
• Expect wobble, not disaster. A clean http-to-https move with proper 301s typically shows a few days to a few weeks of ranking fluctuation and then recovers fully. The horror stories all trace back to broken redirects, blocked crawlers or mixed content that made pages fail – not to the protocol change itself.

Forms, payments and what the rules require

If your site collects any personal data – a contact form counts – HTTPS stops being a nice-to-have and becomes a compliance requirement. GDPR requires appropriate technical measures for personal data, and transmitting form entries in plaintext over http fails that test in the eyes of every EU regulator that has commented on it. For clients in Germany especially, an http contact form is the kind of thing competitors’ lawyers notice.

For payments it is even less optional. PCI DSS, the card industry standard, requires strong encryption for card data in transit – modern TLS, with old protocol versions explicitly banned. In practice on WordPress this is handled sensibly: with Stripe, PayPal or hosted checkout pages, the card data goes from the visitor’s browser to the payment provider, not through your database, which keeps most of the PCI burden off your shoulders. But the providers require the page hosting the payment form to be served over valid HTTPS, and they will refuse to run in live mode without it. WooCommerce has a “force secure checkout” era behind it precisely because of this; today the whole store runs on HTTPS, full stop. A payment page with a certificate error does not degrade gracefully – it simply loses the sale, because no sane customer types card numbers past a security warning.

One subtlety worth knowing: what matters is the page where data is entered, not just the page where it is submitted. A form on an http page that posts to an https endpoint still exposes the visitor to tampering – the http page itself could have been modified in transit to post elsewhere. Everything goes over HTTPS; it is simpler and it is correct.

Common SSL errors and what they actually mean

Browser SSL errors look cryptic but map to a handful of causes. The ones I see on WordPress sites, in rough order of frequency:

• NET::ERR_CERT_DATE_INVALID – the certificate has expired (renewal failed, see above) or, occasionally, the visitor’s own device clock is wrong. If it works for you and not for one visitor, ask them to check their date settings.
• NET::ERR_CERT_COMMON_NAME_INVALID – the certificate does not cover the name being visited. Classic case: the certificate covers example.com but not www.example.com, or a subdomain is not on the certificate. Reissue with both names, or use a wildcard.
• ERR_TOO_MANY_REDIRECTS – the WordPress redirect-loop special. Nearly always a proxy setup: Cloudflare in Flexible mode sends requests to your server over http, WordPress sees http and redirects to https, Cloudflare fetches over http again, forever. Fix: Full (strict) mode with an origin certificate. The same loop happens behind load balancers when WordPress does not trust the forwarded-protocol header; the fix there is a few lines in wp-config.php to detect HTTPS from the proxy header.
• NET::ERR_CERT_AUTHORITY_INVALID – the certificate is self-signed or from an untrusted issuer, or the certificate chain is incomplete. Incomplete chains are sneaky: desktop browsers often repair them silently, older Android devices and some corporate networks do not, so “works on my machine, broken for some visitors” is the signature symptom.
• Mixed content warnings – not a certificate problem at all; see the section above.
• Handshake or protocol-version errors – the server only offers outdated TLS versions. On modern hosting this should not happen; if it does, the server needs its TLS configuration updated, not the certificate replaced.

The diagnostic habit that solves most of these: work out which leg is failing. Visitor to proxy/CDN, or proxy to origin? A page that loads with the CDN paused but fails through it tells you exactly where to look.

How to check your setup properly

Once everything is green in your own browser, spend fifteen minutes verifying it like an outsider:

• Run the domain through Qualys SSL Labs’ server test. It grades your TLS configuration from A+ down, flags weak protocol versions and cipher suites, and – crucially – catches incomplete certificate chains that your own browser hides from you. Aim for an A; on decent hosting you get it without touching anything.
• Test all four URL variants (http, https, www, non-www, plus a deep URL of each) and confirm one-hop 301s to the canonical version. A redirect checker shows the full chain; so does curl.
• Crawl for mixed content across the whole site, not just the homepage – archive pages and old posts are where http assets hide.
• Check the expiry date and who renews it. Click the padlock, read the certificate, note the date, and make sure a calendar other than your memory knows about it.
• Confirm HSTS is doing what you intended – present with a sensible max-age if you enabled it, absent if you did not (some hosts and plugins add it without asking).
• Load the site on a phone over mobile data, not just your desktop on office Wi-Fi. Different network path, different cache, occasionally a different result – and it is how most of your visitors arrive anyway.

Repeat the quick version of this check after anything that touches the stack: a hosting move, adding a CDN, a new page builder, a theme change. SSL setups do not decay on their own, but every infrastructure change is a chance to reintroduce an old problem.

When the padlock still does not mean “safe”

A closing point I make to every client, because it protects them and their customers: the padlock means the connection is encrypted and the domain is authenticated. It does not mean the site is trustworthy. Certificates are free and automated – which is good and correct – and that means phishing sites have padlocks too. A fake bank login page at a lookalike domain will show a perfectly valid padlock, because the criminals control that domain and legitimately obtained a certificate for it.

So teach the people around you the accurate version: the padlock’s absence is a red flag, but its presence proves only that you are talking privately to whoever owns the domain in the address bar. The security question is whether that domain is the one you meant to visit. For your own site, the padlock is the entry ticket, and the actual trust is built by everything else – a maintained, updated, monitored site that handles data properly. Treat SSL as chapter one of your security story, not the whole book.

Want your HTTPS setup done properly – and watched?

I set up and repair SSL on WordPress sites as part of my maintenance and security service – certificate setup, redirects, mixed content cleanup, HSTS and expiry monitoring – and handle the HTTPS side of every website migration I do. Have a look at my portfolio, or tell me what your padlock is doing – I reply within 24 hours, usually much faster.

Frequently asked questions

What is WordPress SSL and do I really need it?

SSL (technically TLS) encrypts the connection between your visitors and your WordPress site, shown by the https:// prefix and padlock. Yes, you need it: browsers flag http sites as “Not secure”, Google uses HTTPS as a ranking signal, and forms and payments legally and practically require it.

Is a free Let’s Encrypt certificate good enough for a business site?

Yes. The encryption is identical to paid certificates, and browsers display it identically. Paid OV/EV certificates only matter if a compliance policy specifically demands them.

Why does my padlock disappear on some pages?

Mixed content: something on those pages – usually an old image URL, a hardcoded script or a stylesheet – still loads over http. The browser console names the exact URLs; a database search-replace fixes most of them in one pass.

Why does my site show “too many redirects” after enabling SSL?

Almost always a proxy conflict, most often Cloudflare in Flexible SSL mode looping against WordPress’s own https redirect. Install an origin certificate and switch Cloudflare to Full (strict).

How often does an SSL certificate need renewing?

Let’s Encrypt certificates last 90 days and must renew automatically; paid certificates typically last one year. Either way, set up independent expiry monitoring – renewal automation fails silently, and an expired certificate takes the whole site offline behind a browser warning.

Does moving to HTTPS hurt SEO?

Done properly – single-hop 301 redirects, updated canonicals and sitemap, Search Console re-verified – you may see minor fluctuation for a few weeks, then full recovery. Lasting damage comes from broken redirects and mixed content, not from the protocol change.

Does HTTPS make my WordPress site secure?

No – it secures data in transit only. Outdated plugins, weak passwords and missing backups are unaffected by the padlock, so treat SSL as one layer of security, not the whole strategy.