How to install a free SSL certificate on WordPress and move the site to HTTPS

A free certificate comes from one of three places: your host's control panel, a program called Certbot on a server you run yourself, or a CDN or proxy in front of the site. Let's Encrypt, a nonprofit certificate authority, issues certificates at no charge, and most browsers and operating systems trust them.

Installing the certificate is half the job. WordPress goes on using http until its two address settings say https, old links keep arriving over http until the server redirects them, and pages can still ask for files over http. Work in this order: get the certificate, check it, change WordPress, redirect, clear what is left.

Get the certificate

From your host's control panel

Look here first. Let's Encrypt's own guidance is that for many people the hosting provider gets and manages the certificate, either automatically or through an option you switch on.

Open the control panel and find the section about SSL or certificates.

• If a certificate is already listed for your domain, check that it covers the address with www and the one without. Then go to the next section.
• If the option is there and switched off, switch it on and wait for the certificate to be issued.
• If you cannot find it, ask the host whether a free certificate is included, how to turn it on, and whether they renew it.

On a server you run yourself, with Certbot

If you manage the server over SSH, Let's Encrypt recommends Certbot for most people. Certbot's instructions ask for three things: comfort with the command line, a site that is already online over http with port 80 open, and SSH access with sudo.

Install it by following Certbot's instructions for your web server and system. Then run the command for your server, with your own names in place of example.com.

sudo certbot --apache -d example.com -d www.example.com

Let's Encrypt checks that you control each name by asking the site for a file over http, on port 80. Certbot puts the file there for you. So every name you list must already point at this server.

Certbot then installs the certificate in the web server's configuration. Unless you tell it otherwise, it also sets the server to redirect http to https. To get the certificate without any change to the configuration, run sudo certbot certonly --apache or sudo certbot certonly --nginx and install it yourself.

Now test the renewal:

sudo certbot renew --dry-run

This runs a renewal against Let's Encrypt's staging server and saves nothing. If it ends without an error, this server can renew its certificate.

From a CDN or proxy in front of the site

A CDN or proxy that carries the whole site can supply a certificate of its own. The visitor's browser connects to the proxy, and the proxy's certificate is the one it sees.

That covers only the first half of the journey. The proxy then makes its own connection to your server, and with no certificate on the server that half travels unencrypted. Cloudflare's documentation, for one, calls that arrangement Flexible and recommends the modes that use https all the way to the server. It also warns that in Flexible mode a server that redirects http to https sends visitors round in a loop.

So put a certificate on the server as well, from your host or with Certbot, and set the proxy to connect over https. How to set up a CDN for WordPress has the settings.

Check that https works before you change WordPress

Open https://example.com/ in a browser, with your own domain. Then try it with www in front. WordPress has not been told about https yet, so do not judge how the page looks. What matters is that the browser shows no certificate warning.

If it does show one, stop and fix that first. How to fix "Your connection is not private" goes through each cause.

From a terminal:

curl -I https://example.com/

-I asks for the headers only, and curl verifies the certificate before it asks. A status line beginning HTTP/, followed by headers, means the certificate was accepted. An error about the certificate, with no headers, means it was not.

Point WordPress at https

WordPress keeps its own address in two settings and builds its links from them. Both have to say https.

With the button in Site Health

Since version 5.7, WordPress tests whether the site answers over https and offers to make the change itself.

The button is not always there.

• If the text says "Talk to your web host about supporting HTTPS for your website.", WordPress could not reach the site over https. Go back to the previous section.
• If it says the address is controlled by a PHP constant, the addresses are defined in wp-config.php and have to be changed in that file.
• The one-click change does not support a site whose two addresses differ. Change those by hand.

By hand, under Settings

If the fields cannot be edited, the addresses are defined in wp-config.php. How to change your WordPress URL covers that file, WP-CLI and the database.

After either change, on a site that already had content, WordPress 5.7 and later rewrites your own site's http addresses to https as it prints post content, excerpts, text widgets and custom CSS. Nothing stored is changed, and addresses kept anywhere else are not touched.

Redirect http to https

Old links, bookmarks and search results still point at http. A permanent redirect, status 301, sends each of them to the same page over https.

It may already be in place. Certbot sets one up when it installs a certificate, and a hosting control panel may have a switch for it. To find out, put http://example.com/, with your own domain, into the redirect checker. It lists each hop, its status code and where it sends you next. One 301 to the https address and then a 200 is the result you want.

If there is no redirect, add one.

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

• On Apache, the lines go in the .htaccess file in the site's main folder, above the line # BEGIN WordPress. WordPress writes everything between that line and # END WordPress itself, and a change made in between is overwritten. Keep a copy of the file before you edit it.
• On nginx, this must be the only block that listens on port 80 for these names. If the site's own block has a listen 80; line as well, remove that line and leave the block listening on port 443, with the certificate and the rules for WordPress. Run sudo nginx -t to test the configuration, then sudo nginx -s reload.
• Write the address the way WordPress has it, with www or without. A visitor is then redirected once and not twice.
• Behind a proxy that connects to your server over http, do not add this. Every request reaches the server over http, so the redirect never ends. Set the proxy to connect over https first, or make the redirect at the proxy.

The redirect does not get in the way of renewal. Let's Encrypt's check starts over http and follows redirects. To undo the change, remove the lines you added.

Clear what is left over

Files still asked for over http

Give your home page's address to the WordPress site health check. It reports whether the page is served over https and whether anything on it is still asked for over plain http. It reads one page at a time, so try a post and a product page as well.

Anything it finds is mixed content. How to fix mixed content warnings has the fix for each source, including the http addresses stored in the database.

A dashboard or login that loops

If the site redirects in a circle after the change, and a CDN, load balancer or other proxy sits in front of it, WordPress cannot see that the visitor is on https. WordPress's documentation gives a check for this. Here it is, with a test added so that a request without the header raises no warning. Download a copy of wp-config.php before you edit it, because a mistake in that file takes the site down.

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
	$_SERVER['HTTPS'] = 'on';
}

To undo it, remove the lines. If every page loops and the browser says the site redirected too many times, see how to fix ERR_TOO_MANY_REDIRECTS. If only the login page keeps coming back, work through the login page that keeps refreshing or redirecting.

Search engines

Google treats a change from http to https as a site move, and recommends permanent server-side redirects from the old addresses to the new.

• Verify the https address in Search Console, and keep the http one verified. Google says to verify every variant of the old and the new site.
• Submit the sitemap at its https address.
• You do not need the Change of Address tool. Google says it is not for a move from http to https.
• Keep the redirect. Google's guidance is as long as possible, and generally at least a year.

Google says to expect rankings to move about for a while as it reads the site again.

Keep the certificate renewed

Let's Encrypt's certificates are short-lived on purpose. They are valid for 90 days by default, and it recommends renewing those every 60 days. It plans to bring the longest lifetime down to 45 days by February 2028. Nobody is meant to renew by hand. Whatever got the certificate renews it.

• A host that manages the certificate renews it as part of that. If nobody has confirmed it to you, ask.
• Certbot's packages come with a scheduled task that runs certbot renew. In current versions it renews a certificate once less than a third of its lifetime is left. sudo certbot certificates lists each certificate with its names and its expiry date.
• With a CDN or proxy there are two certificates. The one on your server is still yours, or your host's, to renew.

To read the dates of the certificate a site is serving, from any computer with OpenSSL:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

The notAfter line is the day it expires.

Do not wait to be warned. Let's Encrypt ended its expiry emails on June 4, 2025. Put the date in a calendar, or use a monitoring service that watches it.

When a certificate lapses, browsers put a certificate error in front of every page. Treat it as the site being down. How to fix "Your connection is not private" covers a renewal that fails.

What not to rely on

• The CDN's certificate alone. It protects the visitor's connection to the CDN and nothing behind it.
• HSTS as a first step. The Strict-Transport-Security header tells a browser to use only https for your site for as long as its max-age says. During that time the browser does not let a visitor click past a certificate error. That is good protection once https is settled. It also means a lapsed certificate shuts those visitors out completely, and the only way to switch it off is to send max-age=0 over working https. Add it later, when renewal has been seen to work, and begin with a short max-age. Leave includeSubDomains out until every subdomain has a certificate.
• The padlock as proof that the site is clean. It describes the connection, not the site.

If the site loops or shows warnings after the move and the pages above do not settle it, our one-time fix starts with a free diagnosis that gives you a written cause and a fixed quote.