Quels encodages HTTP Googlebot accepte-t-il réellement pour crawler vos pages ?

Pourquoi cette clarification arrive-t-elle si tard ?

Google a officiellement documenté les trois types d'encodage HTTP que ses crawlers acceptent, alors que cette information traînait depuis des années dans des articles de blog épars. Soyons honnêtes : cette opacité a généré son lot de confusion et d'erreurs de configuration serveur.

La raison probable ? Google ne voyait pas cette information comme prioritaire. Mais avec la montée en puissance des Core Web Vitals et l'importance accrue de la vitesse de crawl, documenter ces détails techniques devient indispensable.

Quels sont ces trois encodages supportés ?

Google supporte gzip, deflate, et br (Brotli). Le premier reste le plus répandu, mais Brotli offre un meilleur ratio de compression — surtout pour les ressources textuelles comme le HTML, CSS, et JavaScript.

Deflate est moins utilisé en pratique, car gzip l'a largement supplanté. Mais le fait que Googlebot l'accepte signifie qu'un serveur configuré avec deflate ne posera pas de problème d'indexation.

Qu'est-ce que ça change concrètement pour le crawl ?

Un serveur qui répond avec un encodage non supporté peut entraîner des erreurs de lecture côté Googlebot. Résultat : la page n'est pas indexée ou mal interprétée.

Autre point : un mauvais choix d'encodage peut ralentir le temps de réponse serveur. Et si le temps de crawl explose, Google passera moins souvent — surtout sur les gros sites avec des milliers de pages.

• Googlebot accepte gzip, deflate, et Brotli pour la compression HTTP
• Brotli offre un meilleur taux de compression que gzip sur du contenu textuel
• Un encodage non supporté peut bloquer l'indexation ou ralentir le crawl
• La configuration serveur doit être testée pour éviter les erreurs de compression

Cette déclaration est-elle cohérente avec les pratiques observées ?

Oui. Depuis des années, les professionnels SEO qui activent Brotli sur leurs serveurs constatent que Googlebot crawle sans problème. Mais jusqu'à cette documentation officielle, il fallait se fier à des tests empiriques ou à des déclarations éparses dans des forums.

Ce qui manque ici — et c'est frustrant — c'est un ordre de préférence. Google privilégie-t-il Brotli si le serveur le propose ? Ou choisit-il automatiquement selon la bande passante disponible ? [À vérifier] sur la base de logs serveur détaillés.

Quelles nuances faut-il apporter ?

Attention : tous les crawlers Google ne se comportent pas forcément de la même manière. GoogleBot Desktop et Mobile partagent probablement les mêmes capacités d'encodage, mais qu'en est-il des crawlers spécialisés comme Google-InspectionTool ou AdsBot ?

Autre nuance : activer Brotli côté serveur demande une configuration spécifique. Sur Apache ou Nginx, cela passe par des modules additionnels. Si le module n'est pas installé ou mal configuré, le serveur peut renvoyer du contenu non compressé — ce qui pénalise la vitesse de chargement.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si votre serveur répond avec un encodage propriétaire ou exotique (type SDCH, jadis testé par Google puis abandonné), Googlebot ne saura pas lire la réponse. Résultat : erreur de crawl.

Également : certains CDN appliquent une compression automatique. Si le CDN choisit un encodage non supporté ou mal implémenté, cela peut créer des incohérences entre ce que voit l'utilisateur et ce que crawle Google.

Que faut-il faire concrètement ?

Première étape : vérifier que votre serveur renvoie bien du gzip ou Brotli dans les en-têtes HTTP. Utilisez un outil comme curl ou les DevTools Chrome pour inspecter les headers Content-Encoding.

Si vous êtes sur Apache, activez mod_brotli ou mod_deflate. Sur Nginx, ajoutez le module ngx_brotli. Testez ensuite avec un crawler comme Screaming Frog pour vérifier que Googlebot reçoit bien les réponses compressées.

Quelles erreurs éviter ?

Ne jamais activer la compression sur des fichiers déjà compressés (images JPEG, PNG, vidéos). Cela augmente la charge serveur sans gain de poids.

Évitez aussi de compresser les fichiers très petits (moins de 1 Ko). Le surcoût en calcul dépasse le gain en bande passante.

Comment vérifier que mon site est conforme ?

Configurez Google Search Console pour surveiller les erreurs de crawl. Si des pages retournent des erreurs 5xx ou des timeouts, vérifiez les logs serveur pour détecter d'éventuels problèmes de compression.

Utilisez aussi PageSpeed Insights ou GTmetrix pour mesurer l'impact de la compression sur le temps de chargement. Un bon ratio de compression Brotli peut réduire le poids HTML de 15 à 20 % par rapport à gzip.

• Vérifier les en-têtes Content-Encoding dans les réponses HTTP
• Activer Brotli sur Apache (mod_brotli) ou Nginx (ngx_brotli)
• Ne pas compresser les fichiers déjà compressés (images, vidéos)
• Exclure les fichiers de moins de 1 Ko de la compression
• Surveiller les erreurs de crawl dans Google Search Console
• Tester l'impact de la compression avec PageSpeed Insights