Mixed Content Warnings After Switching to HTTPS

After moving a site to HTTPS, the padlock often fails to appear. The page itself is secure; something it loads is not. Browsers block active mixed content outright and flag passive mixed content, and both look like a broken site to a visitor.

Find what is failing

Open the page, open the browser console, and read. Every mixed-content item is listed with its full URL, which tells you where it came from.

# from the command line
curl -s https://example.com | grep -oE 'http://[^"'\'' ]+' | sort -u | head -40

1. Database URLs

Most http:// references live in post content, where they were saved when the site was on HTTP. Use a tool that understands serialised data — plain SQL replacement corrupts serialised arrays by changing string contents without updating their declared lengths.

wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run
# review the output, then run without --dry-run

2. Theme and plugin files

Hard-coded URLs in template files survive any database operation:

grep -rn "http://" wp-content/themes/your-theme/ | grep -v "http://www.w3.org"
grep -rn "http://" wp-content/plugins/ --include=*.php | head -40

Ignore matches against XML namespaces such as w3.org — those are identifiers, not requests.

3. Widgets, options and customiser settings

Text widgets and theme options store their own content and are easy to miss because they are not post content. Check wp_options directly:

wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%http://example.com%';"

4. External resources that lack HTTPS

Occasionally a third-party asset genuinely has no HTTPS version. You have three options: find an alternative, host a copy yourself, or remove it. Do not use a proxy service — you are adding a dependency to fix a dependency.

5. The catch-all, used carefully

The upgrade-insecure-requests header tells browsers to retry HTTP sub-resources over HTTPS automatically:

add_header Content-Security-Policy "upgrade-insecure-requests" always;

This masks the problem rather than fixing it. Use it as a safety net after you have fixed what you can find, not instead of fixing.

Verify properly

1. Check several page types, not just the home page: a post with embedded media, an archive, the contact page, and any page with a form.
2. Check logged out, in a private window.
3. Re-crawl the site looking for http:// in the HTML.
4. Confirm the sitemap and canonical tags use https.
5. Update the site URL and home URL in Settings → General if you have not already.

Common questions

Why does the padlock appear on some pages and not others?

Because the offending resource is only on some pages — usually an image embedded in one old post.

Does mixed content hurt SEO?

Indirectly. Blocked resources can break layout and functionality, and that does affect how the page performs.

Should I use a plugin to force HTTPS?

As a temporary measure while you fix the source, yes. As a permanent solution it adds a filter to every URL on every page load.