How to Fix Your SSL Certificate on WordPress

Do these in order

This is the part people get wrong, and it is worth stating up front. Certificate first. Then force HTTPS. Then, only if you want it, HSTS.

Reversing that order is how sites go down. Turn on HSTS before HTTPS works everywhere and you have told browsers to refuse the only working version of your site.

Step 1: get a certificate installed

You almost certainly do not need to buy one. Your host provides a free certificate, and on cPanel that is AutoSSL. Let's Encrypt is the default AutoSSL provider for all new installations, and AutoSSL renews certificates that expire within 29 days, so once it works it keeps working.

If your certificate has expired or was never issued, go to cPanel > SSL/TLS Status and run AutoSSL manually. If it fails, the usual reason is a domain or subdomain in the list that does not point at this server, so AutoSSL cannot validate it. Exclude it and run again.

Not on cPanel? The same idea applies, look for your host's free SSL or Let's Encrypt option. If your host has none, that is a reason to consider a different host.

Step 2: tell WordPress it is on HTTPS

WordPress stores its own address, and it will keep building http:// links until you change it. Go to Settings > General and set both WordPress Address (URL) and Site Address (URL) to the https:// version.

You may be logged out after saving. That is expected, log back in at the https:// address.

To force the admin area and login over SSL, add this to wp-config.php, above the line that says it should stop editing.

define( 'FORCE_SSL_ADMIN', true );

This covers wp-admin and wp-login.php. It does not redirect the front end of your site, which is the next step.

Step 3: redirect HTTP to HTTPS

On Apache, this goes in .htaccess. Put it above the # BEGIN WordPress block, because WordPress rewrites what is inside that block.

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

If your site sits behind a proxy or a CDN, %{HTTPS} may not be set even on a secure request, which produces a redirect loop. In that case the correct condition depends on what your host puts in front of you, so ask them rather than guessing. Many hosts also have a Force HTTPS switch in their panel, which is simpler and worth using if it exists.

Step 4: hunt down mixed content

This is where most of the actual work is. Your certificate is valid, the padlock still will not appear, and the browser console is full of warnings. That is mixed content: a secure page loading an image, script or stylesheet over plain HTTP.

It comes from http:// URLs saved into your database over the years. Images in old posts. A logo path in your theme options. A script URL in a widget. Open your browser developer tools, look at the console, and it will name every offending URL.

The trap that breaks WordPress sites

The obvious fix is to run a SQL find and replace across the database, swapping http:// for https://. Do not do this.

WordPress stores a lot of settings, theme options and page builder data as PHP serialized arrays. Serialized data records the length of every string alongside it. Change http:// to https:// and the string is one character longer, but the recorded length is not updated, so the data no longer parses. WordPress then reads it as empty. Your theme settings vanish, your widgets go blank, and there is no error explaining why.

Use a search-replace tool that understands serialization. WP-CLI's search-replace command does, and so do several well-established standalone scripts and plugins. Whatever you use, take a database backup first. This is the step to be careful with.

Also, do not reach for protocol-relative URLs like //example.com/logo.png. That was a workaround for an era of mixed HTTP and HTTPS sites, and it is no longer recommended. Write the full https:// URL.

Step 5: HSTS, if you want it

Only once everything above is done and every page loads cleanly over HTTPS. HSTS tells browsers never to try HTTP for your domain again, which closes the small window during the initial redirect.

You set it as a response header. Our guide to security headers on WordPress covers where to put it and why the Apache always keyword matters.

Preloading is a separate decision, and a serious one. Getting on the preload list requires a max-age of at least 31536000, includeSubDomains, the preload directive, a valid certificate, an HTTP to HTTPS redirect on the same host, and every subdomain on HTTPS. Inclusion cannot easily be undone, and removal takes months to reach users through browser updates. If you have a subdomain you have forgotten about, preload will find it for you, in the worst way. Plain HSTS is a good idea. Preload needs a reason.

A note for WooCommerce

Same steps, higher stakes. A mixed content warning on a blog post is untidy. On a checkout page it costs you the order, because shoppers do not push through a browser security warning to hand over a card number.

After the switch, walk the whole flow yourself: product page, cart, checkout, payment, order confirmation email. Then run a check to confirm what your customers actually see.

Check your work in seconds

Run your site through our free safety check to confirm the fix is live, and see what else a shopper would notice.

Run a free check

Frequently asked questions

Do I need to buy an SSL certificate for WordPress?

Almost certainly not. Your host provides one free. On cPanel that is AutoSSL, where Let's Encrypt is the default provider for new installations, and it renews certificates automatically within 29 days of expiry. If your host offers no free certificate at all, that is worth questioning.

My certificate is valid but there is still no padlock. Why?

Mixed content. The page itself is secure, but something on it, usually an image, script or stylesheet, is loading over plain HTTP. Open your browser developer tools and check the console, which will list every URL causing it. Those URLs are almost always http:// links saved in your database.

Can I just run a SQL replace of http with https in the database?

No. WordPress stores many settings and page builder layouts as PHP serialized data, which records the length of every string. Replacing http:// with https:// makes strings one character longer without updating the length, so the data stops parsing and WordPress reads it as empty. Theme options and widgets disappear with no error. Use a search-replace tool that handles serialization, such as WP-CLI search-replace, and back up first.

What does FORCE_SSL_ADMIN do?

Added to wp-config.php, it forces the admin area and the login page over SSL. It is worth having, but it only covers wp-admin and wp-login.php. Your public pages still need a redirect at the server level, or your host's force HTTPS setting.

Should I turn on HSTS?

Once HTTPS works properly across your whole site, plain HSTS is a sensible addition. Preload is a different question. It demands every subdomain on HTTPS, it cannot easily be undone, and removal takes months to reach real users through browser updates. Do not preload just because a scanner suggested it.

Does any of this differ for WooCommerce?

The steps are identical, WooCommerce is WordPress. The difference is consequence. A mixed content warning at checkout loses sales outright, so test the full purchase flow after switching, including the confirmation email.