Google crawle-t-il vraiment autre chose que HTTP et HTTPS ?

Google peut-il réellement indexer des contenus FTP ou autres protocoles ?

La réponse officielle est oui, techniquement Google peut crawler du FTP. Dans la pratique, cette capacité existe depuis les débuts du moteur, époque où les serveurs FTP publics hébergeaient des masses de documents PDF, archives et fichiers texte.

Mais ce "peut" ne signifie pas "devrait". La nuance est cruciale. Le crawler de Google est optimisé pour HTTP/HTTPS, pas pour d'autres protocoles. FTP, gopher, ou même certains protocoles propriétaires peuvent être lus, mais sans aucune garantie de traitement équivalent.

Pourquoi Google maintient-il cette compatibilité technique si elle est déconseillée ?

Héritage technique avant tout. Des millions de liens FTP existent encore sur le web, notamment dans des archives académiques, des forums techniques, des documentations anciennes. Ignorer totalement ces protocoles créerait des trous dans l'index.

Cela dit, le support reste minimal. Pas de rendu JavaScript évidemment, pas de suivi des redirections complexes, pas de signals de qualité comparables à ceux d'une page HTTPS moderne. Un fichier sur FTP peut apparaître dans les résultats, mais il partira avec un handicap énorme en termes de ranking.

Quelle est la différence concrète entre "crawler" et "indexer de façon optimale" ?

Crawler, c'est récupérer le contenu. Indexer de façon optimale, c'est analyser tous les signaux modernes : Core Web Vitals, HTTPS, structured data, crawl rendering, liens internes, autorité de domaine, freshness, mobile-first, etc.

Un fichier FTP sera crawlé comme un simple document texte brut. Aucun contexte sémantique riche, aucune mise en page analysée, aucune UX mesurée. C'est l'équivalent d'indexer une photocopie noir et blanc d'un magazine couleur : techniquement possible, factuellement inutile pour ranker correctement.

• HTTP/HTTPS bénéficient de centaines de signaux de ranking que les autres protocoles ignorent totalement
• FTP et autres protocoles sont crawlés sans rendering, sans analyse comportementale, sans metrics de performance
• Le passage en HTTPS est un signal de confiance explicite, absent des protocoles alternatifs
• Les outils Search Console et Analytics ne fonctionnent qu'avec HTTP/HTTPS, rendant tout pilotage SEO impossible ailleurs
• Aucun support des standards modernes (schema.org, OpenGraph, meta robots) sur protocoles non-web

Cette déclaration est-elle cohérente avec les observations terrain ?

Totalement. Je n'ai jamais vu un site FTP ranker correctement sur une requête compétitive. Les rares occurrences de résultats FTP concernent des recherches ultra-nichées, souvent des noms de fichiers exacts, où aucun contenu HTTP concurrent n'existe.

La formulation de Google est d'ailleurs diplomatique mais sans ambiguïté. "Peut crawler" ne veut pas dire "va traiter équitablement". C'est une tolérance technique, pas une recommandation stratégique. En 15 ans de pratique, je n'ai jamais eu à défendre un choix FTP devant un client, et c'est heureux.

Dans quels cas cette règle pourrait-elle ne pas s'appliquer strictement ?

Soyons francs : aucun cas business légitime ne justifie du FTP pour du contenu web en production. Les seuls scénarios où ça pourrait avoir un sens théorique sont des archives historiques accessibles uniquement en lecture, où la priorité est la préservation, pas le ranking.

Mais même dans ce cas, la bonne pratique reste d'exposer ces contenus via une interface HTTP avec métadonnées enrichies. Un wrapper HTTP autour de ressources FTP backend offre le meilleur des deux mondes : archivage stable côté serveur, accessibilité moderne côté utilisateur et moteurs.

Quelles nuances faut-il apporter à cette position officielle ?

La principale nuance concerne les ressources embarquées. Une page HTTPS peut pointer vers une ressource FTP (un PDF technique par exemple) sans que cela pénalise directement la page hôte. Ce n'est pas optimal, mais ce n'est pas catastrophique non plus.

Ce qui compte, c'est que la navigation principale, les contenus indexables prioritaires, et l'expérience utilisateur soient sur HTTP/HTTPS. Si 99% de votre site est en HTTPS et que 1% de ressources annexes pointent vers du FTP legacy, personne ne va déclasser votre domaine pour autant. [A vérifier] : aucune donnée publique ne confirme l'impact exact de liens FTP sortants sur le PageRank d'une page HTTPS, mais empiriquement, l'effet semble négligeable tant que le volume reste marginal.

Que faut-il faire concrètement si votre site utilise encore FTP ?

Migration immédiate vers HTTP/HTTPS, sans négociation possible. Chaque jour en FTP est un jour de ranking perdu. La migration elle-même est simple techniquement : hébergement web standard, certificat SSL gratuit (Let's Encrypt), redirections 301 depuis les anciennes URLs FTP si elles sont référencées ailleurs.

Le vrai travail est dans l'inventaire. Listez tous les contenus accessibles via FTP, cartographiez les liens entrants externes, préparez un plan de redirections. Si des outils internes ou partenaires pointent vers vos ressources FTP, prévenez-les en amont du changement de protocole.

Comment vérifier que votre infrastructure n'expose rien d'involontaire en protocoles alternatifs ?

Audit de ports ouverts via des outils comme Nmap ou Shodan. Vérifiez que seuls les ports 80 (HTTP) et 443 (HTTPS) répondent publiquement. Le port 21 (FTP) ne devrait jamais être ouvert côté web public, sauf besoin spécifique interne avec authentification forte.

Testez également les URLs de votre site en remplaçant https:// par ftp:// dans la barre d'adresse. Si quelque chose charge, vous avez une fuite de configuration à colmater immédiatement. Beaucoup de serveurs mal configurés exposent par erreur des répertoires entiers en FTP anonyme.

Quelles erreurs éviter lors de la transition vers HTTP/HTTPS exclusif ?

Première erreur : laisser des liens internes pointer vers d'anciennes URLs FTP après migration. Cela crée des chaînes de redirections inutiles et dilue le link juice. Nettoyez le HTML à la source, pas seulement via .htaccess.

Deuxième erreur : négliger le HTTPS si vous migrez depuis FTP. Passer de FTP à HTTP sans SSL est un gâchis. Vous perdez un signal de ranking positif et exposez vos utilisateurs à des warnings navigateur. HTTPS doit être le standard par défaut, sans exception, même pour des contenus statiques.

• Inventorier tous les contenus actuellement servis via protocoles non-HTTP/HTTPS
• Mettre en place un hébergement web avec support HTTPS natif et certificat SSL valide
• Configurer des redirections 301 permanentes depuis les anciennes URLs FTP vers leurs équivalents HTTPS
• Fermer les ports FTP publics (21, 20) côté firewall si aucun besoin métier légitime
• Auditer les liens entrants externes pointant vers d'anciennes ressources FTP et contacter les webmasters concernés
• Vérifier dans Search Console qu'aucune URL FTP ne remonte dans les rapports de couverture ou d'erreurs