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

What "non-HTTP protocol" links are

Every link on the web uses a URI scheme, the prefix before the colon that tells the browser how to handle the target. Web pages use http:// or https://. Crawlers like Googlebot, Screaming Frog and Sitebulb are built to follow those HTTP schemes, request the resource, read the response and pass on link equity. Anchors that use any other scheme, such as mailto:, tel:, javascript:, ftp: or file:, do not resolve to a crawlable web page. The audit groups these together and surfaces them so you can confirm each one is intentional rather than a broken or misconfigured navigational link.

This is a review-and-confirm warning, not an automatic error. Many of these links are valid; the report simply separates the legitimate ones from cases where a link that should reach a real page does something else.

Which protocols, and when each is legitimate

mailto:

Opens the user's email client with a pre-filled recipient, for example mailto:hello@example.com. This is a legitimate, recommended pattern for contact links. It is not meant to be a page and is correctly ignored by crawlers.

tel:

Triggers a phone dialer, for example tel:+15551234567. Genuinely useful on mobile and expected by users. Like mailto, it is fine to leave in place.

javascript:

Runs inline script when clicked, such as javascript:void(0). This is the scheme that most often signals a real problem. It is almost never a legitimate href and usually indicates a control that should have been a button or a link with a real destination.

ftp:

Points at a file-transfer server. Modern browsers have dropped native FTP support, so these links frequently fail for users and are not indexable. If you need to offer a download, host the file over HTTPS instead.

file:

References a path on the local machine, for example file:///C:/docs/report.pdf. This only works on the author's own computer and is almost always a mistake left over from local testing. It should never ship to production.

Why crawlers flag them

Search engine crawlers exist to discover and fetch web pages over HTTP. When a crawler meets a non-HTTP scheme it cannot send a request or follow the link to a new URL. For mailto and tel that is intended. For a link that was supposed to lead somewhere it means a dead end: the destination is invisible to search engines, receives no internal link equity, and may never be discovered through that link. Auditors raise the warning so you can verify intent rather than silently losing crawl paths.

The javascript: anti-pattern

The most damaging case is using an anchor as a fake button: <a href="javascript:void(0)"> wired to a click handler. Accessibility guidance from MDN and practitioners is consistent here. The rule of thumb is that links are for navigation and buttons are for actions. An anchor without a real href is not reliably keyboard focusable, is not announced as a proper link by screen readers, and clutters the assistive-technology links list with destinations that go nowhere. Screen reader users expect links in the links list and buttons in the buttons list; keyboard users expect Enter to follow a link and Space or Enter to fire a button. A javascript: anchor breaks all of those expectations at once. If the element performs an in-page action, it should be a real <button>. If it navigates, it should be an anchor with a genuine URL.

How to diagnose

Run a crawl and open the report that lists outgoing links with their target protocol. In Screaming Frog the Outlinks export includes a protocol column, so you can filter for anything that is not http or https. Review each flagged anchor and classify it: a contact mailto or tel link is fine, while a javascript:, ftp: or file: link in a navigational context needs fixing. Pay special attention to anchors with a javascript: href that carry an onclick handler, and to any file: links, which should not exist in production at all.

How to fix

For real navigation, give the anchor a genuine href and attach behaviour with a proper event listener rather than an inline scheme. For in-page actions that do not change the URL, use a button element. Leave legitimate mailto and tel links exactly as they are. Replace ftp and file links with HTTPS-hosted resources.

<!-- BAD: fake button, no crawlable destination -->
<a href="javascript:void(0)" onclick="openMenu()">Menu</a>

<!-- BAD: navigational link with no real target -->
<a href="javascript:loadProducts()">View products</a>

<!-- BAD: local file path shipped to production -->
<a href="file:///C:/site/guide.pdf">Download guide</a>

<!-- GOOD: an action is a button -->
<button type="button" onclick="openMenu()">Menu</button>

<!-- GOOD: navigation uses a real, crawlable URL -->
<a href="/products/">View products</a>

<!-- GOOD: the file is hosted over HTTPS -->
<a href="https://example.com/files/guide.pdf">Download guide</a>

<!-- GOOD: legitimate contact links, left untouched -->
<a href="mailto:hello@example.com">Email us</a>
<a href="tel:+15551234567">Call us</a>

Common mistakes

Treating every flagged link as an error and stripping out valid mailto or tel contact links is a frequent overreaction; those should stay. Swapping a javascript: anchor for <a href="#"> is not a fix either, because it scrolls to the top and still is not a proper control. Adding role="button" to an anchor instead of using a real button piles on ARIA to patch the wrong element. And leaving file: links live, assuming they work because they open on your machine, ships a link that is broken for every visitor.

FAQ