WordPress And HTTPS Mixed Content: The Specific Sources

Many WordPress sites that migrated to HTTPS years ago still have mixed content warnings on specific pages. The browser shows the security warning on those pages, search engines treat them as less trustworthy, and the issues persist because the sources of the mixed content aren't obvious from looking at the site.

The sources of mixed content on WordPress are predictable. A systematic check of each source resolves the issue in a few hours of focused work.

Source 1: hardcoded URLs in post content

The most common source. Post content from before the HTTPS migration contains image tags with http:// URLs. The browser loads the page over HTTPS, sees the http image references, and either blocks them or shows mixed content warnings.

The fix: WP-CLI search-and-replace across the database. The command:

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

The --dry-run flag shows what would change. Remove it to execute. The --skip-columns=guid flag prevents changing the guid column, which should keep its original values for compatibility.

After running, verify by spot-checking 5-10 affected posts. The image URLs should now use https://.

Source 2: theme template hardcoded URLs

Theme template files sometimes reference images, stylesheets, or scripts with http:// URLs. The site might work fine until you look at a specific theme template that has hardcoded references.

The check: grep through theme files for http:// references.

grep -rn 'http://' wp-content/themes/your-theme/

The fix: update each occurrence to use https:// or, better, to use WordPress functions like get_template_directory_uri() that respect the site's protocol automatically.

Source 3: third-party embeds and widgets

YouTube, Vimeo, Twitter, Google Maps, and other third-party embeds typically have HTTPS versions. Older embedded content sometimes uses HTTP iframe URLs.

The fix: for each affected post, re-paste the embed using the current HTTPS embed URL. For systematic fixes across many posts, search-and-replace can update the iframe src URLs.

Some third parties don't support HTTPS embed. For those, either: switch to a different third party that does, host the content yourself, or accept the mixed content warning.

Source 4: external CSS or JavaScript loaded over HTTP

Some plugins or themes load resources from external CDNs. If the CDN URL is HTTP, the loaded resource produces mixed content.

The fix: identify which plugin or theme is loading the HTTP resource (browser DevTools shows the loading file's source), update the URL to HTTPS if available, or contact the plugin developer to fix the URL.

For most modern CDNs (jQuery's CDN, Bootstrap's CDN, Google Fonts), HTTPS is available. The fix is usually a one-character change in the source code.

Source 5: external image references in advertisement code

Ad networks that haven't migrated their image servers to HTTPS produce mixed content when their ads load on HTTPS pages. The site can't unilaterally fix this; the ad network has to migrate.

For ad networks that still have HTTP-only images in 2026 (which should be rare but happens), the choice is: contact the ad network and request HTTPS, switch to a different ad network, or accept the mixed content warning until the ad network migrates.

Source 6: user-generated content with HTTP links

Comment fields and user profile bio fields can contain HTTP image URLs that produce mixed content. The site administrator usually can't fix these en masse because the content was entered by users.

The fix: either remove the user-entered content (rejecting HTTP image URLs going forward), or proxy the HTTP images through your site so they're served over HTTPS, or accept the limited scope (only specific user-generated pages have the warning, not the whole site).

Source 7: redirect chains that include HTTP intermediate

An HTTP URL redirects to HTTPS, but somewhere in the redirect chain there's an HTTP intermediate. The intermediate redirect might be technically over HTTPS but include HTTP references.

The diagnosis: use curl -v or a redirect tracer to see each step in the chain. Identify the HTTP step. Fix it (usually a server configuration issue).

Source 8: WordPress media library URLs that didn't update

WordPress stores image URLs in the database with the protocol included. The HTTPS migration usually updates these URLs but sometimes misses media items in specific tables or via specific plugins.

The check: query the wp_postmeta table for any meta values containing http://yourdomain.com. The WordPress functions that emit image URLs use these meta values.

The fix: a more thorough search-replace that includes more columns and handles serialized data correctly. WP-CLI's search-replace handles serialization; raw SQL search-replace breaks serialized data.

The verification

After running through all sources, verify the site is clean. Methods:

1. Browser DevTools console. Visit several representative pages. Any mixed content shows as a warning in the console. Pages should have no warnings.

2. SSL test tools like ssllabs.com/ssltest. The Mixed Content section flags any issues.

3. crawl the site with a crawler that checks for mixed content (Screaming Frog has this feature in the paid version). The crawler identifies which pages have warnings and what specifically is loading over HTTP.

The verification is the discipline that turns "we migrated to HTTPS" into "we actually migrated to HTTPS." Many sites stop at the first step (the URL bar shows the green lock) and don't verify the deeper sources.

The Strict-Transport-Security header

Once mixed content is fully resolved, enable HSTS (HTTP Strict Transport Security) with a meaningful max-age. The header tells browsers to always use HTTPS for the domain, preventing protocol downgrade attacks.

The setup pattern: start with max-age=300 (5 minutes), verify everything works, increase to max-age=31536000 (1 year) for production. The longer max-age provides better security but makes recovery harder if the certificate breaks.

HSTS preload (submitting your domain to be hardcoded in browsers as HTTPS-only) is the strongest form. Submit only after you're confident HTTPS is fully working; the submission is hard to reverse.

The honest framing

Mixed content is a residual problem from HTTPS migrations that many sites haven't fully cleaned up. The cleanup is mechanical: identify sources, fix each one, verify completion.

The benefit: the site genuinely communicates over HTTPS without warnings. Browser trust improves. Search engine trust improves. The mixed content warning that occasionally appears in user reports goes away.

The cost: 2-8 hours of focused work depending on site size and source diversity. The work is one-time; once the site is clean, new content rarely introduces mixed content because the workflow has shifted to HTTPS by default.