Does Google really crawl anything besides HTTP and HTTPS?

Can Google really index FTP content or other protocols?

The official answer is yes, technically Google can crawl FTP. In practice, this capability has existed since the early days of the engine, when public FTP servers hosted vast amounts of PDF documents, archives, and text files.

But this "can" doesn't mean "should." The distinction is crucial. Google's crawler is optimized for HTTP/HTTPS, not for other protocols. FTP, gopher, or even some proprietary protocols can be read, but there is no guarantee of equivalent processing.

Why does Google maintain this technical compatibility if it is discouraged?

Technical legacy above all. Millions of FTP links still exist on the web, especially in academic archives, technical forums, old documentation. Ignoring these protocols entirely would create gaps in the index.

That said, support remains minimal. No JavaScript rendering, obviously, no tracking of complex redirects, no quality signals comparable to those of a modern HTTPS page. A file on FTP may appear in the results, but it will come with a huge disadvantage in terms of ranking.

What is the concrete difference between "crawling" and "optimal indexing"?

Crawling is retrieving the content. Optimal indexing means analyzing all modern signals: Core Web Vitals, HTTPS, structured data, crawl rendering, internal links, domain authority, freshness, mobile-first, etc.

An FTP file would be crawled like a plain text document. No rich semantic context, no analyzed layout, no measured UX. It is akin to indexing a black-and-white photocopy of a color magazine: technically possible but factually useless for ranking properly.

• HTTP/HTTPS benefit from hundreds of ranking signals that other protocols completely ignore
• FTP and other protocols are crawled without rendering, without behavioral analysis, without performance metrics
• Switching to HTTPS is an explicit trust signal, absent in alternative protocols
• Search Console and Analytics tools only work with HTTP/HTTPS, making any SEO management impossible elsewhere
• No support for modern standards (schema.org, OpenGraph, meta robots) on non-web protocols

Is this statement consistent with field observations?

Absolutely. I have never seen an FTP site rank properly for a competitive query. The rare instances of FTP results involve ultra-niche searches, often exact file names, where no competing HTTP content exists.

Google's wording is actually diplomatic but unambiguous. "Can crawl" does not mean "will treat fairly." It's a technical tolerance, not a strategic recommendation. In 15 years of practice, I have never had to defend an FTP choice to a client, and that's a good thing.

In what cases might this rule not apply strictly?

Let's be honest: no legitimate business case justifies using FTP for production web content. The only theoretical scenarios where it might make sense are historical archives accessible only in read mode, where preservation is prioritized over ranking.

But even then, the best practice remains to expose that content via an HTTP interface with enriched metadata. An HTTP wrapper around backend FTP resources provides the best of both worlds: stable archival on the server side, modern accessibility on the user and engines side.

What nuances should be added to this official position?

The main nuance concerns embedded resources. A HTTPS page can point to an FTP resource (like a technical PDF) without penalizing the host page directly. It’s not optimal, but it’s not catastrophic either.

What matters is that the main navigation, the priority indexable content, and the user experience are on HTTP/HTTPS. If 99% of your site is in HTTPS and 1% of ancillary resources point to legacy FTP, no one is going to downgrade your domain because of it. [To be verified]: no public data confirms the exact impact of outgoing FTP links on the PageRank of an HTTPS page, but empirically, the effect appears negligible as long as the volume remains marginal.

What should you do if your site still uses FTP?

Immediate migration to HTTP/HTTPS, with no negotiations possible. Every day on FTP is a day of lost ranking. The migration itself is technically simple: standard web hosting, free SSL certificate (Let's Encrypt), 301 redirects from old FTP URLs if they are referenced elsewhere.

The real work is in the inventory. List all content accessible via FTP, map out incoming external links, prepare a redirect plan. If internal tools or partners link to your FTP resources, warn them in advance of the protocol change.

How can you check that your infrastructure doesn’t expose anything inadvertently in alternative protocols?

Audit open ports using tools like Nmap or Shodan. Ensure that only ports 80 (HTTP) and 443 (HTTPS) respond publicly. Port 21 (FTP) should never be open on the public web, except for specific internal needs with strong authentication.

Also test your site’s URLs by replacing https:// with ftp:// in the address bar. If something loads, you have a configuration leak to seal immediately. Many misconfigured servers inadvertently expose entire directories via anonymous FTP.

What mistakes should be avoided when transitioning to an exclusive HTTP/HTTPS?

First mistake: leaving internal links pointing to old FTP URLs after migration. This creates unnecessary redirect chains and dilutes link juice. Clean up the HTML at the source, not just via .htaccess.

Second mistake: neglecting HTTPS when migrating from FTP. Switching from FTP to HTTP without SSL is a waste. You lose a positive ranking signal and expose your users to browser warnings. HTTPS must be the default standard, without exception, even for static content.

• Inventory all content currently served via non-HTTP/HTTPS protocols
• Set up web hosting with native HTTPS support and valid SSL certificate
• Configure permanent 301 redirects from old FTP URLs to their HTTPS equivalents
• Close public FTP ports (21, 20) on the firewall if there is no legitimate business need
• Audit incoming external links pointing to old FTP resources and contact the concerned webmasters
• Check in Search Console that no FTP URL appears in coverage or error reports