HTTPS Links HTTP

What this check means

Your page is served over HTTPS, but somewhere in its HTML it links to an http:// address. That link might be a navigation link, a citation, an image, a script, or a stylesheet. The check does not care whether the destination happens to redirect to HTTPS. It flags the fact that the link as written starts on the insecure protocol, because that has real consequences depending on what kind of link it is.

There are two flavors, and it is worth keeping them straight. A hyperlink to an http URL (an anchor a user clicks) is a navigation and referrer problem. A subresource loaded over http (an image, script, iframe, or stylesheet embedded in the page) is a mixed content problem, and browsers treat it far more harshly.

Why it matters

The impact ranges from a minor tax to a broken page, so do not wave it off.

• Mixed content. When an HTTPS page loads an active subresource (script, iframe, stylesheet) over http, browsers block it outright. Passive content like images may load with a warning. Either way the page is degraded and the padlock can break.
• Extra redirect hops. Most http URLs now 301 to HTTPS. Every link that starts at http forces an extra round trip: request http, get redirected, request https. On a link heavy page that adds up in latency and crawl overhead.
• Referrer leakage. Navigating from HTTPS to a plain http destination can strip the referrer, so the destination loses attribution. It also just looks careless to anyone inspecting the traffic.
• Trust and quality signals. Google has pushed HTTPS as a baseline for years. A secure site riddled with http links reads as an incomplete migration, and users who see a broken padlock lose confidence fast.
• Wasted crawl budget. Search engines follow the http link, hit the redirect, then fetch the https target. That is two fetches for one destination, multiplied across the site.

What the browser does with each type

Where these links come from

After a migration to HTTPS, the certificate and redirects usually get handled, but the links inside the content often do not. Typical sources:

• Hardcoded http:// URLs in old posts, page builders, and templates.
• Image and media references saved with the full http path in the database.
• Third party embeds, widgets, and scripts still pointing at http endpoints.
• Theme and plugin defaults, canonical tags, or sitemaps generated before the switch.
• Internal links copied from an older version of the site.

How to detect it

• Screaming Frog: crawl the site, then check the "Security" tab for the "HTTP URLs" and "Mixed Content" filters. It lists every insecure link and the pages they sit on.
• Browser DevTools: open the Console and Security panels on a page. Mixed content is reported explicitly, with the exact offending resource.
• Sitebulb: its security hints surface insecure links and mixed content, grouped so you can gauge scale.
• Search Console: watch the Pages report for HTTPS related issues, and use URL Inspection to see how a page renders.
• Server logs: a spike of internal requests hitting http then redirecting to https confirms the links are live and being followed.

How to fix it, step by step

1. Inventory every http link with a full crawl. Separate hyperlinks from subresources, because subresources are the urgent ones.
2. Fix subresources first. Any script, stylesheet, image, or iframe loaded over http must be switched to https or replaced. Active mixed content is being blocked right now.
3. Rewrite internal links to https. For a database driven site, a careful search and replace of http://yourdomain.com to https://yourdomain.com handles the bulk. Back up first.
4. Update external links where the target supports HTTPS. If a linked site offers https, link to it directly rather than relying on its redirect.
5. Keep the site wide http to https redirect in place. It is your safety net for anything you missed and for old inbound links, but it is not an excuse to leave http links in your own code.
6. Consider HSTS. An HTTP Strict Transport Security header tells browsers to always use https for your domain, closing the door on downgrade attempts.
7. Re crawl and confirm zero. Verify the Security tab is clean and DevTools shows no mixed content warnings.

Do vs Don't

Link type, browser behavior, priority

What "good" looks like

Every internal link, image, script, and stylesheet on the site uses https. The Security tab in a fresh crawl is empty, DevTools shows no mixed content warnings, and the padlock is intact on every page. The site wide http to https redirect still stands as a safety net for old inbound links, but your own pages never trigger it. External links point at https wherever the destination supports it. If you have gone the extra step, an HSTS header enforces https before a request even leaves the browser.

FAQ