The fix, in one snippet
grep -rn 'href="http://' templates/ content/Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Every link on an HTTPS page is parsed and resolved to an absolute URL, and those whose scheme is http are reported with their source page. Only anchors are counted here: an http:// image or script on an HTTPS page is mixed content and belongs to the security scan, which reports it separately and more seriously.
Links are parsed from the DOM rather than matched with a pattern, so a URL mentioned in a code sample or a comment is not counted. What is reported is a link a visitor can actually click.
Why it matters
Following an http:// link means one unencrypted request before the redirect to HTTPS arrives. That request carries the URL in clear text and can be intercepted or rewritten by anything on the path, which is the exact gap HSTS exists to close.
It also costs a round trip every single time, on every link, for every visitor. On mobile that is often several hundred milliseconds of nothing.
For crawlers, an internal http:// link introduces a second URL for the same destination. Where redirects or canonicals are inconsistent, both versions can end up in the index, splitting the page's signals.
How to fix it
Fix the links at the source; the redirect is a safety net, not the answer:
# find them
grep -rn 'href="http://' templates/ content/
# for content in a database, one pass over the affected columns
UPDATE posts SET body = REPLACE(body, 'href="http://example.com', 'href="https://example.com');Use root-relative links (/guides/x) for anything on your own site, which removes the question entirely. For external links, prefer the HTTPS version where the destination supports it. Then add HSTS so that even a stray http:// link is upgraded by the browser before a request is made.
Where this fits
http:// references on HTTPS pages is check 5 of 7 that the seo & site health audit runs under technical seo and speed, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Slow server response (medium), where how long the server took to return each page. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
http:// references on HTTPS pages closes one route in. Immediately below it: Language attribute missing, where the lang attribute on <html> tells screen readers which pronunciation to use and search engines which language to file the page under; No cache policy on HTML, where hTML with no cache policy is re-downloaded in full on every visit, including every back-button navigation.
Found in the same scan
The seo & site health audit reports this alongside checks from other categories that are at least as serious, including Broken internal links, where an internal link that returns an error is a dead end for the reader and a wasted request for the crawler, and Crawl errors (4xx / 5xx), where uRLs reached during the crawl that returned a client or server error. A single run of seo & site health audit answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: http:// references on HTTPS pages (medium severity)
Scanner check id: seo-mixed-protocol-linksThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.