Padlock missing after switching to HTTPS? Find the http resources still loading

What mixed content is

A valid certificate makes the page itself arrive securely. If that page then pulls a picture, a stylesheet or a script from an address that begins http://, the page is only partly secure, and the browser either upgrades the request, blocks it or shows a warning in place of the padlock. This is different from an expired or wrong certificate, which stops the page loading at all. It is common straight after a site moves to https, because older pages remember the old http addresses.

What browsers do with each kind

MDN describes two categories. Upgradable content, such as images and audio or video loaded by a src attribute, is rewritten from http to https automatically, and fails if no https version exists. Everything else, including scripts, stylesheets, iframes and fetch or XHR calls, is blocked. MDN lists CSS background images among the upgradable items in one place and CSS url() values, which cover fonts and cursors, among the blockable ones in another, so test those rather than assume. A blocked script or stylesheet is why a page can lose its layout or a menu stop working after a move, even though the padlock looks fine on the home page.

• Upgraded images may hide a problem until the https version of the file goes missing.
• Blocked scripts and styles are the ones that visibly break pages.
• A request to a bare IP address over http is blocked, not upgraded.

Finding what is still http

Open the page in a browser, open the developer console and reload. Firefox and Chrome both list upgraded and blocked requests with the address of each. Check a handful of page types, not only the home page: a blog post, a contact page, a product or booking page, and any page with an embedded video or map. MDN also lists crawlers that scan a site for mixed content; any of them gives a list you can work through.

On a WordPress site, our reading is that the leftovers usually live in the database: post content, widgets, theme and plugin settings that store a full address. WordPress's own documentation says references to an old address remain in the database after a move and can break links or theme display, which is the same mechanism.

• Record the address of each blocked or upgraded request and the page it appears on.
• Group them: content you edit, theme or plugin settings, and third-party services.

What actually fixes it

Serve your own content over https, use https or relative addresses for it, and use the https address of each third-party resource where one exists. For stored WordPress addresses, a database search-and-replace is the usual route, but a careless one can corrupt serialised data, so it needs a dry run and a method that understands that format. Cloudflare's WordPress plugin with Automatic HTTPS rewrites is one tool Cloudflare itself suggests.

The Content-Security-Policy directive upgrade-insecure-requests tells the browser to upgrade every request to https, including ones it would otherwise block. It is a useful safety net while you fix the sources, but it does not create the https version of a file that does not exist, and it hides the leftovers instead of removing them.

• Fix the source of each address, not just the symptom.
• Re-test the same pages in the console afterwards.

What is and is not a paid outcome here

There is no separate fixed-price job for a sitewide mixed-content clean-up. The certificate job lists what it finds loading over http on the home page, and the WordPress move job includes the careful address replacement when a move changes the address. A wider clean-up can be described in an enquiry, and we say whether it fits before any price or payment. These are published test prices that have not been tested with buyers, payable after you sign off.

It does not fit when the certificate itself is expired or wrong, which is the certificate job, or when the page loads in a redirect loop, which is the redirect job.