Guide des CDN et du SEO

TL;DR — Un CDN est un réseau mondial de serveurs qui conserve des copies de vos pages et les diffuse depuis un emplacement proche de chaque visiteur. Il accélère et fiabilise le site. Ce n’est pas un facteur de classement direct, mais il améliore des éléments mesurés par Google. Son principal risque SEO est un blocage accidentel des robots des moteurs, qui peut être corrigé.

Qu’est-ce qu’un CDN ?

Sans CDN, chaque visiteur contacte votre serveur d’origine, où qu’il se trouve. Plus la distance est grande, plus chaque requête prend du temps.

Un CDN place des copies du contenu sur de nombreux serveurs périphériques. Le visiteur reçoit la réponse du nœud le plus proche, ce qui réduit le délai et la charge de l’origine. Cloudflare, Fastly, Akamai, Amazon CloudFront et Bunny sont des exemples courants.

Un CDN aide-t-il le SEO ?

Réponse courte : le CDN n’est pas lui-même un facteur de classement, mais il améliore des éléments qui comptent. Google ne récompense pas sa simple présence. Il peut :

• Accélérer les pages et améliorer les Core Web Vitals.
• Maintenir le site disponible pendant des pointes, de brèves pannes ou des attaques grâce au cache et à la protection.
• Permettre une exploration plus rapide : Google relève le seuil de débit d’exploration lorsqu’il détecte un CDN.

Le CDN est donc un outil qui soutient le SEO, pas un bouton magique de classement.

Principal risque SEO d’un CDN

La protection contre les robots bloque les flots malveillants, mais peut aussi intercepter Googlebot ou Bingbot et leur présenter un défi « prouvez que vous êtes humain ». Le moteur ne voit alors plus la page, ce qui peut affecter les positions.

Le problème se diagnostique avec Inspection d’URL dans Google Search Console. Si Google reçoit une page blanche, une erreur ou un défi plutôt que le contenu, corrigez la règle de pare-feu avec le fournisseur du CDN.

Deux autres inquiétudes sont généralement infondées :

• Une adresse IP de CDN partagée ne pose aucun problème ; John Mueller indique qu’un bloc d’IP dédié est inutile.
• La pénalité pour contenu dupliqué liée au CDN n’existe pas. Une mauvaise configuration peut seulement conduire Google à choisir une mauvaise URL canonique, ce qui se corrige avec les balises appropriées.

Pour le budget d’exploration, les caches froids, les blocages de robots, les consignes Google de décembre 2024, HTTPS et les URL canoniques à la périphérie, ouvrez l’onglet Avancé.

TL;DR — Un CDN diffuse le contenu depuis des serveurs périphériques proches, réduit le TTFB, améliore les Core Web Vitals, renforce la disponibilité et permet à Google d’élever ses seuils d’exploration. Ce n’est pas un facteur de classement. Les risques sont opérationnels : un cache froid oblige toujours l’origine à servir chaque nouvelle URL au moins une fois ; le WAF ou les défis antirobots peuvent bloquer les moteurs ; les URL canoniques et HTTPS doivent traverser la périphérie sans altération. En décembre 2024, Google a déconseillé en moins d’une semaine de placer les ressources JS/CSS critiques sur un sous-domaine de CDN, tout en maintenant cette possibilité pour les gros fichiers non critiques. La source principale est son article sur les CDN et l’exploration publié pendant « Décembre de l’exploration ».

Ce que fait réellement un CDN

Le CDN est un intermédiaire entre le serveur d’origine et tous ceux qui demandent vos URL. L’article Google de décembre 2024 le décrit comme un intermédiaire entre l’origine et l’utilisateur final, qui stocke temporairement une URL après sa première requête. Son objectif est de réduire la latence du site, même lorsque le trafic est important.

Cet article de Martin Splitt et Gary Illyes constitue la source la plus récente et la plus autorisée des moteurs sur les CDN et le SEO. L’analyse ci-dessous s’y appuie largement.

Soyons précis : un CDN désigne la topologie distribuée de nœuds périphériques qui mettent en cache et servent le contenu entre l’origine et les demandeurs. Il ne se confond ni avec l’hébergement, ni avec le cache HTTP. Le WAF et la terminaison TLS sont des fonctions distinctes souvent regroupées par les fournisseurs.

Un CDN aide-t-il le SEO ? Réponse honnête

Un CDN n’est pas un facteur de classement. Il agit sur les performances et la fiabilité, qui influencent trois domaines utiles :

TTFB plus court et Core Web Vitals

Un cache périphérique proche réduit le temps d’aller-retour et le time to first byte, qui précède le LCP des Core Web Vitals. Google explique que le cache des médias, JavaScript, CSS et HTML diminue la charge serveur et accélère les pages dans le navigateur, avec une corrélation positive sur les conversions. C’est l’argument SEO le plus solide, en lien avec le cache, les resource hints et les outils de performance.

Le bénéfice dépend cependant d’un cache hit proche. Un miss, une réponse personnalisée non mise en cache ou un nœud mal placé peut laisser le TTFB inchangé, voire ajouter un surcoût. Le gain existe lorsque la périphérie peut réellement servir la réponse.

Seuil d’exploration supérieur pour les sites avec CDN

Google déduit la capacité du serveur à partir de l’IP et conçoit son infrastructure pour autoriser un débit d’exploration supérieur sur les sites derrière un CDN. Le seuil de limitation devient beaucoup plus élevé lorsqu’un CDN est détecté. Il s’agit d’un plafond de capacité déduit, pas d’une garantie de budget, d’indexation ou de classement ; la demande d’exploration détermine l’usage réel de ce plafond.

Fiabilité, disponibilité et protection contre les flots

Google cite la protection contre les flots, qui identifie et bloque le trafic excessif ou malveillant, et la fiabilité, puisque certains CDN servent encore le site lorsque l’origine tombe. Les CDN peuvent absorber des attaques DDoS de plusieurs térabits. Une indisponibilité durable qui renvoie des erreurs à Googlebot finit, elle, par nuire à l’indexation.

Limite du budget d’exploration : caches froids

Un CDN ne dispense pas l’origine de servir les nouvelles URL. À la première requête, le cache est froid et doit être alimenté. Pour une boutique lançant plus d’un million d’URL, Google rappelle que le serveur devra servir ces 1 000 007 URL au moins une fois. La charge initiale et le pic d’exploration restent donc réels.

Conséquence pratique : lors d’un lancement massif, d’une migration ou d’un nouveau catalogue, dimensionnez l’origine pour le premier passage. Le CDN protège après le réchauffement, pas pendant celui-ci.

Placer les fichiers statiques sur un sous-domaine de CDN ?

Vous pouvez héberger CSS, JS et images sur cdn.example.com ou placer le nom d’hôte principal derrière le CDN ; Google prend en charge les deux solutions. Un hôte distinct peut aider le service de rendu, mais la nouvelle connexion peut dégrader les performances.

Google a changé de position en moins d’une semaine. Le 3 décembre 2024, il suggérait d’héberger les ressources sur un autre nom d’hôte. Trois jours plus tard, il a précisé que le surcoût de connexion pouvait ralentir la page et déconseillé cette stratégie pour JavaScript et CSS critiques. Elle reste envisageable pour les vidéos et téléchargements non critiques. Le WRS conserve en outre JS/CSS jusqu’à 30 jours, indépendamment de vos en-têtes HTTP.

Quand le CDN nuit au SEO : blocage des robots

Le principal problème réel n’est pas le contenu dupliqué, mais l’exclusion silencieuse des robots. Google avertit que les robots souhaités peuvent finir dans la liste de blocage du CDN, généralement dans le WAF. Il distingue blocages durs et souples.

Blocages durs : le code de statut est essentiel

• HTTP 503 / 429 — bon signal d’un blocage temporaire, qui laisse le temps de corriger avant une désindexation.
• Délai réseau dépassé — mauvais signal, considéré comme une erreur terminale « dure ». Les conséquences dépendent de la classe d’erreur, de la durée et de la répétition, selon la documentation sur les codes HTTP et erreurs réseau ou DNS.
• Message d’erreur servi avec un statut 200 — pire cas. Google peut supprimer l’URL comme erreur dure ou éliminer comme doublons les pages partageant ce corps.

Règle immédiatement exploitable : un 503 propre vaut mieux qu’une page d’erreur 200 prétendument disponible.

Blocages souples : interstitiels de vérification

Un défi « êtes-vous humain ? » remplace entièrement la page pour le robot. Google recommande un signal clair sous forme de statut HTTP 503 aux clients automatisés afin d’éviter une suppression automatique du contenu.

Méthode de diagnostic

Utilisez Inspection d’URL dans Search Console et examinez la capture rendue. Une page blanche, une erreur ou un défi désigne le CDN. Vérifiez ensuite l’identité du robot avec les plages publiées, puis corrigez le WAF. Google avertit que des IP peuvent être bloquées automatiquement à votre insu et publie les plages Googlebot.

J’ai observé ce type de panne dans toute la pile. Ma présentation SMX Advanced 2018 « Solving Complex SEO Problems » cartographie les couches où réside la logique : DNS, CDN, middleware, serveur, en-têtes et locale. Lorsqu’un comportement diffère entre navigateur et Googlebot, la périphérie cache souvent la surprise.

En-têtes de cache et canonisation à travers le CDN

Le contenu dupliqué reste un risque gérable, pas une pénalité. Les échecs réels sont les suivants :

• Le CDN sert le contenu depuis son domaine sans reprendre la balise ou l’en-tête canonique de l’origine.
• Les régions diffusent des contenus différents sans hreflang correct.
• La clé de cache ou les chaînes de requête créent des doublons à paramètres.

Veillez à ce que les balises et en-têtes canoniques traversent la périphérie, puis contrôlez-les après le déploiement. La canonisation regroupe les signaux ; une réécriture du CDN envoie simplement un signal contradictoire.

Le mythe à écarter : l’en-tête Vary concerne la correction du cache, pas le SEO. Vary: User-Agent peut réduire le taux de cache si le CDN refuse les réponses variables, mais Google ne l’utilise pas comme signal d’indexation mobile ou ordinateur.

HTTPS/TLS à travers un CDN

Le chiffrement comporte deux segments : origine↔périphérie et périphérie↔client. Tous deux doivent utiliser HTTPS. Un mode « Flexible SSL » peut afficher HTTPS au visiteur tout en parlant HTTP à l’origine, et des URL de fichiers en HTTP créent du contenu mixte. HSTS et CSP doivent aussi traverser la périphérie. HTTPS reste un léger signal de classement. Lors d’un changement de CDN sans modification d’URL, suivez les consignes Google sur le changement d’hébergement.

IP partagées et éléments sans importance

• Une IP de CDN partagée n’affecte pas les positions. John Mueller indique qu’il est normal de partager le bloc d’IP avec d’autres entreprises.
• Le choix entre cdn.example.com et un domaine tiers relève de la technique et des performances, tant que le contenu reste explorable.

Point de vue de Bing

Bing ne publie pas de guide aussi détaillé, mais les mêmes problèmes s’appliquent. Il fournit les plages IP officielles et un outil pour vérifier le robot avant de modifier les listes du WAF : Verify Bingbot et son outil public. Microsoft a également publié la liste des IP Bingbot en JSON. Bing cite la vitesse et le CDN parmi les moyens d’améliorer les temps de chargement. Les remarques de Fabrice Canel sur le contenu distribué décrivent surtout la complexité opérationnelle, pas un signal de classement.

Place dans l’ensemble

Les décisions CDN touchent les performances — cache, resource hints, Core Web Vitals et TTFB —, l’exploration, la canonisation, HTTPS et les migrations. Le CDN aide les signaux utiles si les URL canoniques, HTTPS et l’accès des robots restent intacts à la périphérie ; sinon, il peut provoquer une indexation sans contenu.

Résumé par l’IA

Version condensée de l’onglet Avancé :

• Un CDN n’est pas un facteur de classement, mais il améliore TTFB, LCP, Core Web Vitals, disponibilité, HTTPS et efficacité d’exploration.
• Google élève le seuil d’exploration des sites derrière un CDN, d’après l’IP de service. C’est un plafond de capacité, sans garantie de budget, d’indexation ou de classement.
• Un cache froid oblige l’origine à servir chaque nouvelle URL au moins une fois. Les gros lancements sollicitent donc encore le budget d’exploration et le serveur.
• Google déconseille depuis décembre 2024 de placer JS/CSS critiques sur un sous-domaine de CDN, à cause du coût de connexion ; les gros fichiers non critiques restent adaptés.
• Le principal échec est le blocage des robots. 503/429 signale un problème temporaire récupérable ; les délais réseau sont des erreurs terminales ; une page d’erreur 200 risque la suppression ou la déduplication. Les interstitiels doivent répondre 503.
• Diagnostiquez avec la capture rendue d’Inspection d’URL, les plages IP officielles et les listes du WAF.
• Les URL canoniques doivent traverser la périphérie. Les chaînes de requête et les régions peuvent créer des doublons ; Vary concerne le cache, pas le SEO.
• HTTPS doit protéger les deux segments et les IP de CDN partagées ne nuisent pas au classement.

Documentation officielle

Documentation de première main publiée par les moteurs.

Google

• Crawling December : CDN et exploration (Splitt et Illyes, décembre 2024) — cache, protection, débit d’exploration, caches froids, blocages et diagnostic.
• Crawling December : fonctionnement de l’exploration Googlebot — répartition des ressources, correction du 6 décembre sur JS/CSS critiques et cache WRS de 30 jours.
• Codes HTTP et erreurs réseau ou DNS — conséquences des blocages, délais et erreurs souples.
• Optimiser le budget d’exploration — limite de capacité évoquée par l’article CDN.
• Changer d’hébergement — changement sans modification d’URL, applicable à l’ajout ou au remplacement d’un CDN.
• Plages IP de Googlebot — validation de Googlebot et correction des faux blocages du WAF.

Bing / Microsoft

• Vérifier Bingbot — confirmer le robot avant toute modification du WAF.
• Outil Verify Bingbot — outil public de validation.
• Consignes Bing pour les webmasters — recommandations générales, dont la vitesse du site.

Citations des sources

Déclarations publiques de Google avec liens profonds. Les positions de Bing et John Mueller sont résumées dans l’onglet Avancé.

Google — fonction et utilité d’un CDN

• “Content delivery networks (CDNs) are particularly well suited for decreasing latency of your website and in general keeping web traffic-related headaches away. This is their primary purpose after all: speedy delivery of your content even if your site is getting loads of traffic.” (traduction) « Les CDN conviennent particulièrement bien pour réduire la latence et éviter les difficultés liées au trafic ; leur objectif principal est de diffuser rapidement le contenu même sous forte charge. » — Martin Splitt et Gary Illyes, Google Search Central Blog, décembre 2024. Accéder à la citation
• “CDNs are basically an intermediary between your origin server (where your website lives) and the end user, and serves (some) files for them.” (traduction) « Les CDN servent essentiellement d’intermédiaire entre le serveur d’origine et l’utilisateur final, en diffusant certains fichiers à sa place. » Accéder à la citation
• “Traffic flood protection: CDNs are particularly good at identifying and blocking excessive or malicious traffic, letting your users visit your site even when misbehaving bots or no-good-doers would overload your servers.” (traduction) « Les CDN savent identifier et bloquer le trafic excessif ou malveillant afin que les utilisateurs accèdent au site malgré les robots qui surchargeraient les serveurs. » Accéder à la citation
• “Reliability: Some CDNs can serve your site to users even if your site is down. This of course might only work for static content, but that might already be enough to ensure they don’t take their business somewhere else.” (traduction) « Certains CDN peuvent servir le site même lorsqu’il est en panne ; le contenu statique seul peut déjà éviter le départ des utilisateurs. » Accéder à la citation

Google — débit d’exploration et coût du cache froid

• “Our crawling infrastructure is designed to allow higher crawl rates on sites that are backed by a CDN, which is inferred from the IP address of the service that’s serving the URLs our crawlers are accessing.” (traduction) « Notre infrastructure autorise un débit d’exploration supérieur pour les sites derrière un CDN, déduit de l’adresse IP qui sert les URL visitées. » Accéder à la citation
• “In short, even if your webshop is backed by a CDN, your server will need to serve those 1,000,007 URLs at least once.” (traduction) « Même si votre boutique utilise un CDN, votre serveur devra servir ces 1 000 007 URL au moins une fois. » Accéder à la citation

Google — blocage des robots, principal risque réel

• “Due to the CDNs’ flood protection and how crawlers, well, crawl, occasionally the bots that you do want on your site may end up in your CDN’s blocklist, typically in their Web Application Firewall (WAF).” (traduction) « La protection contre les flots et le comportement des robots peuvent placer les robots souhaités dans la liste de blocage du CDN, généralement dans le WAF. » Accéder à la citation
• “In case of these bot-verification interstitials, we strongly recommend sending a clear signal in the form of a 503 HTTP status code to automated clients like crawlers that the content is temporarily unavailable.” (traduction) « Pour ces interstitiels, nous recommandons fortement d’envoyer aux clients automatisés un statut HTTP 503 indiquant l’indisponibilité temporaire du contenu. » Accéder à la citation
• “Remember that the IPs may end up on a blocklist automatically, without you knowing, so checking in on the blocklists every now and then is a good idea for your site’s success in search and beyond.” (traduction) « Des IP peuvent être ajoutées automatiquement à une liste de blocage à votre insu ; vérifiez donc régulièrement ces listes. » Accéder à la citation

Google — répartition par nom d’hôte et correction du 6 décembre

• “Splitting out resources to their own hostname or a CDN hostname (cdn.example.com) may allow our Web Rendering Service (WRS) to render your pages more efficiently. This comes with a caveat though: this practice may negatively affect page performance due to the overhead of a connection to a different hostname.” (traduction) « Séparer les ressources sur leur propre nom d’hôte peut aider le WRS, mais le coût d’une connexion supplémentaire peut dégrader les performances. » Accéder à la citation
• “Update on December 6, 2024: This can result in slower page performance due to the overhead of connection to a different hostname, so we don’t recommend this strategy for critical resources (such as JavaScript or CSS) that are needed for rendering a page.” (traduction) « Mise à jour du 6 décembre 2024 : cette connexion peut ralentir la page ; nous déconseillons donc cette stratégie pour les ressources critiques comme JavaScript ou CSS. » Accéder à la citation

Liste de contrôle d’un audit CDN et SEO

Vérifiez que le CDN aide le SEO sans lui nuire silencieusement :

• Accès des robots : la capture rendue d’Inspection d’URL montre la vraie page, pas une erreur, un blanc ou un défi.
• Liste de blocage du WAF contrôlée pour Googlebot et Bingbot, avec googlebot.json et les plages Bing.
• Blocages temporaires en 503/429, jamais délai réseau ou page d’erreur 200.
• Interstitiels de vérification en 503 pour les clients automatisés.
• Balises et en-têtes canoniques intacts après le déploiement du CDN.
• HTTPS sur les deux segments, sans contenu mixte « Flexible SSL », avec HSTS/CSP préservés.
• Aucun doublon accidentel provenant du domaine CDN, des régions ou des clés de cache ; hreflang correct.
• Gros lancements dimensionnés pour les caches froids, afin que l’origine serve le premier passage.
• JS/CSS critiques non répartis sur un autre sous-domaine ; gros fichiers non critiques autorisés.
• En-têtes de cache corrects, sans contenu obsolète ou inadapté ni chute du taux de hit causée par Vary.

Modèles mentaux

1. Un CDN facilite les signaux sans en être un. Demandez quels éléments il améliore — TTFB, CWV, disponibilité, HTTPS et exploration — plutôt que s’il augmente directement les positions.

2. La périphérie est une couche logique supplémentaire. DNS, CDN, middleware, serveur, en-têtes et locale peuvent chacun modifier redirection, blocage ou réponse. Si Googlebot voit autre chose que le navigateur, examinez la périphérie.

3. Cache chaud contre cache froid. Le CDN protège après le premier accès. Les nouvelles URL sollicitent encore l’origine et le budget d’exploration ; planifiez leur réchauffement.

4. Échouer clairement et temporairement. Un 503/429 propre est préférable à un délai ou à une page d’erreur 200. Un échec temporaire explicite se récupère ; une fausse réussite peut désindexer.

5. Les signaux doivent traverser la périphérie. URL canoniques, HTTPS, en-têtes de sécurité et accès des robots passent tous par le CDN. Vérifiez leur fonctionnement après le déploiement au lieu de le supposer.

Aide-mémoire CDN et SEO

Lorsque le CDN refuse un robot, choisissez la bonne réponse

Ce qu’un CDN fait ou ne fait pas pour le SEO

Repères rapides

• Source principale : Décembre de l’exploration : CDN et exploration de Google, décembre 2024.
• Diagnostiquez les blocages avec la capture rendue d’Inspection d’URL.
• Vérifiez les robots avec googlebot.json et les plages Bing.
• HTTPS doit protéger les deux segments.

Mythes, erreurs et corrections

Voici les croyances courantes sur les CDN et le SEO, leur défaut et la bonne solution.

Mythe : « Un CDN améliorera directement mes positions. » Pourquoi c’est faux : Google ne récompense pas la simple utilisation d’un CDN. Il facilite les performances et la fiabilité. À faire : améliorez et mesurez TTFB, Core Web Vitals, disponibilité et efficacité d’exploration.

Mythe : « Un CDN provoque automatiquement une pénalité pour contenu dupliqué. » Pourquoi c’est faux : cette pénalité n’existe pas. Une configuration canonique incorrecte peut seulement faire choisir une URL inattendue. À faire : contrôlez les balises et en-têtes canoniques après chaque déploiement.

Mythe : « Une IP de CDN partagée avec des sites médiocres dégrade mes positions. » Pourquoi c’est faux : John Mueller indique que ce partage est normal et sans pénalité. À faire : n’achetez pas d’IP dédiées pour des raisons SEO.

Mythe : « Les fichiers statiques sur cdn.example.com améliorent toujours le budget d’exploration. » Pourquoi c’est faux : Google a corrigé ce conseil en décembre 2024 ; pour JS/CSS critiques, le coût d’une connexion supplémentaire dépasse le gain. À faire : gardez les ressources critiques sur l’hôte principal derrière le CDN et réservez l’hôte distinct aux gros fichiers non critiques.

Mythe : « Une page d’erreur avec un statut 200 reste sans danger puisque le site répond. » Pourquoi c’est faux : Google la traite comme erreur souple et peut supprimer l’URL ou dédupliquer toutes les pages identiques. À faire : utilisez 503/429 pour les blocages temporaires, jamais une erreur 200.

Mythe : « Les CDN concernent seulement le développement et l’exploitation. » Pourquoi c’est faux : leurs erreurs provoquent blocages, contenu absent de l’index et régressions de performance. À faire : considérez chaque modification comme pertinente pour le SEO et revérifiez robots, URL canoniques et HTTPS.

Vérifier ce qu’un robot reçoit réellement à travers le CDN

Envoyez une requête comme Googlebot et comparez-la à une requête de navigateur. Un défi ou un blocage modifiera le statut, le corps ou la redirection.

macOS / Linux

# Fetch as Googlebot — watch the status line and headers
curl -sSI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/some-page/

# Compare against a normal browser UA
curl -sSI -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \
  https://example.com/some-page/

Windows / PowerShell

$gb = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://example.com/some-page/" -UserAgent $gb -Method Head |
  Select-Object StatusCode, Headers

Un 403, une page de défi ou une réponse 200 anormalement courte servie uniquement à l’agent robot signale une interférence du WAF ou de la gestion des robots.

Vérifier qu’un robot est réellement Googlebot avant de l’autoriser ou le bloquer

Ne faites jamais confiance au seul user-agent, facile à imiter. Effectuez une résolution DNS inverse puis directe.

macOS / Linux

# Reverse-DNS the IP from your logs — should end in googlebot.com or google.com
host 66.249.66.1
# Forward-DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Si le résultat inverse ne se termine pas par un domaine Google ou si le résultat direct ne retrouve pas l’IP initiale, ce n’est pas Googlebot. Comparez aussi les plages googlebot.json et la liste IP de Bingbot.

Repérer le contenu mixte inscrit dans le CDN avec la console DevTools

Collez le script dans la console Chrome DevTools afin de lister les fichiers chargés en HTTP, symptôme fréquent de « Flexible SSL » :

[...document.querySelectorAll('[src],[href]')]
  .map(el => el.src || el.href)
  .filter(u => u && u.startsWith('http://'))
  .forEach(u => console.warn('Insecure:', u));

Chaque résultat indique une requête HTTP susceptible de provoquer un avertissement de contenu mixte derrière le CDN HTTPS.

Contrôle mensuel de l’accès des robots au CDN

1. Échantillonnez les modèles critiques. Choisissez au moins une URL d’accueil, de catégorie, d’article et de conversion ; testez deux régions ou PoP et les états hit, miss et stale lorsque possible. Terminé lorsque chaque ensemble de règles de cache ou WAF est couvert.
2. Inspectez chaque URL comme Google. Lancez le test en direct d’Inspection d’URL et examinez le rendu. Terminé lorsque Google reçoit la page, pas un défi.
3. Contrôlez les événements WAF. Filtrez les blocages mensuels des robots vérifiés avec les plages Googlebot et Bingbot. Aucun robot légitime ne doit rester bloqué.
4. Comparez les en-têtes périphériques. Vérifiez statut, URL canonique, Cache-Control, HTTPS, HSTS et CSP après la périphérie.
5. Consignez exceptions et responsables. Notez règle, motif d’URL, correction, responsable et prochaine date de revue.

Googlebot reçoit soudain un défi CDN

1. Confirmez dans Inspection d’URL. Si le rendu est normal, recherchez une région ou un motif précis ; sinon, poursuivez.
2. Identifiez la réponse périphérique. Un 403, délai, défi ou faux 200 pointe vers le WAF. Si l’origine répond pareil, transmettez au responsable de l’origine.
3. Rendez l’échec récupérable. Utilisez 503 ou 429 pendant le diagnostic, jamais un délai ni une page de défi 200.
4. Vérifiez le robot. Confirmez l’IP par DNS inverse/direct ou avec les plages officielles avant de modifier une liste.
5. Réduisez la portée du changement. Supprimez le blocage fautif ou exemptez le robot vérifié, puis répétez Inspection d’URL et surveillez les événements.
6. Prévenez la récidive. Documentez la règle et ajoutez-la au contrôle mensuel.

Google voit un défi plutôt que la page

Symptôme : Inspection d’URL rend un interstitiel, une page blanche ou un message WAF. Cause probable : vérification de robot ou blocage automatique au CDN. Correction : vérifiez le robot, ajustez la règle WAF et renvoyez 503 tant que le blocage est temporaire. Confirmez par une nouvelle inspection.

Les URL canoniques diffèrent après le déploiement

Symptôme : la réponse périphérique omet ou modifie l’URL canonique de l’origine. Cause probable : transformation HTML, réécriture d’en-tête ou document obsolète en cache. Correction : purgez la clé, supprimez la réécriture et comparez de nouveau origine et réponse publique.

HTTPS fonctionne, mais du contenu mixte apparaît

Symptôme : le navigateur signale des fichiers non sécurisés malgré une URL HTTPS. Cause probable : liaison HTTP vers l’origine ou réécriture des URL de fichiers. Correction : imposez HTTPS sur les deux segments, corrigez les URL, purgez et relancez le test Console.

Un gros lancement surcharge l’origine

Symptôme : latence ou erreurs augmentent pendant la découverte des nouvelles URL. Cause probable : chaque cache froid exige une réponse d’origine. Correction : rétablissez la capacité, utilisez des statuts temporaires récupérables si nécessaire et planifiez le réchauffement lors des prochains lancements.

Blocage temporaire : mauvaise réponse ou réponse récupérable

HTTP/2 200
content-type: text/html

<h1>Verify you are human</h1>

Le 200 masque l’échec et peut faire ressembler de nombreuses URL à des pages de défi dupliquées. Un blocage temporaire doit s’identifier :

HTTP/2 503
retry-after: 300
content-type: text/html

Clé de cache : doublons accidentels ou réponse canonique unique

Une clé qui varie le HTML selon des paramètres de suivi inutiles peut créer des objets distincts pour /product?utm_source=a et /product?utm_source=b. Une configuration plus propre ignore ces paramètres pour le cache et conserve la même URL canonique. La syntaxe exacte dépend du CDN.

Outils d’audit du comportement CDN

• Inspection d’URL de Google Search Console — testez en direct et examinez le rendu pour repérer défis, pages blanches et erreurs périphériques.
• Plages IP Googlebot — validez une source avec googlebot.json avant de modifier le WAF.
• Verify Bingbot — confirmez Bingbot avec l’outil officiel.
• curl ou Invoke-WebRequest dans PowerShell — comparez statuts et en-têtes pour navigateur, robot et origine lorsque l’accès direct est sûr.
• Chrome DevTools — contrôlez les en-têtes de statut et de cache dans Network, puis le contenu mixte dans Console.

Prouver qu’une modification du CDN est sûre pour la recherche

Test d’accès des robots

Test : lancez Inspection d’URL en direct sur chaque modèle modifié. Résultat attendu : la capture contient la vraie page avec le statut prévu. Échec : WAF, défi ou règle périphérique intercepte Google. Fenêtre : immédiatement puis après propagation. Retour arrière : Google reçoit défi, blanc ou blocage dur.

Test de parité des en-têtes périphériques

Test : comparez statut public et d’origine, URL canonique, Cache-Control et en-têtes de sécurité. Résultat attendu : signaux identiques après les transformations autorisées. Échec : réécriture ou cache obsolète. Fenêtre : après déploiement et purge. Retour arrière : divergence du statut, de HTTPS ou de l’URL canonique.

Test de performance du cache chaud

Test : demandez deux fois la même URL et comparez l’en-tête de cache et le TTFB. Résultat attendu : la seconde réponse admissible vient du cache sans ralentissement. Échec : réponse non cachable, clé variable ou périphérie contournée. Fenêtre : après propagation. Retour arrière : hausse des erreurs ou dégradation durable du TTFB.

Vérification par région et état de cache

Test : comparez rendu et en-têtes d’une même URL dans plusieurs régions ou PoP et états hit, miss et stale, avec agent normal et robot vérifié, y compris les variantes personnalisées. Résultat attendu : statut, URL canonique, directives robots et contenu conformes dans chaque dimension, sauf différence régionale volontaire et documentée. Échec : dérive de clé, Vary ou configuration périphérique. Fenêtre : immédiatement puis au premier cycle de journaux. Retour arrière : toute différence involontaire visible par le robot.

Indicateurs importants de santé du CDN

Taux de hit du cache périphérique

Indicateur : requêtes admissibles servies depuis la périphérie. Interprétation : mesure la décharge réelle des requêtes répétées. Méthode : analytics CDN segmentés par type cachable. Référence : établissez une base par modèle et classe de fichier ; HTML personnalisé et fichiers immuables ont des objectifs distincts. Fréquence : hebdomadaire et après changement des règles.

Taux d’erreur et TTFB de l’origine

Indicateur : taux 5xx et temps de réponse de l’origine lors des miss. Interprétation : montre si caches froids ou pics dépassent la capacité. Méthode : analytics CDN et journaux serveur. Référence : plage normale propre au site par classe d’URL ; examinez toute régression durable. Fréquence : alertes continues et revue hebdomadaire.

Blocages de robots vérifiés

Indicateur : requêtes Googlebot et Bingbot confirmées bloquées par le WAF. Interprétation : révèle l’exclusion de robots utiles. Méthode : événements validés avec les plages officielles ou le DNS. Référence : zéro blocage involontaire. Fréquence : alerte immédiate et revue mensuelle.

Testez vos connaissances : CDN et SEO

Cinq questions rapides sur les effets d’un CDN sur l’exploration, la vitesse et l’indexation.

Ressources à consulter

Mes articles connexes

• Google PageSpeed Insights pour les référenceurs et développeurs — un CDN est l’un des principaux leviers contre un mauvais score PageSpeed ou Core Web Vitals.
• Guide du débutant sur le SEO technique — place des performances et de l’exploration.

Mes conférences

• SMX Advanced 2018 : Solving Complex SEO Problems (SlideShare) — couches logiques, dont la périphérie CDN, et surprises d’exploration ou de redirection.
• Affiner le SEO technique, la vitesse des pages et la sécurité (Marketing Speak, épisode 109) — SEO technique, vitesse et sécurité.

Sources officielles

• Google — Décembre de l’exploration : CDN et exploration et Fonctionnement et raisons de l’exploration Googlebot.
• Bing — Verify Bingbot et l’outil Verify Bingbot.

Dans le secteur

• Un CDN peut-il améliorer le SEO ? (DebugBear) — configuration pratique liée aux Core Web Vitals.
• Liste de contrôle SEO technique (DebugBear) — place des performances CDN dans un audit.
• Meilleur SEO pour votre CDN (KeyCDN) — avis du fournisseur sur les en-têtes canoniques et robots.txt.
• Effets des CDN sur le SEO (Search Engine Journal) — vue générale antérieure aux consignes Google de décembre 2024.
• Publication de la liste des IP Bingbot (Search Engine Land) — parallèle Bing aux plages Google.
• Toutes les IP Bingbot dans un fichier JSON (Search Engine Roundtable) — autre couverture de la même liste.

Journal des modifications