HTTP/2 pour le crawl : faut-il abandonner le domain sharding ?

Qu'est-ce que le multiplexage HTTP/2 et pourquoi Google s'y intéresse ?

Le multiplexage HTTP/2 permet de transmettre plusieurs requêtes et réponses simultanément sur une seule connexion TCP. Avec HTTP/1.1, le navigateur ou le crawler devait ouvrir plusieurs connexions parallèles pour charger simultanément plusieurs ressources — d'où la limite de 6 connexions par domaine dans la plupart des navigateurs.

Pour Google, l'enjeu est double : réduire la charge réseau côté infrastructure de crawl (moins de négociations TCP/SSL) et crawler plus efficacement les sites qui hébergent de nombreuses ressources. Le multiplexage élimine le phénomène de « head-of-line blocking » qui ralentissait HTTP/1.1.

Pourquoi seulement 10-20% des sites sont crawlés en HTTP/2 ?

Google déploie cette fonctionnalité de manière progressive et contrôlée. Splitt ne donne pas de détails sur les critères de sélection : taille du site, volume de crawl, compatibilité serveur, ou simple test A/B interne.

Ce déploiement partiel suggère que Google teste la stabilité et l'impact sur son infrastructure avant une généralisation. Certains serveurs ou configurations peuvent aussi mal gérer HTTP/2, provoquant des erreurs de crawl.

Faut-il encore utiliser le domain sharding ?

Le domain sharding consistait à répartir les ressources statiques (images, CSS, JS) sur plusieurs sous-domaines (cdn1.exemple.com, cdn2.exemple.com) pour contourner la limite de 6 connexions HTTP/1.1 par domaine. Avec HTTP/2, cette technique devient contre-productive.

Multiplier les domaines force désormais le navigateur (ou Googlebot) à ouvrir plusieurs connexions HTTP/2 distinctes, annulant l'avantage du multiplexage. Google ne le dit pas explicitement, mais le domain sharding peut même ralentir le crawl si Googlebot privilégie HTTP/2.

• HTTP/2 élimine le besoin de domain sharding grâce au multiplexage sur une seule connexion
• Google ne crawle qu'une minorité de sites en HTTP/2 (10-20%), le reste reste en HTTP/1.1
• Le déploiement progressif indique une phase de test, pas une migration générale
• Le domain sharding peut devenir un frein si Googlebot privilégie HTTP/2
• Aucun critère public sur les sites éligibles au crawl HTTP/2

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

La migration partielle vers HTTP/2 pour le crawl est cohérente avec la prudence habituelle de Google face aux changements d'infrastructure. Les logs serveur confirment que Googlebot utilise majoritairement HTTP/1.1, même sur des sites HTTP/2-ready.

Ce qui surprend, c'est l'absence de communication sur les critères de sélection. Google ne dit pas si les sites crawlés en HTTP/2 sont choisis par taille, secteur, ou configuration serveur. [A vérifier] : aucune donnée publique ne permet de savoir si un site sera crawlé en HTTP/2 ou HTTP/1.1.

Quelles nuances faut-il apporter à cette annonce ?

Splitt présente HTTP/2 comme un avantage net, mais il omet plusieurs points. D'abord, HTTP/2 n'améliore pas directement le ranking : c'est une optimisation côté Google, pas un facteur de classement. Ensuite, tous les serveurs ne gèrent pas HTTP/2 de manière optimale.

Certains hébergeurs mutualisés ou configurations nginx mal paramétrées peuvent provoquer des timeouts ou des erreurs de connexion avec Googlebot HTTP/2. Si Google détecte ces erreurs, il peut fallback sur HTTP/1.1 — mais on ne sait pas combien de temps cela prend, ni si cela impacte le crawl budget.

[A vérifier] : Google ne précise pas si un site non crawlé en HTTP/2 perd en efficacité de crawl, ni si le passage de HTTP/1.1 à HTTP/2 augmente le nombre de pages crawlées par session.

Le domain sharding est-il vraiment obsolète partout ?

Pour les sites crawlés en HTTP/2, oui, le domain sharding n'a plus de sens. Mais si 80-90% des sites restent crawlés en HTTP/1.1, le retirer brutalement peut réduire le parallélisme du crawl et ralentir l'indexation.

Concrètement, un site avec 50 000 pages et un domain sharding agressif (4-5 sous-domaines) peut voir son crawl ralentir si Googlebot reste en HTTP/1.1. L'inverse est aussi vrai : si Google passe en HTTP/2 sans que le site ne consolide ses domaines, on perd l'avantage du multiplexage.

Comment savoir si Googlebot crawle mon site en HTTP/2 ?

La seule méthode fiable est d'analyser les logs serveur. Cherchez les requêtes Googlebot et identifiez le protocole utilisé (HTTP/1.1 ou HTTP/2). La plupart des logs nginx ou Apache affichent cette information dans le champ de requête.

Si vous n'avez pas accès direct aux logs, utilisez un outil comme Screaming Frog Log File Analyser ou OnCrawl pour filtrer les requêtes Googlebot et vérifier le protocole. Attention : un site peut être crawlé en HTTP/2 sur certaines sections et HTTP/1.1 sur d'autres.

Faut-il retirer le domain sharding immédiatement ?

Si vos logs confirment que Googlebot crawle majoritairement en HTTP/2, oui, consolidez vos domaines. Regroupez vos ressources statiques sur un seul domaine (ou utilisez un CDN unique) pour maximiser le multiplexage.

Si Googlebot reste en HTTP/1.1, ne touchez à rien pour l'instant. Gardez le domain sharding jusqu'à ce que Google généralise HTTP/2. Surveillez vos logs mensuellement pour détecter un basculement.

Quelles erreurs éviter lors de la migration ?

Ne supprimez pas brutalement les sous-domaines sans redirections. Si vous consolidez cdn1.exemple.com et cdn2.exemple.com vers cdn.exemple.com, mettez en place des 301 permanentes pour éviter les 404 pendant la transition.

Vérifiez aussi que votre serveur HTTP/2 est correctement configuré : compression Brotli activée, push server désactivé (souvent contre-productif), limites de connexions suffisantes. Une mauvaise config HTTP/2 peut provoquer des erreurs de crawl pires que HTTP/1.1.

• Analyser les logs serveur pour identifier le protocole de crawl Googlebot (HTTP/1.1 ou HTTP/2)
• Ne retirer le domain sharding que si Googlebot crawle majoritairement en HTTP/2
• Mettre en place des redirections 301 lors de la consolidation des domaines
• Vérifier la configuration serveur HTTP/2 (compression, limites de connexions, timeouts)
• Surveiller les logs mensuellement pour détecter un basculement vers HTTP/2
• Tester la charge serveur après migration : HTTP/2 peut augmenter le nombre de requêtes simultanées