Has Link to Non-HTTP Protocol: When It Is a Problem

TL;DR: This check flags anchors pointing to schemes other than http/https, things like mailto:, tel:, javascript:, ftp:, and file:. Contact links are fine and expected. The one to hunt down is a navigational link built on javascript:, which gives crawlers and users no real, indexable destination.

What a "non-HTTP protocol" link is

Every link declares a URI scheme, the bit before the colon that tells the browser how to handle the target. Web pages use http:// or https://, and crawlers like Googlebot, Screaming Frog, and Sitebulb are built to request those, read the response, and pass link equity along. Any other scheme does not resolve to a crawlable page. This audit groups them so you can confirm each is intentional rather than a broken or lazy navigation link. It is a review-and-confirm warning, not an automatic error: plenty of these links are perfectly valid.

Think of it as a sorting job rather than a bug hunt. The report pulls together every non-HTTP link so you can split them into two piles: the contact links that are supposed to be there, and the handful of cases where a link that should reach a real page is quietly pointing at a script, a dead protocol, or a local file path. Most of the list is usually the first pile; the value is in catching the few that belong in the second.

Which schemes are fine, and which one bites

A real failing snippet, and the fix

The problem case is a link that looks like navigation but goes nowhere a crawler can follow. Note the example below is defanged (a space inserted after the colon) so it cannot execute:

<!-- Fails: fake navigation, no crawlable destination -->
<a href="javascript: void(0)" onclick="loadPanel('specs')">
  View specifications
</a>

Googlebot cannot follow javascript:, so the "specs" content behind it is invisible to search and unreachable by keyboard in some setups. If the content lives at a real URL, link to it. If it is a genuine in-page control that toggles something, it should be a <button>, not an anchor:

<!-- Fixed A: real, crawlable destination -->
<a href="/products/widget/#specifications">View specifications</a>

<!-- Fixed B: it's a control, so use a button -->
<button type="button" onclick="loadPanel('specs')">View specifications</button>

The rule of thumb: if it takes you to content, it is a link and needs an href to a real page. If it manipulates the current page, it is a button. A dummy javascript: href is neither and should not exist.

How to detect it

1. Screaming Frog. Crawl, then use Custom Search (or export All Outlinks) and filter the link targets for javascript:, ftp:, and file:. Screaming Frog also lists non-HTTP outlinks separately so you can eyeball what should not be there.
2. axe / keyboard test. Tab through the page. A javascript: "link" that is really a control often cannot be reached or activated by keyboard, and axe flags anchors with no valid href. That failure is your signal to convert it to a button.
3. View Source. Search the raw HTML for href="javascript, href="ftp, and href="file. Any hit that is not a deliberate mailto: or tel: gets reviewed.

How to fix it

1. Sort the flagged links by scheme. Leave the mailto: and tel: links alone; they are working as intended.
2. For every javascript: href, decide: does it navigate, or does it act on the page? Navigation gets a real href; page actions become <button> elements.
3. For ftp: downloads, move the file behind HTTPS and link to the new URL, because modern browsers have dropped native FTP.
4. Delete any file: links outright; they only ever worked on the author's own machine.
5. Re-crawl and confirm the only non-HTTP schemes left are the intentional contact links.

Frequently asked questions

Are mailto: and tel: links bad for SEO?

No. They are the correct, expected pattern for contact and phone links, and crawlers know to ignore them. They only appear in this report so you can confirm the non-HTTP links are the ones you meant to have.

Why is javascript: in an href a problem when the click still works?

It works for a mouse user with JavaScript enabled, but Googlebot cannot follow it to a destination, so any content behind it may go undiscovered, and it often breaks keyboard access. Real destinations belong in an href; page actions belong in a button.

Do ftp: links still function at all?

Barely. Chrome, Firefox, and Edge removed built-in FTP support, so these links now fail for most users and are not indexable. Host the file over HTTPS and link to that instead.

The audit flagged a file: link I don't remember adding. Where do those come from?

Usually copy-paste from local testing, where an author dragged a file into an editor and the local path stuck. It only resolves on that one machine, so remove it before it ships.

Related checks

A file: scheme is closely related to the Link to Local Path check, and stray characters in a target are covered by Has Link with Whitespace in Href. If your concern is how much of the page a javascript: pattern hides from search, the JavaScript SEO rendering guide explains what crawlers can and cannot see, and Disallowed JavaScript File covers the related rendering trap.