How to Set Up an SSL Certificate on WordPress and Switch to HTTPS

Putting an SSL certificate on a WordPress site takes three steps: install the certificate on your server, point WordPress at the HTTPS versions of your URLs, and redirect the old HTTP traffic. Most hosts now handle the first step for you, and since version 5.7 WordPress handles a large part of the second one by itself. This guide covers all three, for free and paid certificates, and fixes the errors that usually show up afterwards.

Quick answer: install an SSL certificate through your hosting control panel, then open Settings > General in WordPress and change both WordPress Address (URL) and Site Address (URL) to their https versions. Finish by adding a 301 redirect so HTTP requests land on HTTPS.

SSL (short for Secure Sockets Layer, though every certificate issued today actually uses TLS) is what turns http:// into https:// and removes the “Not Secure” label from the address bar. If you want the background first, read what an SSL certificate is. Otherwise, start with the table below.

Which method fits your setup

There are three ways to add SSL to WordPress, and the right one depends almost entirely on your hosting. Find your setup, then jump to that method.

Your setup	Use this method	Roughly how long
Managed WordPress hosting	Nothing to install. The certificate is usually already active, so skip to switching WordPress to HTTPS	5 minutes
cPanel or a similar shared host	Method 1, the host’s free AutoSSL	10 minutes
A host with no SSL tool, or you want it done for you	Method 2, the plugin wizard	10 to 15 minutes
VPS, dedicated server, or a paid certificate	Method 3, manual installation	30 minutes plus validation time
Cloudflare sitting in front of your site	Method 1 or 3, then set Cloudflare SSL to Full (strict). See troubleshooting	15 minutes

Whichever route you take, back up the site first, and if you have a staging environment, run the change there before you touch production.

Do you need an SSL certificate for WordPress?

Yes, and for most people the reason is the one they can already see: Chrome, Firefox, Safari and Edge all mark plain HTTP pages as Not Secure in the address bar. That label appears on every page of a site without a certificate, including the login form.

Three practical reasons to fix it:

• Credentials and form data travel in the clear. Without a certificate, anyone on the same network can read what visitors submit, including your own WordPress password.
• Payments require it. If you run WooCommerce, or accept any card data, HTTPS is not optional. Payment gateways will refuse to operate over HTTP.
• Google uses HTTPS as a ranking signal. It is a real signal but a light one, so treat the SEO argument as a bonus rather than the reason. The browser warning is the reason.

Which SSL certificate should a WordPress site use?

Start with the free option, because for a large share of WordPress sites it is genuinely the right answer. Most hosts issue free Let’s Encrypt certificates automatically, and a free certificate encrypts traffic exactly as well as a paid one. The encryption is identical. What differs between one WordPress SSL certificate and another is what the certificate authority verified before issuing it, and what you get when something goes wrong.

Validation levels

Type	What the CA checks	Issued in	Fits
Domain Validation (DV)	That you control the domain	Minutes	Blogs, brochure sites, most WordPress installs
Organization Validation (OV)	The domain plus your registered organization	1 to 3 business days	Business sites, membership areas, client portals
Extended Validation (EV)	A full legal and operational check of the company	1 to 5 business days	Stores handling payments, finance, anything where identity matters

If your site runs on subdomains, a shop on store.example.com and a blog on blog.example.com for instance, a wildcard certificate covers all of them with one certificate instead of one per subdomain. Not sure which type applies? The SSL Wizard narrows it down in a few questions.

When a free certificate stops being enough

Free certificates are DV only, last 90 days, and come with no support and no warranty. That is fine for a personal blog. It becomes a problem in four situations:

• You take payments. Paid certificates carry a warranty that covers losses if the certificate itself fails. Free ones carry none.
• Your visitors need to know who you are. A DV certificate proves only that someone controls the domain. OV and EV put your verified organization details inside the certificate.
• You run subdomains. Free wildcard issuance is possible but fiddly, and it usually needs DNS automation your host may not offer.
• Renewal is not automated. A 90-day certificate that nobody renews takes the site down as surely as no certificate at all. If your host does not auto-renew, a longer paid certificate is less work, not more.

Method 1: get a free SSL certificate from your host

This is the fastest route and the one to try first. Nearly every host now offers free Let’s Encrypt certificates, often already switched on.

• Open your hosting control panel and look for SSL/TLS, Let’s Encrypt, or AutoSSL. On cPanel it sits under Security.
• Select your domain and issue the certificate. Include both the apex domain and the www version, otherwise one of them will throw a name mismatch warning.
• Confirm auto-renewal is enabled. This is the step people skip.

No hosting panel at all, because you run your own VPS or dedicated server? Use Certbot, the Let’s Encrypt client, which issues the certificate from the command line and sets up its own renewal schedule.

Let’s Encrypt certificates are valid for 90 days, and renewal is meant to happen automatically, typically around 30 days before expiry. When that automation breaks, and it does break, usually after a domain moves or a DNS record changes, the site stays fine for weeks and then goes “Not Secure” without warning. Put a reminder in your calendar for the first expected renewal date and check the certificate with the SSL Checker once it has passed. If the expiry date moved forward, renewal is working.

Method 2: install SSL on WordPress with a plugin

The plugin most people reach for is Really Simple Security. It was called Really Simple SSL until September 2024, when version 9 renamed it as its free feature set grew beyond SSL setup. It has more than three million active installations.

What changed alongside the name matters here: the plugin no longer only forces the redirect, it can also obtain the certificate for you through a Let’s Encrypt wizard. So it covers the whole job when your host does not.

• Install and activate Really Simple Security from Plugins > Add New Plugin.
• Follow the onboarding that opens, or go to the new Security item the plugin adds to the admin sidebar. Older tutorials say Settings > SSL, which is where the plugin lived before the rename. If a certificate is already installed on the server, the plugin detects it.
• If there is no certificate, choose Install SSL certificate and follow the wizard to get a free Let’s Encrypt one.
• Select Activate SSL. The plugin updates your site URLs, sets up the redirect, and reloads the dashboard over HTTPS.

One caveat worth knowing before you commit. A plugin that forces HTTPS does it in PHP, on every request. A redirect written into the server configuration happens before WordPress loads, which is faster and keeps working if the plugin is ever deactivated. If you are comfortable editing server files, do the switch manually and keep the plugin out of the critical path.

Method 3: install an SSL certificate manually

This is the route for a paid certificate, or for any server without a one-click tool. On shared hosting, check first that your plan allows installing third-party certificates; a few budget hosts still lock this down or charge for it.

• Generate a CSR. The certificate signing request carries your domain and organization details to the certificate authority. Use our CSR generator, or follow the CSR guides for your specific server.
• Submit the CSR to the certificate authority and complete validation. DV finishes in minutes, OV and EV take days.
• Install the files. You will receive the certificate itself plus one or more intermediate certificates. In cPanel, paste them under SSL/TLS > Manage SSL sites, following the cPanel installation guide. Other platforms are covered in the SSL installation guides.
• Verify with the SSL Checker before touching WordPress.

Pay attention to the intermediate certificates. If you install the main certificate but omit the chain, most desktop browsers will still show a padlock, because they cache intermediates they have seen elsewhere. Mobile browsers, payment gateways and anything calling your site through an API will fail. A site that “works in Chrome but breaks the checkout” is very often an incomplete chain, and the SSL Checker will report it.

Running WordPress Multisite adds a few steps, covered in the Multisite SSL guide.

Switch your WordPress site from HTTP to HTTPS

The certificate is on the server. WordPress still does not know about it. This is where a lot of guides send you to run a database search and replace before anything else, and for most sites that has not been necessary for years.

What WordPress does on its own

Since WordPress 5.7, released in March 2021, core detects whether your environment supports HTTPS and reports it under Tools > Site Health > Status, in the HTTPS status section. When HTTPS is available, that section offers a button that switches the site over in one click.

More importantly, once Site Address (URL) and WordPress Address (URL) are both on https, WordPress rewrites insecure URLs in your content as it renders the page. Images, links and embeds that were saved with http addresses on your own domain are served over https without you editing the database at all. That is the step older tutorials tell you to do by hand.

Worth understanding precisely, because it decides what you still have to do: the rewriting happens on output, through filters attached to the content as it is displayed. Your database still holds the old http URLs. For visitors the result is identical, which is why the migration works without a search and replace, but the stored data is unchanged. That matters the day you export the site, move it to another host, or query the database directly, and it is the reason a search and replace is still worth running eventually rather than never.

Change the two URL settings

If Site Health does not offer the one-click button, or you would rather do it explicitly, open Settings > General. There are two fields and both have to change:

• WordPress Address (URL), where the WordPress files live.
• Site Address (URL), the address visitors type.

Change http:// to https:// in both, then save. Changing only one is the single most common way to lock yourself out of the dashboard. If that happens, you can set both from wp-config.php over FTP:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Add those lines above the line that reads “That’s all, stop editing”, and replace example.com with your domain. Note that while these constants are defined, the fields in Settings > General become read-only.

When you still need a search and replace

Core’s rewriting covers rendered content. It does not reach everywhere, so a search and replace is still the fix for:

• URLs hardcoded in theme files or in functions.php.
• Plugin settings stored as serialized data, which is why you should never run a plain SQL find and replace.
• Options rows, custom fields and widget content written by page builders.

Use Better Search Replace, which handles serialized data correctly and has a dry-run mode, or WP-CLI:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

Read the dry run output, then repeat the command without –dry-run to apply it. Back up the database first.

Force HTTPS in WordPress with a 301 redirect

Your site now answers on https, but it still answers on http as well, and every old link and bookmark points there. A permanent HTTPS redirect sends both visitors and search engines to the secure version and passes on the ranking signals of the old URLs. Set it at server level rather than in PHP wherever you can.

Apache

Add this at the top of the .htaccess file in your WordPress root, above the WordPress block:

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

The R=301 flag is what makes it permanent. A rule written as [R,L] issues a temporary 302 instead, which is a mistake worth checking for if you copied a redirect from an older guide.

Nginx

Nginx has no .htaccess and does not understand rewrite rules written for Apache. Edit the server block in your site configuration instead:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Test the configuration with nginx -t, then reload with systemctl reload nginx.

Force HTTPS on the dashboard only

To secure logins and the admin area specifically, add this to wp-config.php:

define( 'FORCE_SSL_ADMIN', true );

This covers wp-admin and the login page. It does not redirect the front end, so it complements a server-level redirect rather than replacing it.

HSTS, once everything works

HSTS tells browsers to refuse plain HTTP for your domain entirely, which closes the gap between the first request and the redirect. On Apache:

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

Add this only after HTTPS has been stable for a while, and leave the preload directive off at first. Preloading is difficult to reverse quickly, and if anything on a subdomain is not yet on HTTPS, it becomes unreachable.

Fix what the switch leaves behind

Mixed content

Mixed content is a page served over HTTPS that still pulls in images, scripts, stylesheets or fonts over HTTP. Browsers now split it in two: upgradable resources, mostly images and media, which they quietly upgrade to HTTPS before requesting, and blockable resources such as scripts and stylesheets, which they refuse to load at all. That is why a page with mixed content may look merely unpadlocked, or may arrive completely unstyled.

On WordPress the usual sources are a hardcoded image URL in a theme file, an external script loaded over HTTP, and a CDN still configured for HTTP. Open the browser console, which names the offending resource, and fix it at the source. Our guide on how to fix mixed content covers the diagnosis in detail.

Caches and CDN

Purge your page cache and your CDN after the switch. A cached copy of an HTTP page will keep serving the old markup and make a finished migration look broken.

Emails and transactional templates

This one gets missed almost universally. WooCommerce order emails, password reset messages, invoice templates and newsletter footers often carry hardcoded HTTP links, and they live outside the tables a normal search and replace touches. Send yourself a test order and a test password reset, then check where the links actually point.

Troubleshooting WordPress SSL problems

Symptom	Usual cause	Fix
Endless redirect loop, ERR_TOO_MANY_REDIRECTS	Cloudflare SSL set to Flexible. Cloudflare talks to your server over HTTP, your server redirects to HTTPS, Cloudflare sends it back	Set Cloudflare SSL/TLS encryption mode to Full (strict) and keep a valid certificate on the origin
Locked out of wp-admin after the switch	Only one of the two URL fields was changed	Set WP_HOME and WP_SITEURL in wp-config.php over FTP
Padlock missing on some pages only	Mixed content on those pages	Find the HTTP resource in the browser console, fix it at the source
Site was fine, went “Not Secure” weeks later	A Let’s Encrypt certificate expired because renewal broke	Reissue, then confirm auto-renewal in your control panel
Works in the browser, fails for an app or a payment gateway	Intermediate certificates missing from the chain	Install the full CA bundle, then recheck with the SSL Checker
Name mismatch warning on www or the apex	The certificate covers only one of the two	Reissue the certificate so it covers both names; a redirect alone cannot fix this, the warning appears before any redirect runs

If the certificate is installed and the site still reports as insecure, the SSL error guides cover specific browser error codes.

After the migration: SEO checklist and what to expect

• Add the HTTPS property in Google Search Console. An HTTP property does not report on HTTPS URLs. Add the new one and keep the old, or use a Domain property, which covers both. If you use Bing Webmaster Tools, update it there too.
• Resubmit your XML sitemap with the https URLs.
• Check canonical tags point at https. Most SEO plugins update automatically once the site URLs change, but confirm it in the page source.
• Update Google Analytics and Ads property settings, and any third party service that stores your site URL.
• Update internal links where they are absolute. Relative links need nothing.

What normal looks like afterwards, because it worries people who have never done it: Search Console will show your impressions split across the HTTP and HTTPS properties for a while as Google recrawls, and rankings often move around for a few weeks before settling. Google treats an HTTP to HTTPS move as a site move with URL changes, so some fluctuation is expected rather than a sign that something broke. As long as the 301 redirects are in place and every page resolves, there is nothing to do but wait.

One thing worth saying plainly: going back from HTTPS to HTTP is almost never the right fix for a problem. It means a second site move, another round of ranking disruption, and the browser warnings return. If HTTPS is causing trouble, the cause is nearly always one of the entries in the troubleshooting table, and fixing that is far cheaper than reversing the migration.

Frequently Asked Questions

Moving a different platform to HTTPS, or want the general procedure? See our guide on how to switch a site from HTTP to HTTPS.