An HTTPS page can still reference resources through HTTP. Browsers handle these mixed-content requests according to their type and security rules, so the visible symptom can be a blocked script, a missing image or a broken form. Inspect the specific request before changing the certificate.
Start with the browser evidence
Open the affected page and inspect its console and network requests. Record the insecure URL, the requesting page and the resource type. Repeat on an inner page: a secure homepage does not confirm that every template and saved content field uses the correct addresses.
Classify each URL by ownership. Your own uploaded files, a theme setting, stored database content and a third-party widget can require different corrections. Make the smallest change that replaces the actual insecure dependency.
Correct the source of the URL
- Replace hard-coded HTTP references with the supported HTTPS destination.
- Check site settings and generated asset base URLs.
- Verify externally hosted scripts support HTTPS before relying on them.
- Check form destinations and API endpoints as well as visible images.
- Review redirects for unexpected returns to HTTP.
A blanket browser setting that permits insecure content can conceal the issue during your test while leaving customers affected. Keep the normal browser protections enabled and fix the request path or dependency instead.
Retest after the release
Clear or revalidate the relevant cached page when checking the new release, then confirm the deployed HTML and requests contain the intended URLs. Test the contact submission or other action that previously failed. Also check the certificate hostname and validity separately; mixed content and a certificate mismatch are different findings.
For support, provide one affected page, one resource URL and the exact browser message. Exclude credentials or private tokens from screenshots. This gives the investigation a defined dependency rather than a general “HTTPS does not work” report.