Fix mixed content after switching to HTTPS

After you add an SSL certificate, your site loads over https://, but the browser may still say "Not secure", show a warning on the padlock, or leave out some images and styles. That is usually mixed content: a secure page that still loads some files over plain http://. This guide shows how to find those leftovers in WordPress and replace them. It is for site owners who have just switched their site to HTTPS.

What mixed content is​

A page served over HTTPS is encrypted. If that page then loads an image, script or stylesheet from an http:// address, that one file travels unencrypted. Browsers react in two ways:

• Images, audio and video loaded over http:// are usually upgraded to https:// automatically or blocked, and the padlock may show a warning.
• Scripts, stylesheets and frames loaded over http:// are blocked, because they could change the whole page. This is why a site can lose its layout or features after the switch.

The fix is to make every address on the site use https://.

Find the mixed content​

The address tells you where to look. A file under wp-content/uploads usually comes from content in the database. A file under wp-content/themes or wp-content/plugins usually comes from a theme or plugin. A file on another domain comes from an embed or a third-party service.

Update the WordPress addresses​

If those fields are greyed out, the addresses are set in wp-config.php with WP_HOME and WP_SITEURL. Change them there instead.

Replace old addresses in the database​

Posts, pages, widgets and many plugin settings store full addresses, such as image links, in the database. Changing the site address does not update them.

With WP-CLI​

WP-CLI is the official command-line tool for WordPress. If your hosting gives you SSH access and has WP-CLI installed, connect with SSH, go to the WordPress folder and run a test first:

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

--dry-run shows how many replacements would be made in each table without changing anything. If the numbers look sensible, run the same command without --dry-run. If your site also used http://www.example.com, run a second pass for that address.

--skip-columns=guid leaves the guid column alone. WordPress uses it as a permanent identifier for posts, not as a link, so it should not be changed.

WP-CLI understands serialized data, a format WordPress and plugins use to store settings. That is why you should never edit addresses in the database with a plain text search and replace: changing the length of a serialized value without updating it correctly breaks the setting.

With a plugin​

Without SSH, use a reputable, well-maintained search-and-replace plugin from the official plugin directory that handles serialized data and offers a test run. Use it the same way: test first, replace, then deactivate and delete the plugin.

Fix hard-coded addresses in themes and plugins​

If the console still shows http:// files from wp-content/themes or wp-content/plugins, the address is written into the code or settings.

• Check theme settings under Appearance, such as logo, background and header images, and choose the image again.
• Check custom CSS and custom HTML blocks or widgets for http:// addresses.
• If a theme or plugin file contains a fixed http:// address, update the theme or plugin first. If you maintain the code yourself, change the address to https:// in a child theme rather than in the original files.
• For embeds and third-party scripts, change http:// to https://. If a service does not offer HTTPS, replace or remove it.

Redirect all visitors to HTTPS​

Once the site works over HTTPS, send every http:// visitor to the secure address with a permanent redirect. Many hosts offer this as a setting. On Apache, you can also add these lines to .htaccess, above the # BEGIN WordPress block:

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

If your site is behind a CDN or proxy, use that service's HTTPS setting instead, as this rule may not detect HTTPS correctly there. See Redirects and .htaccess.

Finally, clear any caching plugin or CDN cache and check the browser console again.

Related guides​

• SSL certificates explained
• Redirects and .htaccess
• Get back into a locked WordPress admin