WordPress “Not Secure” Warning: How to Move to HTTPS and Fix Mixed Content

If Chrome shows “Not secure” next to your web address, your site is still being served over plain HTTP. Chrome has labelled every HTTP page that way since July 2018, and Chrome 154, released in September 2026, goes further: by default it asks people before opening an HTTP site. When Google announced the change, it said the warning would cover public sites a person hasn’t visited recently. For a blog that wants readers’ trust, HTTPS is no longer optional.

The switch itself is usually quick, because most hosts provide a free certificate and WordPress has a built-in button for the move. What trips people up comes afterwards: old http:// links to images, scripts and fonts, known as mixed content. This guide covers the whole job in order, from certificate to Search Console, with fixes for the problems people run into most.

What “Not secure” and mixed content mean

With HTTPS, the connection between a visitor’s browser and your server is encrypted, so nobody in between can read or change what is sent. Plain HTTP has no such protection, which is why browsers warn about it.

Mixed content is what happens after a partial switch: the page itself loads over HTTPS, but some of the files it uses are still requested over HTTP. Browsers handle those files in two ways, which MDN describes as upgradable and blockable content:

In practice, mixed content today usually shows up as missing images, a broken slider or form, or a page that looks partly unstyled, rather than as a warning in the address bar. And don’t rely on the padlock to judge success: Chrome announced in 2023 that it would replace the lock with a neutral icon. What matters is that the address starts with https:// and that the browser reports no insecure content.

Before you start

• Make a full backup of your files and database. The steps below change your site’s addresses, so you want an easy way back. Our guide to backing up a WordPress site shows three methods.
• Get a certificate. Let’s Encrypt issues certificates free of charge, and for many people the hosting provider requests and renews them automatically, sometimes after you switch on an option in the control panel. Look for “SSL” or “Let’s Encrypt” in your hosting dashboard, or ask support.
• Let renewal happen automatically. Certificates are getting shorter-lived: Let’s Encrypt’s default lifetime is due to drop from 90 days to 64 days in February 2027 and 45 days in 2028, and it stopped sending expiry reminder emails in 2025. Manual renewal is no longer realistic.
• Test the secure address. Type your domain with https:// in front. If the page loads without a certificate error, you are ready to switch.

Step 1: Switch WordPress to HTTPS

Option A: the Site Health button

Since WordPress 5.7, switching is a one-click move. Go to Tools → Site Health. If it reports “Your website does not use HTTPS”, open that item and click Update your site to use HTTPS. WordPress changes both site addresses, and undoes the change only if WordPress still doesn’t recognize the site as using HTTPS. It won’t switch back if something else breaks later, so keep your backup ready.

The button only appears when WordPress can load your site over HTTPS with a valid certificate (it tests this when Site Health runs), when your addresses aren’t fixed in wp-config.php, and when you are an administrator who can update WordPress. If you see “Talk to your web host about supporting HTTPS for your website” instead, WordPress couldn’t load your site over HTTPS. Usually the certificate isn’t in place yet, although a firewall or security plugin that blocks WordPress’s own test request can cause the same message.

After the switch, if both addresses use the same domain, WordPress also rewrites http:// links to your own site in post content, excerpts, classic Text widgets and Additional CSS as pages are shown. That is a useful safety net, but it doesn’t change your database and doesn’t reach everything; menus, theme settings, custom fields, block widgets and page-builder layouts can still contain old links. Step 4 deals with those.

Option B: change the addresses yourself

Go to Settings → General and change both WordPress Address (URL) and Site Address (URL) from http:// to https://, then save. You will be logged out and asked to log in again. If the two fields are greyed out, the addresses are set in wp-config.php with WP_HOME and WP_SITEURL; change them there instead.

Step 2: Redirect HTTP to HTTPS

Visitors, old bookmarks and links from other sites still point at http:// addresses, so send them to the secure version with a permanent (301) redirect. The simplest way is your host’s own setting. In cPanel it is the Force HTTPS Redirect switch under Domains; other control panels have a similar option.

If your server runs Apache and your host has no such setting, add these lines at the top of the .htaccess file in your site’s main folder, above the # BEGIN WordPress line, because WordPress overwrites anything between its own markers:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Step 3: Find mixed content

Open a page in Chrome, press F12 (or right-click and choose Inspect) and look at the Console tab. Insecure files appear as “Mixed Content” messages that say whether the request was automatically upgraded or blocked, and name the exact file.

For a full list, open the Network tab, reload the page and type mixed-content:all in the filter box; Chrome’s DevTools reference also lists scheme:http for every request made over plain HTTP. Check several page types, not just the home page: a post with images, a page with a form or slider, an archive page and your contact page.

Step 4: Fix mixed content at the source

Most leftover links live in the database: inside posts, in image settings, in widgets and in plugin options. A search-and-replace tool can change http://yourdomain.com to https://yourdomain.com everywhere at once, but it needs care, because WordPress stores some settings in a format that breaks if text is replaced carelessly.

1. Use a tool that understands WordPress data

   Better Search Replace handles WordPress’s stored settings safely and offers a dry run. With command-line access, WP-CLI’s search-replace does the same. Never run a raw SQL replace across every table.

2. Do a dry run first, and skip the GUID column

   A dry run shows how many changes would be made without saving anything. WordPress’s migration guide is emphatic about one column: “Never, ever, change the contents of the GUID column, under any circumstances.”

3. Check what a search and replace can miss

   Confirm that custom links in Appearance → Menus, the logo and background images in the Customizer and any code in Additional CSS now use https://. Page builders can store addresses in a form a plain search doesn’t match, so run your builder’s own “replace URL” tool if it has one. Fix embedded content from other sites, such as old video or map codes, by hand, and edit addresses typed directly into theme files in the files themselves, ideally in a child theme.

4. Clear every cache and test again

   Clear your caching plugin, your host’s cache and any CDN, then repeat Step 3 on the same pages until the Console shows no mixed content messages.

With WP-CLI, start with a dry run. Replace example.com with your own domain, and include www. if your site uses it:

wp search-replace \
  'http://example.com' \
  'https://example.com' \
  --skip-columns=guid --dry-run

If the counts in the report look sensible, run the same command without --dry-run:

wp search-replace \
  'http://example.com' \
  'https://example.com' \
  --skip-columns=guid

Using Cloudflare? Avoid the redirect loop

Cloudflare’s Flexible mode encrypts the connection between visitors and Cloudflare, but connects to your server over plain HTTP. If your server also redirects HTTP to HTTPS, the two keep sending each other round in circles and the site shows “too many redirects”. Cloudflare’s own documentation says not to use Flexible when your server redirects to HTTPS and recommends Full or Full (strict), which requires a certificate on your server as well.

Should you turn on HSTS?

HSTS is a header that tells browsers to use only HTTPS for your site from then on, even if someone types http://. It strengthens security, but it is hard to undo: visitors can no longer click past certificate errors, and the preload list run by browsers covers all your subdomains, with removal that takes months to reach users.

For most small sites, turn it on only after HTTPS has run without problems for a while, start with a short duration and increase it gradually, and leave preloading until you are certain every subdomain supports HTTPS.

After the move: Search Console

Google treats a move from HTTP to HTTPS as a site move with URL changes, although it needs fewer steps than a move to a new domain. You don’t need the Change of Address tool. Google’s checklist is:

• use permanent, server-side redirects and keep them in place for at least a year;
• update internal links to the new https:// addresses;
• make sure each page’s canonical tag points to its own https:// address;
• submit your sitemap again in Search Console;
• expect some temporary movement in rankings while Google processes the change.

A Domain property in Search Console covers http and https, with and without www, in one place; our guide to adding your site to Search Console explains how to set one up. And keep expectations realistic: HTTPS protects your readers and avoids warnings, but Google says that page experience aspects beyond Core Web Vitals don’t directly help your site rank higher.

Troubleshooting common problems

Conclusion

Moving WordPress to HTTPS takes four steps: get a certificate, switch the addresses, redirect HTTP to HTTPS, and clean up mixed content. The first three usually take minutes. The fourth takes a little patience with the Console and a careful search and replace, but once it is done your readers see a secure, complete site on every page.