What mixed content is and why only some of it breaks
MDN defines mixed content as securely loaded web pages that use resources fetched over HTTP or another insecure protocol. Current browsers split those resources into two groups. Upgradable content, such as an img element with a src attribute, audio and video sources, is quietly requested over HTTPS instead. Blockable content is not loaded at all.
That split explains the symptoms people see after a move. A page can look almost right because plain images were upgraded, while the embedded lesson player, a font, a quiz script or the responsive image set is missing. MDN also notes that upgrades are skipped when the URL uses an IP address rather than a host name, and that Safari blocks all mixed content by default, so a page can work in one browser and break in another.
| Resource on the page | Browser behavior (MDN) | What it can look like on a course site |
|---|---|---|
| img with src | Upgraded to HTTPS | Usually fine, but still worth fixing at source |
| img with srcset, or picture | Blocked | Responsive images or course thumbnails missing on some screens |
| audio or video with src, or source | Upgraded to HTTPS | Self-hosted media usually plays |
| iframe src | Blocked | Embedded lesson video, form or calendar area left empty |
| script src | Blocked | Quizzes, sliders or checkout scripts stop working |
| link href, including stylesheets | Blocked | Page loses its styling |
| Web fonts | Blocked | Fallback fonts and shifted layout |
| fetch and XMLHttpRequest | Blocked | Background requests to an http:// address fail |
| Any URL using an IP address instead of a host name | Not upgraded; blocked | Assets that pointed at the old server's IP disappear |
Find every insecure URL before changing anything
MDN and web.dev both point to the browser's developer console, which shows a warning each time mixed content is upgraded or blocked. web.dev notes that the console only reports the page you are viewing, so you need to visit each page type. On a course site that means the pages anonymous visitors see and the pages only members see: the dashboard, a lesson with a video, a quiz, the certificate page, the checkout and the account page.
To catch pages you would not think to open, web.dev describes sending a Content-Security-Policy-Report-Only response header, which reports mixed content without blocking anything. It notes that this report-only variant cannot be set with a meta tag; it has to be a response header from the server or host.
Fix the two site URLs first
WordPress.org's Migrating WordPress page says the WordPress Address and Site Address are stored as siteurl and home in the options table and that both should include the https:// part. The wp-config.php reference adds that WP_HOME and WP_SITEURL constants override those values without changing the database, so check wp-config.php if a settings change does not seem to stick.
Since WordPress 5.7, the Site Health screen reports whether the site uses HTTPS and can switch the site to HTTPS in one click when the server already supports it. The WordPress 5.7 developer note explains the limits. The switch updates home and siteurl, then replaces old http:// home URLs on the fly in post content, excerpts, widget text and custom CSS only, without changing the database. It does not run when WP_HOME or WP_SITEURL are defined or when the two addresses use different domains. Anything stored elsewhere, such as page-builder data, LMS settings or post meta, keeps its old URLs.
Run a scoped, rehearsed search-replace
WordPress.org warns that a plain search and replace across the database can break serialized data, because some themes and widgets store values with the length of the URL recorded, and says never to change the GUID column. WP-CLI's search-replace command is documented as handling PHP serialized data. Its --dry-run flag runs the whole operation and shows a report without saving, --skip-columns=guid leaves the GUID alone, --report-changed-only trims the report, and --precise forces PHP instead of SQL for all columns.
A typical first pass looks like: wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run. Back up the database, read the dry-run report table by table, and only then run it without --dry-run. Our URL search-replace rehearsal guide walks through scoping the replacement and checking the result before you touch production.
Places a database replace does not reach
Some insecure URLs are not in the database at all. Theme and child-theme templates, CSS files on disk and custom JavaScript can contain hard-coded http:// links, so search the theme folder too. Embed codes pasted into lessons may point at an http:// player address; replace them with the provider's current HTTPS embed code.
If a third-party resource is not available over HTTPS, web.dev lists three choices: use a different host for it, host the content yourself if the law allows, or remove it. The upgrade-insecure-requests Content-Security-Policy directive tells browsers to request every URL over HTTPS, including blockable content, but web.dev notes that a resource that is not available over HTTPS then fails to load, so treat it as a safety net rather than the fix.
Mixed content checklist for a migrated course site
- Set home and siteurl to https, and check wp-config.php for WP_HOME or WP_SITEURL overrides.
- Open the console on a logged-out page, a lesson with video, a quiz, the certificate, checkout and the account page.
- Back up, then run wp search-replace with
--dry-runand--skip-columns=guid before the real run. - Search theme files, CSS and custom scripts for hard-coded http:// URLs.
- Replace old embed codes with the provider's HTTPS embed code.
- Look for any asset URL that uses the old server's IP address; browsers will not upgrade it.
- Use a Content-Security-Policy-Report-Only header to find pages you missed.
- Recheck in Safari, which blocks all mixed content by default.
Questions before you decide
Why do images load but my lesson videos do not?
MDN lists img src, audio and video as upgradable, so browsers fetch them over HTTPS automatically. Iframes, which most hosted video players use, are blockable, so an http:// embed is not loaded at all.
Does the WordPress 5.7 HTTPS switch fix stored URLs?
No. The 5.7 developer note says it updates home and siteurl and replaces insecure home URLs on the fly in content, excerpts, widget text and custom CSS only. The database is not changed, and page-builder or LMS data is not covered.
Is it safe to run a find-and-replace in phpMyAdmin?
WordPress.org warns that a plain database replace can break serialized data and that the GUID column must never be changed. WP-CLI search-replace handles serialized data and supports --dry-run and --skip-columns=guid.
Will the upgrade-insecure-requests header solve it?
It tells browsers to request all URLs over HTTPS. web.dev notes that any resource not available over HTTPS then fails to load, so fix the stored URLs as well.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- MDN: Mixed content Accessed 30 Oct 2026
- web.dev: Fixing mixed content Accessed 30 Oct 2026
- WordPress.org: Migrating WordPress Accessed 30 Oct 2026
- WordPress.org: wp-config.php reference Accessed 30 Oct 2026
- WordPress.org: Site Health screen Accessed 30 Oct 2026
- Make WordPress Core: Improved HTTPS detection and migration in WordPress 5.7 Accessed 30 Oct 2026
- WP-CLI: wp search-replace Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.