How to switch WordPress to HTTPS

Moving a WordPress site to HTTPS is four steps: get a certificate, tell WordPress its address has changed from http to https, force every visitor onto the secure version, and fix whatever still refers to the old http address in your content. Skip any one of them and you end up with a site that is partly secure and shows a browser warning for the parts that are not.

Step 1: issue the SSL certificate

Every hosting plan here includes free SSL. In most cases it is issued automatically once a domain is added and pointing at the account; if it is not yet active, see installing an SSL certificate for how to issue one from your control panel.

Confirm the certificate is actually active before moving on: visit the site with https:// typed manually in the address bar and check for the padlock icon with no warning.

Step 2: update the WordPress site URLs

WordPress stores its own address in the database, including the protocol. Changing the certificate alone does nothing until WordPress is told the site now lives at the https version.

1. Go to Settings, then General

   You will see WordPress Address (URL) and Site Address (URL).

2. Change http to https in both fields

   They should read identically apart from any subdirectory difference your setup already had.

3. Save

   You will be logged out and asked to log back in, since the session was tied to the old address.

Step 3: force every visitor onto HTTPS

Updating the site URL settings does not stop someone reaching the site over plain http if they type it that way, or if an old link points there. A redirect rule closes that gap by sending any http request straight to the https version automatically.

Add this to your .htaccess file, above the WordPress block that begins with # BEGIN WordPress:

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

See forcing HTTPS on your website for alternative methods if your control panel offers a built-in redirect option instead, which is often simpler than editing .htaccess directly.

Step 4: fix mixed content

This is the step almost everyone underestimates. Even with the site URL correctly set to https and every visitor forced onto it, individual pieces of content — an image inserted years ago with a full http:// URL, a script tag hardcoded in a theme, a link pasted into a post — can still reference the old plain address directly. Browsers respond to this by either blocking the insecure resource or showing a "not fully secure" warning, known as mixed content.

The fix is a careful, serialization-aware search-and-replace across the database, swapping every http://yourdomain.com reference for https://yourdomain.com. Full detail, including which tools handle WordPress's serialized data safely, is in fixing mixed content warnings in WordPress.

Checking the whole thing worked

• Visit the site with plain http:// and confirm you are redirected to https:// automatically.
• Check the address bar shows a padlock with no warning on the homepage and at least one inner page.
• Open the browser's developer console and look for any mixed content warnings listed there.
• Check that internal links throughout the site point at https addresses, not the old http ones.

If search rankings matter to you

A permanent redirect from http to https preserves the search ranking signal built up under the old address rather than losing it, provided the redirect is a genuine 301 rather than a temporary one — which the rule in Step 3 correctly is. There is no separate step needed here beyond making sure that redirect is actually in place and working before you consider the migration finished.

What breaks if you skip a step

Each of the four steps closes a different gap, and problems tend to trace directly back to whichever one was skipped:

• Certificate issued, site URLs not updated. The site still generates internal links using http, so visitors keep landing back on the insecure version even though a secure one is available.
• Site URLs updated, no forced redirect. Anyone who types the address without https, or follows an old bookmark or external link, reaches the insecure version and sees no automatic upgrade.
• Redirect in place, mixed content not fixed. The page itself loads securely, but individual images or scripts still trigger a browser warning, which looks identical to a broken certificate from a visitor's point of view even though the certificate is entirely fine.

Doing all four in order is what actually produces a site with no warnings anywhere, rather than one that looks fixed on the homepage and breaks on the first older post someone clicks into.

A note on caching after the switch

If the site uses a caching plugin, clear the cache after completing these steps. A page cached under the old http version can otherwise continue to be served to some visitors even after everything above is correctly configured, which looks exactly like the fix not having worked when the real cause is simply a stale cached copy.