Mixed content blocked on your HTTPS site

First, find which http:// file is being blocked

If you checked your domain on kortaga.com/check, our check detects active http:// scripts, stylesheets, iframes, and objects in your home page's HTML; otherwise you can see every blocked or upgraded request in your browser's Developer Console.

1. Open your https:// page in Chrome, Firefox, Edge, or Safari, and open Developer Tools (press F12, or Ctrl+Shift+I on Windows and Linux, or Cmd+Option+I on a Mac).
2. Select the Console tab and reload the page. The console prints a mixed-content warning or error for each http:// resource, naming the blocked URL and the line in your HTML or CSS that requested it.
3. Browsers divide mixed content into two categories: upgradable content (such as <img src>, <audio src>, <video src>, and CSS background-image, which the browser tries to upgrade to https:// automatically) and blockable content (also called active mixed content: <script src>, <link rel="stylesheet" href>, <iframe src>, <object data>, web fonts, fetch(), and XMLHttpRequest), which the browser blocks outright.

Even upgradable images are blocked if the http:// URL uses a raw IP address (such as http://93.184.215.14/image.png) instead of a domain name, or if the image is loaded through srcset or <picture>.

Change the http:// links in your HTML or WordPress database

The cleanest fix is to serve every resource on your domain over https:// (or use relative paths) and use https:// URLs for any third-party scripts, fonts, or widgets.

1. In your theme templates or HTML files

1. Open the template or HTML file named in the console warning and change http:// to https:// on each stylesheet, script, or iframe:<link rel="stylesheet" href="https://example.com/main.css"> <script src="https://example.com/app.js"> </script>
2. Check that the file actually loads when you open its https:// URL directly in a browser tab. Most hosts and third-party services already serve the same file over HTTPS.

2. In a WordPress database after switching to HTTPS

1. If your site runs WordPress and old http:// links are stored across posts, widgets, or theme options, WP-CLI's wp search-replace command searches all tables registered to $wpdb and replaces the old address with the new one while handling PHP serialized data safely.
2. Run a dry run first over SSH so you can see how many rows will change without saving anything to the database:wp search-replace \ 'http://example.com' \ 'https://example.com' \ --all-tables --dry-run
3. When the report looks right, run the replacement without --dry-run:wp search-replace \ 'http://example.com' \ 'https://example.com' \ --all-tables

Tell browsers to upgrade leftover http:// requests automatically

If your site has a large number of legacy http:// URLs that take time to rewrite by hand, the HTTP Content-Security-Policy directive upgrade-insecure-requests instructs browsers to treat all of the site's insecure resource URLs as though they had been replaced with https:// before the network request is made.

1. In your web server configuration, send the response header:Content-Security-Policy: upgrade-insecure-requests;
2. Or, if you cannot edit server headers, add this <meta> element inside your page's <head>:<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

upgrade-insecure-requests rewrites both first-party and third-party resource requests (including blockable scripts and stylesheets) to https://, but if a third-party server does not actually serve that file over HTTPS, the request will fail with no fallback to HTTP. It also does not upgrade top-level <a href="http://..."> links to other websites, and it does not replace the Strict-Transport-Security (HSTS) header for protecting visitors who type your domain over HTTP.

These steps follow MDN's guides on Mixed content, How to fix a website with blocked mixed content, and the Content-Security-Policy: upgrade-insecure-requests directive, and the WordPress Developer Handbook's reference for wp search-replace, all read 27 October 2026.

If you would rather we write it for you

If you would rather we repair the site or build a clean one-page site on your own domain, it is USD 150, live within 7 days of the day you approve the draft or every dollar back, first year of hosting included. Terms at kortaga.com/sites.