The document loads over HTTPS, but one HTTP script, font, iframe, or fetch request may be blocked. Images may be automatically upgraded, hiding the stored bad URL until a different browser or export exposes it.
Use the sequence below as a diagnostic method, not as a promise that one setting fits every host; verify its example paths, privileges, and backup assumptions while working to find insecure URLs in HTML, CSS, srcset, embeds, database content, and generated assets without unsafe global replacement.
Likely failure paths
- Old absolute HTTP URLs remain in post content, options, widgets, or serialized data.
- Theme CSS, generated page-builder files, or an external embed requests HTTP.
- WordPress home/siteurl or proxy handling still emits the old scheme.
The branches are ordered to protect the strongest evidence around this possibility: old absolute HTTP URLs remain in post content, options, widgets, or serialized data. The observed scope and logs—not a familiar-looking error screen—decide which one applies.
Routing should be read as a chain of explicit HTTP responses; wordPress, the web server, proxy, CDN, and browser can each redirect or cache independently; the address finally visible in the browser hides that chain; in this guide, the practical goal is to find insecure URLs in HTML, CSS, srcset, embeds, database content, and generated assets without unsafe global replacement.
A controlled investigation
- Open the browser console and Network panel; record each insecure request and its initiator.
- Inspect page source, CSS, srcset/picture markup, and database matches.
- Run
wp search-replace 'http://old.example' 'https://example.com' --dry-runand review affected tables. - Verify the destination actually serves the resource correctly over HTTPS.
The sequence moves from observation toward intervention. Preserve the result of the final check—verify the destination actually serves the resource correctly over HTTPS—because it provides a useful comparison after the repair.
From first observation to a reversible decision
The opening hypothesis is old absolute HTTP URLs remain in post content, options, widgets, or serialized data. Test it with the least invasive observation available: open the browser console and Network panel; record each insecure request and its initiator. Do not change configuration until the observation has been saved with a timestamp.
When that evidence is consistent with the hypothesis, stage this repair: correct WordPress URL settings and source templates first. Otherwise, preserve the current state and advance to the next branch. This keeps rollback simple and prevents a second change from masking the first.
Inventory old HTTP origins before replacement
Use a serialized-data-aware dry run for database values and a separate source scan for theme/plugin files. The dry run must be reviewed before any write.
wp search-replace 'http://old.example.com' 'https://example.com' \
--all-tables-with-prefix --precise --dry-run
rg -n 'http://old\.example\.com' wp-content/themes wp-content/pluginsInterpretation and safety: Back up the database before removing –dry-run. Do not blindly replace unrelated third-party HTTP URLs; some resources need a new HTTPS source instead.
Make the smallest durable change
- Correct WordPress URL settings and source templates first.
- Use serialized-data-aware WP-CLI replacement for confirmed internal URLs, after a database backup.
- Regenerate derived CSS/assets and replace or remove third-party resources without HTTPS.
Before applying “Correct WordPress URL settings and source templates first,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can browse representative templates with mixed-content blocking enabled; a changed symptom at that point is new evidence, not permission to make several more changes at once.
Close the incident with evidence
- Browse representative templates with mixed-content blocking enabled.
- Confirm console and network logs contain no HTTP subresource request.
- Crawl media and downloadable links, not only page HTML.
One successful refresh is not closure. Keep the incident open until you can also confirm console and network logs contain no HTTP subresource request, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.
Prepare a useful escalation if the boundary is outside your control
Capture curl -I or curl -IL output, the canonical host/scheme policy, proxy/CDN rule names, WordPress home and site URL values, and one deep affected path; remove cookies and authorization headers before sharing evidence; include the result of this first observation: open the browser console and Network panel; record each insecure request and its initiator.
State what was tested, including the result of “Open the browser console and Network panel; record each insecure request and its initiator,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.
Do not trade visibility for a green screen
- Do not run SQL string replacement directly across serialized options.
- CSP upgrade-insecure-requests can reduce breakage but should not hide uncorrected source data.
Operator record
Primary references
- MDN mixed content — official reference consulted for this guide.
- WP-CLI search-replace — official reference consulted for this guide.
Editorial note: The scenario above illustrates how to approach “Correct WordPress URL settings and source templates first”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.