Start with the page and its HTTPS connection
HTTPS protects the connection between a visitor’s browser and a website. A page can appear to use HTTPS while still requesting an image, script, font, or other resource over HTTP. These requests are called mixed content. Browsers may block some of them or handle them differently, which can leave a page looking broken or behaving unexpectedly.
Begin with a few representative pages: the home page, an article, a page with a form, and any template that uses different media or interactive features. Open each page using its https:// address. Check whether it loads without a certificate warning and whether the address remains on HTTPS after redirects. If a browser reports a certificate problem, investigate that first; replacing asset URLs will not fix an invalid certificate. Certificate coverage should include the hostnames visitors actually use, such as a www version if the site supports one.
Use browser tools to find mixed requests
Open the browser’s developer tools and reload a page. The Console may show mixed-content warnings, including the URL of a requested resource. In the Network panel, look for requests beginning with http://, failed requests, or resources the browser reports as blocked or upgraded. Keep the panel open while interacting with the page: a menu, video, embedded widget, or form may load additional resources only after someone uses it.
Record the page URL, the affected resource URL, its type, and what triggers the request. This makes the fix easier to locate and retest. A blocked script can prevent a feature from working, while a missing image may be easier to notice visually. Do not rely on the page’s appearance alone: a resource can fail without an obvious layout change, and a browser may silently upgrade some requests.
Check templates and site-wide references
One clean page does not establish that the whole site is clean. Review pages that use different templates, plugins, embeds, or content editors. If you have access to a site crawler, configure it to identify HTTP resources referenced by HTTPS pages. You can also search templates, stylesheets, and stored content for http:// references. Focus first on resources requested by the browser; an HTTP URL shown as ordinary text is not necessarily a mixed-content request.
Check more than visible assets. An HTTPS page may contain an HTTP form action, a CSS file may reference an HTTP font or background image, and a third-party embed may request additional resources. Also review internal links, canonical URLs, and sitemap entries for consistency with the preferred HTTPS URLs. These are separate from mixed content, but inconsistencies can send visitors and crawlers through avoidable redirects or point them toward the wrong page version.
Fix the source, not just the symptom
For a resource you control, change the source reference to a working HTTPS URL. First confirm that the resource is available over HTTPS; changing http:// to https:// blindly can create a broken request. For resources hosted by someone else, check whether that provider offers a secure version or a supported replacement. If not, consider removing the resource or hosting an appropriate copy yourself when you have the rights and a workable maintenance plan.
Update shared templates and content settings where possible instead of patching individual pages one by one. Check that HTTP page addresses redirect to their intended HTTPS equivalents, and avoid redirect chains when you can. If you are considering a stricter browser policy such as HSTS, test HTTPS coverage across every affected hostname first. Such policies are not a substitute for repairing mixed-content requests and can make an incomplete migration more disruptive.
Retest and keep a simple review routine
After making changes, clear or bypass relevant caches and reload the affected pages with developer tools open. Confirm that the previously flagged resources now load successfully and that forms, navigation, and interactive features still work. Test on a narrow viewport as well as a desktop-sized one if the site serves different media or components by screen size. Then sample other pages that share the changed template.
Keep a short list of the URLs tested, problems found, fixes made, and any resources you could not change. Repeat the check after adding a new theme component, embed, plugin, or content source. The aim is not to collect a perfect-looking score: it is to make pages reliably usable over HTTPS and to give visitors a consistent, secure path through the site.
