Padlock Broken After Switching to HTTPS: How to Find Mixed Content

The quickest check

First things first: open the page that's lost its padlock, press F12 (or Ctrl+Shift+I) and go to the Console tab. When you visit an HTTPS page in Google Chrome, the browser flags mixed content with errors and warnings in the JavaScript console. Look for lines starting with "Mixed Content". That line already contains the exact address of the resource breaking security: that's where you start, not with the theory of HTTP and HTTPS.

One detail that wastes everyone's time: mixed content warnings are only shown for the page you're currently viewing, and the console clears every time you navigate to a new page. So a clean homepage doesn't mean a clean site: you need to check internal pages too, especially older articles.

What the error means, in one line

The browser loaded the page over HTTPS, but inside that page there's an image, script or stylesheet still being requested over HTTP. The browser removes the padlock because it can't guarantee all traffic is encrypted. In some cases Chrome automatically upgrades passive mixed content: if a resource is written as HTTP but is also available over HTTPS, the browser loads the secure version; if no secure version exists, the resource simply fails to load. For scripts, iframes and stylesheets the issue is more serious: because of the higher risk, most browsers already block this kind of active content by default, although behaviour varies between browsers and versions.

The causes, in order of frequency

1. The site address is still on http (the most common case on WordPress)

How to spot it. Go to Settings → General in the WordPress dashboard and look at the two fields WordPress Address (URL) and Site Address (URL).

How to fix it. If they still show http://, change them to https:// and save. If saving locks you out of the dashboard in a redirect loop, the alternative is to force the values via a file, opening wp-config.php and adding, before the line "That's all, stop editing!":

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

On cPanel you can edit the same file via File Manager; on Plesk via File Manager, inside the domain's folder.

How to verify it. Reload Settings → General: both fields should now show https://.

2. Http links written inside the content (the case a redirect won't fix)

A 301 redirect from http to https changes the protocol for anyone typing the address into the address bar, but it doesn't touch URLs already saved inside posts, pages, widgets or builders: those remain written out as http:// and the browser still treats them as insecure requests, blocked or downgraded regardless of the redirect.

How to spot it. If you have SSH access and WP-CLI installed, run a dry run first without writing anything:

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

The command and the --dry-run and --skip-columns parameters are documented on the official wp search-replace page of the WP-CLI Handbook. The report shows how many occurrences would be replaced in each table: if the number isn't zero, this is the cause.

How to fix it. Re-run the same command without --dry-run:

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

If you don't have SSH access, the same job can be done from phpMyAdmin with an UPDATE query on the wp_posts and wp_postmeta tables, searching for and replacing the string http://yourdomain.com with https://yourdomain.com; this must be done carefully because an overly broad replacement can break serialised data in widgets or plugins, hence the usefulness of the --skip-columns=guid flag and, in trickier cases, of --precise.

How to verify it. Re-run the --dry-run: it should report zero possible replacements.

3. References hardcoded in theme or plugin files

How to spot it. On an Ubuntu 24.04 system with SSH access, search for occurrences inside the active theme's folder:

grep -rn "http://yourdomain.com" /var/www/yourdomain.com/wp-content/themes/theme-name/

On cPanel you can do the same search from File Manager using the search-in-files feature, inside public_html/wp-content/themes/.

How to fix it. Replace the hardcoded http:// with https://, or, where possible, with a relative URL generated by WordPress (for example via get_template_directory_uri() for theme files) instead of writing out the full domain.

How to verify it. Reload the page and check the console again: the warning relating to that file should disappear.

4. External resources that aren't yours (CDN, fonts, advertising iframes)

How to spot it. In the browser console, check the domain of the blocked resource: if it's not yours, the cause is a third-party service still hooked up over http.

How to fix it. Copy the resource's address, open it in a new tab changing http:// to https://: if it loads, simply update the reference in the plugin settings or in the embed code; if it doesn't load over https, the external provider doesn't support it and the resource needs to be replaced or removed.

When it's the provider's fault. If the block affects a resource that passes through your CDN or your hosting's proxy, and persists after fixing the database and theme, the problem may be on the provider's side. When contacting support, attach: the exact blocked address copied from the console, a screenshot of the Console or Issues tab in DevTools, and the domain name involved.

Useful paths for checking requests on the server side

If, after the fixes, there's still doubt about which request is actually arriving over http, it can help to check the webserver logs:

Environment	Log path
Ubuntu/Debian with Nginx	/var/log/nginx/access.log and /var/log/nginx/error.log
cPanel (user account)	~/access-logs/, with older archives in ~/logs/
Plesk (per domain)	/var/www/vhosts/system/example.com/logs/ — error_log, access_log and access_ssl_log

The Ubuntu/Debian paths are the distribution's defaults: on Ubuntu and Debian systems, the default paths are /var/log/nginx/access.log and /var/log/nginx/error.log. If the path has been customised, it can be found with nginx -T in the access_log or error_log directive of the active configuration file.

How to verify it's fixed, in general

1. Reopen the console on every page you noted down (it clears on every navigation, so it needs to be checked page by page).
2. In Chrome, also check the Issues tab, which lists every insecure resource along with its block status.
3. Clear the cache of any caching plugins and the CDN before checking again: an already-cached page can keep showing the error even after the fix.
4. Only once the console is clean on all the checked pages will the padlock become stable again.

No product mentioned in this article is a Prime Software product.