HTTPS and mixed content: fix insecure page references

HTTPS pages and HTTP resources

HTTPS protects the connection to a page. An HTTP image loaded from that page is mixed content; browsers may upgrade or block it. An HTTP internal link, canonical or hreflang target is a different consistency problem and should be reviewed separately. A protocol-relative URL inherits the document scheme and is harder to reason about.

Why secure references matter

Mixed content can reduce browser security or leave images missing. HTTP links can take readers through avoidable redirects or an insecure destination. Canonical and hreflang references should align with the intended secure public version. Do not treat every security diagnostic as a direct ranking factor.

What SEOTera detects and does not prove

Page Audit checks the fetched page's HTTPS delivery, HTTPS-to-HTTP downgrade, internal HTTP links, mixed image references, HTTP canonical and hreflang targets, and protocol-relative links. Site Audit finds observed insecure images and internal HTTP links across analyzed pages. These findings do not establish whether every browser loaded an asset or whether the HTTP URL ultimately redirects securely.

Inspect references and responses

Open the HTTPS page and inspect browser Console and Network panels. Look at img src, anchor href, canonical and hreflang values in the HTML. Request each affected HTTP and HTTPS address to check whether the secure endpoint exists and returns the intended asset or page. Review both source HTML and the rendered view when scripts rewrite URLs.

Common migration leftovers

A CMS media library may store absolute HTTP image URLs; a CDN may still publish an old host. Templates can emit HTTP canonicals or hreflang references after an HTTPS migration. Old internal links and protocol-relative //example.com paths often survive configuration changes.

Keep page references consistent

For internal pages, use a correct relative path or an explicit HTTPS URL. For external media, confirm that the provider supports HTTPS before changing the address. Canonical and hreflang targets should resolve to the intended secure pages. Fix an HTTPS-to-HTTP redirect at its routing rule, not by hiding its source link.

1. Group affected URL sources

Separate HTTP image references from internal links and metadata targets. Identify whether they come from a template, CMS field, CDN configuration or a single page. Prioritize visible missing assets and user-facing insecure destinations.

2. Update the authoritative value

Configure HTTPS on the target service, then change the source data or template to use it. Replace protocol-relative URLs with explicit HTTPS where possible. Align canonical and hreflang with the intended final URL and repair any downgrade rule.

3. Recheck pages and sitewide findings

Reload representative pages with the browser cache cleared and confirm secure network responses. Run Page Audit for affected pages and Site Audit for repeated references. Compare findings with crawl coverage and inspect any remaining HTTP URLs individually.

Replace an insecure image URL

Confirm the image is actually served over HTTPS, then update the CMS record or template that emits the reference. A visual check alone may miss a browser-upgraded request, so inspect the network response too.

<img src="http://cdn.example.com/photo.jpg">  →  <img src="https://cdn.example.com/photo.jpg">