What is SSL/TLS and why does WordPress need it?

SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) encrypt the connection between a visitor's browser and your server, protecting data in transit from eavesdropping and tampering. HTTPS is HTTP carried over a TLS connection. WordPress sites need it because all form data (logins, payments, contact submissions) is otherwise transmitted in plain text; Google has used HTTPS as a ranking signal since 2014; Chrome shows 'Not Secure' warnings on non-HTTPS pages; and modern performance protocols (HTTP/2, HTTP/3) require HTTPS.

Does an SSL certificate make my WordPress site fully secure?

No. SSL/TLS protects data in transit — the connection between browser and server. It does not protect data stored in your database, files on your server, or vulnerabilities in your application code. A site can hold a valid certificate and still be fully compromised through SQL injection, a vulnerable plugin, or a brute-force attack. SSL is one essential layer, not a complete solution. Many phishing sites use valid certificates — the padlock indicates an encrypted connection, not legitimacy.

What is mixed content on a WordPress site?

Mixed content occurs when an HTTPS page loads resources (images, scripts, stylesheets, iframes) over HTTP. Browsers block or warn about these because an HTTP resource can be intercepted and modified even when the page itself is encrypted. The most common WordPress causes are hardcoded HTTP URLs inside post content, themes, and plugin settings. Identify it with Chrome DevTools (Console shows mixed content warnings); fix it by updating URLs to HTTPS or running a database search-replace.

What is HSTS and should WordPress sites use it?

HTTP Strict Transport Security (HSTS) instructs browsers to only connect to your site over HTTPS, even if a visitor types http:// or follows an old HTTP link. Once the browser has seen an HSTS header, it automatically upgrades all future connections for the specified duration (typically 1 year), protecting against protocol downgrade attacks. Enable HSTS only after verifying every page and resource loads correctly over HTTPS — HSTS cannot be quickly revoked once browsers have cached it.

How do I fix common SSL certificate errors?

Certificate expired: renew it, or ensure automatic renewal is in place (Let's Encrypt certificates expire every 90 days). Certificate not trusted: switch to a CA recognised by all browsers — Let's Encrypt is universally trusted. Name mismatch: ensure the certificate covers your exact domain and any subdomains in use. Mixed content: update HTTP URLs to HTTPS throughout WordPress settings, themes, and content, typically with a database search-replace. On managed hosting, renewal and most configuration is handled automatically.

Is SSL a GDPR requirement for UK WordPress sites?

The UK GDPR requires 'appropriate technical and organisational measures' to protect personal data, without naming specific technologies. The Information Commissioner's Office (ICO) treats encryption in transit as a baseline measure for any site handling personal data — which includes any WordPress site with contact forms, newsletter signups, accounts, or WooCommerce checkout. A site that processes personal data over plain HTTP would struggle to argue it meets the 'appropriate measures' standard.

SSL and HTTPS for WordPress: A UK Business Guide -- WP Pro Host

If your WordPress site still shows “Not Secure” in the browser bar, or you have an SSL certificate installed but are unsure whether it is configured correctly, this guide covers what SSL does, the configuration mistakes that undermine it, and how to fix the most common problems. Proper HTTPS is no longer optional — 85% of online shoppers avoid websites that do not use HTTPS, Google ranks HTTP sites lower, and UK GDPR compliance effectively requires it for any site handling personal data.

What SSL/TLS actually does

SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) encrypt the connection between a visitor’s browser and your server. HTTPS is simply HTTP carried over a TLS connection. The encryption does three things:

Confidentiality — data in transit cannot be read by anyone intercepting the connection (ISPs, public Wi-Fi operators, network attackers).
Integrity — data in transit cannot be modified without detection. Without TLS, a malicious party on the network can inject code, replace images, or alter form submissions.
Authentication — the certificate verifies that the server you are connecting to is actually the one for that domain, not an impostor.

What TLS does NOT do: it does not protect data once it reaches your server, does not prevent vulnerabilities in your application code, and does not stop attackers who have legitimate access to your hosting account. A site can hold a perfectly valid certificate and still be completely compromised through SQL injection, a vulnerable plugin, or a brute-force login attack. SSL is one essential layer of security, not the whole solution.

Why HTTPS is no longer optional

Four separate pressures now make HTTPS mandatory in practice for any WordPress site:

Google ranking signal since 2014. Sites on HTTPS rank higher than equivalent sites on HTTP. The gap has widened over time as HTTPS became the expected default.
Chrome’s “Not Secure” label. Since 2018, Chrome (60%+ of desktop browser market) has labelled HTTP pages as “Not Secure” in the address bar. Users see the warning before reading any of your content.
Modern performance protocols require it. HTTP/2 and HTTP/3 — both of which deliver significant real-world performance improvements — are only supported by browsers over HTTPS. A site on HTTP is locked out of contemporary web performance.
UK GDPR. The Information Commissioner’s Office treats encryption in transit as a baseline “appropriate technical measure” for personal data. A WordPress site processing contact forms, newsletter signups, accounts, or WooCommerce orders over HTTP cannot credibly claim GDPR compliance.

Certificate types and what you actually need

Three types of certificate are commonly available:

Domain Validated (DV) certificates verify only that the person requesting the certificate controls the domain. They are issued automatically, often within minutes, and are free from Let’s Encrypt. For almost all WordPress business sites, DV is adequate. The padlock is identical to any other certificate in modern browsers.

Organisation Validated (OV) certificates additionally verify the legal identity of the organisation requesting them. They are typically paid and take 1-3 business days to issue. The browser’s certificate details panel shows verified organisation information; the padlock itself looks the same.

Extended Validation (EV) certificates apply the strictest identity verification. Historically they displayed the organisation name in green in the address bar. Modern browsers (Chrome, Firefox, Safari) have removed that indicator, which dramatically reduces EV’s practical value. They remain expensive and slow to issue.

For the vast majority of UK business WordPress sites, a Let’s Encrypt DV certificate is the correct choice — free, automatic renewal, universally trusted. Paid certificates make sense only in specific niche cases (some enterprise compliance contexts, very high-value ecommerce with specific insurance implications).

The common WordPress SSL mistakes

Having a certificate is not enough — it must be configured correctly. Five mistakes undermine SSL on WordPress sites regularly:

1. Mixed content

An HTTPS page that loads some resources over HTTP. The page itself is encrypted, but individual images, scripts, or stylesheets are not — and browsers either block them outright or display prominent warnings.

Causes: hardcoded HTTP URLs in post content, page builder blocks, theme templates, or plugin settings. The most common source is content imported or created before HTTPS was enabled, still referring to http://yourdomain.com/wp-content/....

Fix: Run a database search-replace using WP-CLI or a plugin like Better Search Replace:

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

Then audit with Chrome DevTools (Console tab) — any remaining mixed content resources show warnings. Themes and plugins with hardcoded HTTP URLs in PHP require manual patching.

2. No HTTP-to-HTTPS redirect

If your site works on both http://yourdomain.com and https://yourdomain.com, you have not actually enforced HTTPS — you have added it as an option. Search engines may index both versions (duplicate content), and any HTTP link from elsewhere on the web will land visitors on the insecure version.

Fix: Add a 301 redirect in .htaccess (Apache / LiteSpeed):

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

On managed hosting, this is typically handled at the server level without needing .htaccess edits.

3. Expired certificates

A certificate that has expired produces a full-page browser warning. Let’s Encrypt certificates expire every 90 days and must be renewed automatically; commercial certificates typically last 1-2 years. Expired certificates are almost always the result of either a failed auto-renewal (check the renewal cron job and account email for failure notices) or a lapsed paid certificate nobody remembered to renew.

Fix: Confirm automatic renewal is in place. For Let’s Encrypt via Certbot, certbot renew --dry-run will verify the renewal process works. On managed hosting, certificate renewal should be automatic and monitored — if your host cannot confirm that, that is a serious gap.

4. Hardcoded HTTP URLs in WordPress settings

WordPress stores its canonical URLs in wp_options under siteurl and home. If these are set to http://, WordPress generates HTTP URLs in navigation, emails, and REST API responses — even if every request comes in over HTTPS.

Fix: Update both in Settings → General, or directly:

UPDATE wp_options SET option_value = REPLACE(option_value, 'http://yourdomain.com', 'https://yourdomain.com')
WHERE option_name IN ('siteurl', 'home');

5. Missing HSTS headers

HSTS (HTTP Strict Transport Security) tells browsers to only connect over HTTPS for a specified duration, even if someone types http:// manually. Without HSTS, the first request of each session can still go over HTTP before being redirected — a window that can be exploited by an attacker on the network.

Fix: Add an HSTS header via .htaccess or server configuration:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Enable HSTS only after confirming that all pages and assets load correctly over HTTPS. Once a browser has cached the HSTS policy, it cannot be easily bypassed — testing must happen first.

SSL is not formally a GDPR requirement but is effectively mandatory under the “appropriate technical measures” clause. The UK GDPR requires data controllers (any WordPress site with contact forms, accounts, or order processing) to implement security measures appropriate to the risk. The Information Commissioner’s Office (ICO) treats encryption in transit as a baseline measure — processing personal data over plain HTTP would struggle to meet the standard.

Practical implications:

Any WordPress site with contact forms, newsletter signups, or user accounts must serve those forms over HTTPS
WooCommerce sites must have HTTPS covering all checkout, account, and order pages (PCI DSS compliance requires it independently of GDPR)
A breach notification in which the breached data was transmitted over HTTP is significantly harder to defend before the ICO

See our GDPR hosting responsibilities guide for the wider compliance picture.

Performance: HTTPS is faster now, not slower

The long-standing assumption that HTTPS hurts performance is outdated. Three factors have reversed it:

Modern hardware. TLS handshake overhead on contemporary CPUs is negligible. AES-NI instructions in modern processors handle the encryption with no measurable latency impact.
HTTP/2 and HTTP/3. Both require HTTPS. The multiplexing, header compression, and improved connection reuse in HTTP/2 typically produce larger performance gains than the TLS overhead costs.
TLS 1.3. The current TLS version reduces the handshake to a single round trip (down from two in TLS 1.2), with “0-RTT” resumption eliminating the handshake entirely for repeat visitors.

For WordPress specifically, running HTTPS with HTTP/2 and TLS 1.3 is faster than running HTTP alone — often by a meaningful margin on mobile connections.

A checklist for WordPress SSL health

Use this to audit any WordPress site:

Valid certificate that has not expired and covers the correct domain(s) including www if used
HTTP to HTTPS 301 redirect is in place and works from every URL structure
WordPress Settings → General has HTTPS for both “WordPress Address” and “Site Address”
No mixed content warnings in Chrome DevTools Console on any core page
HSTS header present (confirm with curl -I https://yourdomain.com | grep -i strict)
Certificate auto-renewal configured with a verified renewal process
HTTP/2 or HTTP/3 enabled at the server level
TLS 1.3 supported (confirm with SSL Labs scan)

An external tool like the free SSL Labs Server Test provides a full grade assessment — aim for A or A+.

SSL on managed hosting

On managed hosting built for WordPress, SSL is handled automatically: free Let’s Encrypt certificates issued and renewed on a 90-day cycle, automatic HTTP-to-HTTPS redirects, HSTS headers configured by default, TLS 1.3 enabled at the server level, and HTTP/2 and HTTP/3 available. Mixed content in existing content is the one area that typically requires a one-off clean-up after migration — a database search-replace covers the vast majority of cases.

If you are weighing the configuration effort of self-managed SSL against the automatic handling on managed infrastructure, see how our security approach compares and how managed and shared hosting differ on security fundamentals.

SSL and HTTPS for WordPress: A UK Business Guide