HTTPS URL Links to HTTP URL: How to Fix It

What "HTTPS URL Links to HTTP URL" means

This audit issue flags a page served over a secure HTTPS connection that contains a hyperlink pointing to an HTTP version of a URL, usually another page on the same site. In other words, a secure page is sending visitors and crawlers to an insecure address. Most sites moved to HTTPS years ago, but old internal links frequently keep their original http:// prefix buried in the page HTML, the database, or a theme template. The page itself loads fine, so the problem is easy to miss, yet every one of those links quietly works against the clean, secure structure you set up when you migrated.

This is closely related to, but not the same as, mixed content. Mixed content is when an HTTPS page loads a resource (image, script, or stylesheet) over HTTP. As Screaming Frog notes, that mixed content weakens HTTPS and makes the page easier to compromise. The issue here is about navigational links rather than embedded resources, but it shares the same root cause: a leftover http:// reference on a page that should be fully secure.

Why HTTPS-to-HTTP internal links are a problem

An extra redirect on every click

When a properly configured site receives a request for an HTTP URL, it answers with a 301 redirect to the HTTPS version. That redirect is the safety net, not the destination. Every time an internal link points at HTTP, the browser and Googlebot must make a wasted round trip: request the HTTP URL, receive the redirect, then request the HTTPS URL. That hop slows the page slightly for users and wastes crawl budget, since the crawler spends requests resolving redirects instead of discovering real content.

Duplicate http and https URLs

Search engines treat http://example.com/page and https://example.com/page as two distinct URLs. When your own internal links keep referencing the HTTP variant, you are actively signaling that the insecure version exists and matters. That can muddy canonicalization, split link signals between two versions of the same page, and create avoidable duplicate-content confusion. Google's guidance is consistent: pick HTTPS as your canonical and link to it everywhere.

A weaker security posture

Until the redirect fires, the first request travels over plain HTTP. On a hostile network that initial unencrypted hop is exactly the window an attacker watches for. Linking directly to HTTPS removes the insecure hop entirely so the connection is encrypted from the very first request.

How to diagnose it

A crawl-based audit is the fastest way to find these links at scale. Tools like Screaming Frog, Sitebulb, and SEO ProCheck crawl your site and flag any HTTPS page whose outlinks contain an HTTP URL. In Screaming Frog you can open the Security tab and review the outlinks of each affected page, then use Bulk Export to pull the full list of offending links alongside the pages they sit on. That export tells you exactly which template, post, or menu to edit.

For a quick manual spot check, open a page, view source, and search the HTML for href="http:// (note the missing "s"). Pay special attention to navigation menus, footers, and body content, since a single shared template can spread one bad link across thousands of pages.

How to fix it

1. Update internal links to HTTPS

The direct fix is to rewrite every internal http:// link to https://. Update the source: theme files, navigation menus, widgets, and any hardcoded links in post content. On a WordPress site, a search-and-replace across the database (with a backup first) catches links stored in posts and options. For internal links you can also use root-relative paths so the protocol is inherited automatically.

<!-- Bad: forces a redirect and references the insecure URL -->
<a href="http://example.com/services/">Our services</a>

<!-- Good: links straight to HTTPS -->
<a href="https://example.com/services/">Our services</a>

<!-- Also good: root-relative, inherits the secure protocol -->
<a href="/services/">Our services</a>

2. Enforce an HTTPS redirect and HSTS

Fixing the links removes the everyday redirects, but you still want a server-level rule that forces any stray HTTP request to HTTPS, plus an HSTS header so browsers refuse to even attempt HTTP on return visits. This is your backstop, not a substitute for clean links.

# Apache .htaccess: force HTTPS site-wide
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Tell browsers to use HTTPS only going forward
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

After deploying both fixes, re-crawl the site to confirm the issue count drops to zero and no new HTTP links have crept back in.

Common mistakes

Hardcoded http URLs. The single biggest source is absolute http:// links typed directly into templates, menu items, and content. Because they are absolute, the redirect rule cannot save you from the extra hop. They must be edited at the source.

Old database links. On CMS platforms, links saved in the database from before your HTTPS migration keep their HTTP prefix forever unless you run a search-and-replace. Always back up the database first, then replace http://yourdomain.com with https://yourdomain.com across post content and serialized options.

Relying on the redirect alone. Some teams assume the site-wide HTTPS redirect makes link cleanup optional. It does not. The redirect fixes the destination but the wasted hop and the duplicate-URL signal remain until the links themselves point to HTTPS.

FAQ