Pourquoi un CDN ou un hébergeur peut-il générer des erreurs invisibles pour vous ?

Un CDN (Content Delivery Network) sert vos pages depuis des serveurs distribués géographiquement. Si sa configuration est bancale, certaines requêtes de Googlebot peuvent recevoir des réponses différentes de celles qu'un visiteur lambda reçoit.

Typiquement, un interstitiel anti-bot mal calibré peut bloquer Googlebot en pensant filtrer du spam. Résultat : Google voit une page vide ou un captcha là où votre navigateur affiche du contenu. De même, un hébergeur saturé ou mal configuré peut renvoyer des codes 404 temporaires sur des pages parfaitement valides, simplement parce que le serveur n'a pas pu répondre à temps.

Quelle différence entre une erreur ponctuelle et une erreur systématique ?

Google tolère les erreurs sporadiques : un timeout occasionnel, une maintenance de 10 minutes. Ce qui pose problème, c'est la récurrence. Si Googlebot crawle votre site trois fois dans la semaine et obtient trois fois un 404 sur une URL qui devrait retourner du 200, il finit par considérer que cette page n'existe plus.

Le terme systématique est crucial ici. Une erreur devient systématique quand elle se reproduit à chaque tentative de crawl, ou quand elle touche un pourcentage significatif de vos URLs. C'est ce pattern répétitif qui déclenche une réévaluation de la qualité de votre site par l'algorithme.

Comment Googlebot interprète-t-il ces réponses inattendues ?

Googlebot ne devine pas vos intentions. Il lit les codes HTTP que votre infrastructure lui renvoie. Un 404 signifie « page supprimée », un 503 signifie « reviens plus tard », un 200 avec un interstitiel signifie « contenu partiel ou bloqué ».

Si votre CDN retourne un 404 à la place d'un 200, Google désindexe la page. Si votre hébergeur montre un interstitiel CAPTCHA au bot, Google considère que la page n'est pas accessible et ajuste son crawl budget en conséquence : moins de pages crawlées, moins de fraîcheur, perte de positions sur les requêtes concurrentielles.

• Erreurs systématiques : répétées à chaque crawl, déclenchent désindexation ou perte de crawl budget
• Codes HTTP inattendus : 404 au lieu de 200, 503 récurrents, redirections en boucle
• Interstitiels mal configurés : captchas, pages de vérification qui bloquent Googlebot
• Impact sur le crawl budget : Google réduit la fréquence de visite si les erreurs persistent
• Invisibilité côté client : votre navigateur peut voir du contenu correct pendant que Googlebot voit une erreur

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

Oui, et c'est même un classique des audits techniques. On voit régulièrement des sites perdre 30 à 50 % de leur trafic organique après un changement de CDN ou une migration d'hébergeur, sans modification du contenu. Le problème n'apparaît souvent qu'après plusieurs semaines, le temps que Google recrawle suffisamment d'URLs pour détecter le pattern.

Ce qui est moins évident, c'est que certains CDN appliquent des règles géolocalisées : Googlebot crawle depuis des IPs américaines, mais aussi européennes ou asiatiques selon le datacenter. Si votre CDN bloque certaines zones ou applique des règles différentes par région, vous pouvez avoir un crawl partiel sans le savoir. [A vérifier] : Google ne précise pas dans quelle mesure il teste depuis plusieurs geolocalisations pour valider la cohérence des réponses.

Quelles nuances faut-il apporter à cette affirmation ?

Google parle d'erreurs systématiques, mais ne donne aucun seuil chiffré. Combien de 404 consécutifs faut-il pour déclencher une désindexation ? Trois ? Cinq ? Dix ? On ne sait pas. En pratique, on observe que Google peut tolérer quelques erreurs si le site a un bon historique de fiabilité, mais un nouveau site sera pénalisé plus vite.

Autre point flou : la distinction entre un interstitiel « acceptable » et un interstitiel « bloquant ». Google autorise certains interstitiels (obligations légales, age verification), mais en interdit d'autres (publicités plein écran). Si votre CDN injecte un interstitiel de sécurité (type « vérification en cours »), est-ce considéré comme bloquant ? [A vérifier] : aucune documentation officielle ne tranche ce cas précis.

Quand cette règle ne s'applique-t-elle pas ou devient-elle contre-productive ?

Si vous gérez un site sous attaque DDoS, activer un interstitiel anti-bot sur votre CDN est parfois la seule solution pour rester en ligne. Dans ce cas, le risque SEO devient secondaire par rapport au risque de disponibilité totale. Google comprend généralement les erreurs temporaires liées à des incidents de sécurité, à condition qu'elles ne durent pas plusieurs semaines.

Autre cas limite : les sites e-commerce avec stock fluctuant. Si une fiche produit retourne un 404 parce que l'article est en rupture définitive, c'est cohérent. Mais si votre hébergeur bug et renvoie des 404 aléatoires sur des produits en stock, là c'est catastrophique. La règle de Google s'applique dans le second cas, pas dans le premier.

Comment vérifier que votre CDN ne bloque pas Googlebot ?

Première étape : testez vos URLs critiques avec l'outil Inspection d'URL de la Search Console. Il simule un crawl Googlebot réel et vous montre exactement ce que Google voit. Si l'outil affiche une erreur alors que votre navigateur affiche la page correctement, votre CDN ou hébergeur est le coupable.

Deuxième vérification : consultez les logs serveur bruts. Filtrez par User-Agent Googlebot et examinez les codes HTTP retournés. Si vous voyez des séquences de 404, 503 ou 403 sur des URLs valides, creusez du côté de votre infrastructure. Comparez aussi les réponses servies à Googlebot versus celles servies à un navigateur classique : toute différence est un red flag.

Quelles erreurs éviter lors du choix ou de la configuration d'un CDN ?

Ne jamais activer un mode « I'm Under Attack » (Cloudflare) ou équivalent de manière permanente. Ces modes sont conçus pour des situations d'urgence, pas pour un fonctionnement quotidien. Ils affichent un interstitiel JavaScript à tous les visiteurs, y compris Googlebot, ce qui bloque l'indexation.

Évitez aussi les règles de rate limiting trop strictes : si Googlebot crawle 50 pages en 2 minutes (ce qui est normal pour un site moyen), un rate limit à 10 requêtes/minute va le bloquer. Résultat : des 429 (Too Many Requests) en série, interprétés comme des erreurs systématiques. Configurez des seuils adaptés au crawl budget réel de votre site.

Que faire si vous détectez des erreurs systématiques ?

Isolez d'abord la source : CDN ou hébergeur. Désactivez temporairement le CDN (passez en DNS direct vers votre serveur origine) et relancez un crawl test. Si les erreurs disparaissent, le CDN est en cause. Si elles persistent, c'est l'hébergeur.

Une fois le coupable identifié, corrigez la configuration (whitelist des bots, ajustement du rate limiting, désactivation des interstitiels agressifs) puis demandez une réindexation via Search Console. Google recrawlera vos URLs dans les jours qui suivent. Surveillez les métriques de crawl dans la Search Console : une remontée du nombre de pages crawlées par jour indique que le problème est résolu.

• Tester les URLs prioritaires avec l'outil Inspection d'URL de la Search Console
• Analyser les logs serveur pour détecter les codes HTTP anormaux retournés à Googlebot
• Vérifier que Googlebot et Bingbot sont en whitelist sur le CDN
• Désactiver les modes anti-DDoS permanents (« I'm Under Attack » etc.)
• Ajuster le rate limiting pour tolérer le crawl budget naturel de votre site
• Comparer les réponses servies à Googlebot versus navigateur classique (via curl ou logs)