How to Force HTTPS in WordPress, Step by Step

A padlock in the address bar is the first thing visitors notice about your site, and the first thing search engines and browsers hold against you when it is missing. If your site still loads over http://, forms and sign-ins travel in plain text for anyone on the same network to read.

Here is how to force HTTPS in WordPress properly, in an order that avoids the classic traps: redirect loops, broken images and a Cloudflare setting that quietly ruins your afternoon.

What "Force HTTPS" Really Means

HTTPS is the secure version of the web address protocol. Your browser and your server agree on an encryption key, so nobody in between can read or tamper with what is sent. The certificate (often called an SSL or TLS certificate) is what proves your site is really yours.

"Forcing" HTTPS means three separate things, and people often only do one:

1. A valid certificate is installed on the server.
2. WordPress knows its address is https, so links, assets and the admin all use it.
3. Every http request is redirected to https, so no one ends up on the insecure version.

Miss any of the three and you get something half-working. To force HTTPS in WordPress for real, you need all three. A certificate with no redirect still lets visitors load http:// pages. A redirect with no certificate shows a scary browser warning. WordPress set to https without a redirect leaves old links dangling.

Do them in order and you will be done in under an hour. The order is the whole trick.

Step 1: Get a Certificate

Most hosts give you one for free, and many switch it on automatically. The certificate authority behind a lot of them is Let's Encrypt, a free, non-profit service. Their getting started page notes that many hosting providers obtain and renew Let's Encrypt certificates for their customers, and that you should check your provider's documentation because some need you to switch the setting on.

So the first move is simple: look in your hosting control panel for a section called SSL, TLS, Security or Let's Encrypt. If there is a button that says "Install" or "Enable", press it.

If your host does not offer it, you can run a tool yourself (Let's Encrypt recommends Certbot), but at that point it is worth asking whether a host that cannot do free certificates in 2026 is the host you want.

Once installed, test it. Visit https://yourdomain.com in a private browser window. You should see the padlock and your site. If the browser warns about the certificate, stop and fix that first. Nothing else in this guide works until the certificate is valid for your domain, and for www too if you use it.

One Certificate, Every Version of Your Address

Check the certificate covers both example.com and www.example.com. A certificate that only covers one will give warnings on the other. Most hosts handle both automatically, but it takes ten seconds to confirm.

Step 2: Change the WordPress Address and Site Address

In your admin, go to Settings, General. There are two fields:

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

Change both from http:// to https://, and click Save Changes. WordPress will probably sign you out. Sign back in at the https address.

Do this after the certificate works. If you switch to https without a working certificate, you can lock yourself out of the admin, which is a bad evening.

If the fields are greyed out, the URLs are set in wp-config.php with WP_HOME and WP_SITEURL. Edit those lines instead:

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

This single change fixes a lot already: new links WordPress builds will use https. It does not redirect visitors yet, and it does not touch old content. That is next.

Step 3: Force HTTPS in WordPress With a Redirect

Now make sure no one stays on the insecure version. The cleanest place to do this is the server, because it happens before WordPress even loads.

Apache and .htaccess

If your host uses Apache (or LiteSpeed, which reads the same rules), add this near the top of .htaccess, above the WordPress block:

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

The 301 tells browsers and search engines the move is permanent. Take a copy of the file before you edit it, so you can put it back if something breaks.

Nginx

On nginx, the redirect lives in the server config, as a separate block listening on port 80:

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

Reload nginx afterwards. If you are on managed hosting, there is often a toggle called "Force HTTPS" in the control panel that does exactly this, and using it is easier than hand-editing config.

Test It Properly

Open a private window and type http://yourdomain.com. It should jump to https. Test with www and without. Test an inner page like http://yourdomain.com/about/. Then check the sign-in page.

If you get a redirect loop (the browser says "too many redirects"), do not keep adding rules. Go to the Cloudflare section below, which is the most common cause.

Step 4: Fix Mixed Content

After the redirect works, you may notice the padlock showing a warning, or images missing. That is mixed content: an https page that still loads something (an image, script, stylesheet or font) over http. Browsers block the risky kinds and flag the rest.

The cause is old URLs. Years of posts, widgets and theme settings stored http://yourdomain.com/... links in the database, and WordPress does not rewrite them for you.

Search and Replace in the Database

The reliable fix is a database search-replace that changes http://yourdomain.com to https://yourdomain.com. Always back up first (our backup guide covers how).

With WP-CLI, which is a command line tool for WordPress, it is one command, with a dry run first:

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

WP-CLI handles serialized data safely, which matters because plain SQL find-and-replace can corrupt settings that store text with its length. If you do not have WP-CLI, use a search-replace plugin that handles serialized data, and remove it afterwards.

Find What Is Left

Open your browser's developer tools, check the console, and look for "mixed content" messages. They name the exact file. Common leftovers are:

• Hard-coded http:// links in a theme or page builder template.
• Fonts or scripts loaded from third-party addresses written with http://.
• Image URLs inside custom CSS.

Fix each at its source. Clear any caches afterwards (page cache, CDN and your browser), or you may keep seeing old pages and think the fix did not work.

Step 5: Force HTTPS for Sign-Ins With FORCE_SSL_ADMIN

WordPress has a constant that insists on secure sign-ins and admin sessions. The WordPress developer documentation on administering WordPress over HTTPS explains that adding this to wp-config.php forces all logins and all admin sessions to happen over SSL:

define( 'FORCE_SSL_ADMIN', true );

Place it above the line that says "That's all, stop editing!". The documentation is clear that SSL must already be configured on the server before you do this, which is why it comes after the earlier steps.

It is worth adding even with a site-wide redirect. It is a belt-and-braces setting for the part of your site that matters most. It does not replace the redirect, because it only covers sign-ins and the admin area, not the front of the site.

If your site sits behind a proxy or load balancer that handles the certificate, the same documentation warns this can cause an endless loop unless WordPress can tell the original request was secure. Your host will usually have this sorted, but it is worth knowing if you see loops.

The Cloudflare Gotcha: Flexible SSL and Redirect Loops

If your site uses Cloudflare, one setting decides whether everything above works: the SSL/TLS encryption mode. Cloudflare offers a few:

Here is why Flexible bites. A visitor loads https://example.com. Cloudflare connects to your server over plain http. Your server (or WordPress, or your redirect rule) sees an insecure request and says "go to https". Cloudflare does it again. And again. The browser gives up with "too many redirects".

The fix is to install a valid certificate on the server (Step 1) and set Cloudflare to Full (strict). Leaving it on Flexible also means the last leg is unencrypted, so it only looks secure.

Stack Guard has a page on this: the Cloudflare integration notes Full (strict) with a certificate on the server as the right choice. If you use Pro, it can read your zone with a read-only API token and show the SSL mode, so you can see whether Cloudflare and your server disagree without logging in to two dashboards.

Step 6: Add HSTS Last, and Carefully

Everything so far makes your site use https. HSTS makes browsers refuse anything else.

HSTS stands for HTTP Strict Transport Security. It is a header your site sends that tells a browser: "for the next N seconds, only ever connect to this site over https." Even if someone types http:// or clicks an old link, the browser upgrades it by itself before sending anything. That closes the small window where the very first insecure request could be intercepted on public Wi-Fi.

The MDN reference on Strict-Transport-Security covers each part of the header. The ones that matter:

• max-age: how many seconds the browser remembers the rule.
• includeSubDomains: applies the rule to every subdomain too.
• preload: asks browsers to build your site into their built-in list, so even the first visit is secure. MDN notes it needs a max age of at least one year and includeSubDomains.

Why It Comes Last

HSTS is hard to undo. Browsers keep the rule until max age runs out, even if you later remove the header. If part of your site is not ready for https, such as an old subdomain with no certificate, visitors will hit a hard error with no way to click through.

So the safe path is:

1. Confirm the whole site and every subdomain you care about works on https.
2. Send HSTS with a short max age, such as a day or a week.
3. Watch for problems for a while.
4. Raise it to a year.
5. Only then consider includeSubDomains.

A Special Warning About Preload

Preload deserves its own caution. Submitting your domain to the browser preload list is a commitment, and getting removed again takes a long time, because browser releases have to roll out. Only preload when every subdomain, including the ones you forgot about (staging, mail, old landing pages), has a working certificate and you intend to keep it that way.

If in doubt, skip preload. HSTS with a one year max age gives most of the benefit with much less risk.

HSTS in Stack Guard

On Pro, Security Headers includes HSTS with a choice of max age, include subdomains and preload. Max age choices run from 1 day to 2 years. It only sends the header on requests that are already https, as the standard requires. The plugin's guidance matches the steps above: start short, and only switch on subdomains and preload when every subdomain has a working certificate. Preload submission itself is done by you at hstspreload.org. The HSTS docs walk through the settings.

Once HTTPS is solid, the next header worth learning is a WordPress Content Security Policy. The other Security Headers (clickjacking, referrer and permissions policies) are in the Free plan, so you can start there while you get HTTPS sorted.

Check Your Work

When you think you are done, check from the outside rather than trusting your own browser, which may be remembering things:

1. Open a private window and visit the http:// version of your home page, an inner page, and your sign-in page. Each should land on https.
2. Look for the padlock on a few pages. No warnings.
3. Check the browser console for mixed content messages.
4. Test with and without www.
5. Run the free security check. It tests HTTPS and HSTS from the outside, which is exactly the view a visitor or attacker has.

Then put a reminder in your calendar. Most hosts renew certificates automatically, but "automatic" means "until the day it silently stops". Looking at your padlock once a quarter takes a few seconds.

Once you force HTTPS in WordPress, add it to your regular WordPress security audit so a lapsed certificate never surprises you. For the wider picture of what else is worth tightening, the WordPress hardening checklist and our guide to WordPress security headers pick up where this one leaves off.