Un CDN change-t-il quelque chose au référencement, mesures à l'appui

La proposition revient dans presque toutes les discussions techniques : installer un réseau de diffusion améliorerait le référencement. L'argument tient en une phrase, il est présenté comme évident, et il mélange plusieurs affirmations dont certaines sont vraies et d'autres pas. Un réseau de diffusion accélère effectivement le service des fichiers, ce qui touche des signaux pris en compte par les moteurs. Il n'améliore en revanche ni la pertinence des contenus, ni la structure du site, ni la qualité du maillage, qui pèsent bien davantage. Il peut même, mal configuré, dégrader l'exploration du site. Nous détaillons ici ce que les mesures montrent réellement, poste par poste, en séparant les gains attribuables au réseau de ceux qui relèvent d'un simple cache correctement configuré. Cette distinction évite de payer un abonnement pour un résultat qu'une demi journée de réglage aurait produit.

Ce qu'un réseau de diffusion fait réellement

Le principe est simple et il vaut la peine d'être rappelé avant d'examiner ses effets. Son fonctionnement détaillé est présenté dans notre article sur la définition d'un CDN et son fonctionnement.

Rapprocher les fichiers du visiteur

Les fichiers statiques du site sont copiés sur des serveurs répartis géographiquement, et le visiteur est servi depuis le plus proche. Le gain porte sur le temps de trajet des données, qui dépend de la distance physique. Pour un visiteur situé à quelques centaines de kilomètres du serveur d'origine, ce gain se compte en quelques dizaines de millisecondes. Pour un visiteur situé sur un autre continent, il peut atteindre plusieurs centaines. L'ampleur du bénéfice dépend donc entièrement de la répartition géographique de l'audience. Sur un site dont les visiteurs sont tous français et le serveur en France, ce gain est modeste, de l'ordre de vingt à cinquante millisecondes. Il devient significatif dès qu'une part notable de l'audience se trouve outre-mer ou à l'étranger, situation plus fréquente qu'on ne le croit sur les sites professionnels.

Absorber les pics de trafic

Le réseau sert les fichiers à la place du serveur d'origine, qui ne traite plus qu'une fraction des requêtes. Un pic de fréquentation qui aurait saturé le serveur passe alors sans difficulté. Ce bénéfice est réel et il ne relève pas du référencement au sens strict. Il évite en revanche les indisponibilités, qui pénalisent effectivement un site lorsqu'elles se prolongent. Sur un site sujet à des pics, cette protection constitue souvent la meilleure raison d'installer un réseau. Elle se justifie indépendamment de toute considération de positionnement. Une campagne de communication, une mention dans la presse ou une publication virale produisent des afflux qu'un hébergement mutualisé ne supporte pas. Le coût d'une indisponibilité pendant ces quelques heures dépasse largement celui de l'abonnement annuel.

Mettre en cache les pages complètes

Certains services vont plus loin et conservent les pages produites, pas seulement les fichiers statiques. Le temps de réponse tombe alors à quelques millisecondes pour la quasi totalité des visiteurs. Ce mode de fonctionnement produit le gain le plus important et il demande une configuration attentive. Il pose la question des pages personnalisées, qui ne doivent jamais être mises en cache. Sur un site de contenu, il transforme les mesures de performance. Sur un site marchand connecté, il exige des règles d'exclusion précises et testées. Les pages concernées se recensent facilement : tout ce qui affiche un nom, un panier, un prix négocié ou un état de connexion. La règle générale consiste à ne mettre en cache que ce qui est identique pour tous les visiteurs anonymes.

Optimiser les protocoles

Les réseaux de diffusion prennent en charge les versions récentes des protocoles de transport, souvent avant l'hébergement d'origine. Ils gèrent également la compression et la négociation des formats d'image. Ces optimisations, prises isolément, sont modestes et leur cumul produit un effet mesurable. Elles peuvent la plupart du temps être obtenues directement sur le serveur d'origine, avec un peu de travail. Le réseau les apporte sans configuration, ce qui constitue son intérêt pratique. Il ne s'agit pas d'un avantage exclusif. Sur un serveur dédié correctement administré, ces mêmes optimisations s'obtiennent en quelques heures de configuration. Sur un hébergement mutualisé où l'on ne maîtrise rien, le réseau devient en revanche le seul moyen d'y accéder.

Filtrer le trafic indésirable

La plupart des services intègrent une protection contre les attaques et un filtrage des robots. Ce filtrage soulage le serveur d'origine, qui traite parfois plus de requêtes automatisées que de visiteurs réels. Il présente aussi un risque, sur lequel nous revenons plus loin : bloquer par erreur les robots des moteurs de recherche. Cette fonction demande donc une vérification explicite après installation. Elle est activée par défaut chez la plupart des fournisseurs. C'est le principal point de vigilance de toute mise en place. Le filtrage repose sur des signatures et sur des comportements, et un explorateur légitime peut ressembler à un robot indésirable. Les fournisseurs proposent des listes d'exception pour les moteurs connus, à condition de les activer.

Ce qu'il ne fait pas

Un réseau de diffusion ne modifie ni les contenus, ni les titres, ni la structure des adresses, ni le maillage interne. Il n'améliore pas la pertinence d'une page pour une requête donnée. Il ne compense pas une architecture confuse ni un contenu insuffisant. Présenter son installation comme une action de référencement revient donc à en surestimer largement la portée. Elle relève de l'infrastructure et elle touche indirectement quelques signaux. Cette distinction devrait figurer dans toute proposition commerciale sérieuse. Un prestataire qui présente l'installation d'un réseau comme une prestation de référencement mélange deux métiers. La confusion n'est pas toujours intentionnelle et elle conduit systématiquement à des attentes déçues.

Les effets mesurables sur les signaux de référencement

Trois signaux sont réellement concernés, avec des ampleurs très différentes.

Le temps de réponse du serveur

Ce délai, mesuré entre la requête et le premier octet de réponse, constitue un signal suivi par les outils de mesure. Sans cache de pages, le réseau ne l'améliore pas puisque la page doit toujours être produite par le serveur d'origine. Avec cache de pages, il tombe de plusieurs centaines de millisecondes à quelques dizaines. C'est de loin le gain le plus important attribuable au réseau. Il conditionne d'ailleurs l'ensemble des autres mesures, puisque rien ne commence avant cette réponse. Sa mesure avant et après installation chiffre l'essentiel du bénéfice. Il faut prendre soin de mesurer depuis plusieurs villes et à plusieurs moments, un relevé unique étant trop sensible aux aléas du réseau. Une centaine de mesures réparties sur vingt-quatre heures donne une base fiable.

L'affichage du contenu principal

Cette mesure dépend du temps de réponse, du chargement des ressources critiques et du travail du navigateur. Un réseau améliore les deux premiers postes et ne touche pas au troisième. Le gain observé se situe couramment entre dix et trente pour cent sur un site non optimisé, et il devient marginal sur un site déjà bien réglé. Cette observation est importante : le réseau ne remplace pas le travail d'optimisation, il le complète. Installer un réseau sur un site aux images non compressées produit un gain décevant. L'ordre des chantiers compte davantage que le choix des outils. Compresser les images, différer les scripts tiers et corriger les déclarations de taille produisent des gains supérieurs pour un coût nul. Le réseau vient ensuite, une fois ces fondamentaux traités, et son apport devient alors clairement identifiable.

La stabilité visuelle et la réactivité

Ces deux mesures dépendent du code de la page et de son exécution dans le navigateur, sur lesquels le réseau n'a aucune prise. Un site instable visuellement le reste après installation. Un site lourd en scripts tiers conserve exactement la même réactivité. Ces deux signaux figurent pourtant dans les mêmes rapports que le précédent, ce qui entretient la confusion. Le détail de ce que recouvre chacun est présenté dans notre article sur les Core Web Vitals de Google. Attendre du réseau une amélioration sur ces postes conduit à une déception. Le seul cas où un effet indirect existe tient à la vitesse d'arrivée des ressources, qui peut légèrement avancer le moment où les décalages se produisent. Cet effet ne change pas l'ampleur du décalage, seulement son instant.

Le budget d'exploration

Un serveur qui répond plus vite permet aux robots de parcourir davantage de pages dans le même temps. Cet effet est documenté et il concerne principalement les sites volumineux, où l'exploration constitue une contrainte réelle. Les mécanismes en jeu sont détaillés dans notre article sur le budget de crawl de Google. Sur un site de deux cents pages, ce facteur n'a aucune importance pratique. Sur un catalogue de cent mille adresses, il devient significatif. La taille du site détermine donc entièrement la pertinence de cet argument. Sur les gros catalogues, l'effet se mesure dans le rapport d'exploration du moteur, où le nombre de pages parcourues par jour augmente après amélioration du temps de réponse. Ce chiffre constitue la seule preuve exploitable de l'effet.

La disponibilité

Un site fréquemment indisponible perd des positions, les moteurs réduisant leur fréquence de passage puis retirant les pages qui ne répondent plus. Un réseau améliore nettement la disponibilité en servant une version conservée lorsque l'origine ne répond pas. Cette fonction, souvent optionnelle, mérite d'être activée. Elle constitue un bénéfice réel et rarement mis en avant. Elle intervient exactement au moment où le site en a le plus besoin. Sur un hébergement mutualisé fragile, elle change la donne. Elle a toutefois une limite : la version servie pendant l'incident est celle qui était en cache, donc potentiellement périmée. Sur un site marchand, mieux vaut afficher une page d'information qu'un prix ou un stock obsolète.

La localisation du serveur

L'idée que la position géographique du serveur influence le classement local est ancienne et largement dépassée. Les moteurs s'appuient sur l'extension du domaine, la langue et les signaux locaux, pas sur l'adresse du serveur. Un réseau de diffusion, dont les serveurs sont partout, ne pose donc aucun problème de ce point de vue. Cette inquiétude revient régulièrement et elle n'a plus lieu d'être. Elle mérite d'être écartée explicitement lors des discussions. Elle bloque parfois des projets sans raison. La seule précaution utile consiste à conserver une extension de domaine cohérente avec le marché visé et à déclarer correctement la langue des pages. Ces deux éléments pèsent réellement, contrairement à la position physique des machines.

Les configurations qui peuvent nuire

Un réseau mal configuré produit des problèmes qui n'existaient pas avant son installation, et certains sont difficiles à diagnostiquer.

Le blocage des robots légitimes

Les protections anti-robots peuvent bloquer les explorateurs des moteurs, notamment lorsqu'ils passent par des adresses inhabituelles. Le symptôme est une chute d'exploration visible dans les outils du moteur, avec des erreurs de récupération. La vérification consiste à examiner les règles de sécurité et à tester la récupération d'une page depuis l'outil du moteur. Ce contrôle doit être fait dans les jours suivant l'installation, pas six mois plus tard. Il constitue la vérification la plus importante de toute mise en place. Son omission a déjà coûté cher à de nombreux sites. Le délai avant qu'un blocage ne se traduise par une perte de position se compte en semaines, ce qui laisse le temps de corriger à condition de surveiller. Passé ce délai, la récupération demande plusieurs mois.

Les défis d'interaction imposés

Certaines protections affichent une page intermédiaire demandant une vérification avant d'accéder au site. Un robot d'exploration ne franchit pas cette étape et reçoit donc une page vide de contenu. Si cette protection s'active sur une partie du trafic, une partie des pages est explorée dans cet état. Le réglage doit exclure explicitement les explorateurs identifiés. Ce point est documenté par tous les fournisseurs sérieux et il est souvent laissé à sa valeur par défaut. Un test avec un outil simulant un robot révèle immédiatement le problème. L'outil d'inspection d'adresse du moteur constitue la référence, puisqu'il montre exactement ce que le robot reçoit. Une page vide ou une page de vérification affichée dans cet outil signale un blocage à traiter d'urgence.

Le cache de pages personnalisées

Mettre en cache une page contenant des informations propres à un utilisateur conduit à servir ces informations à d'autres visiteurs. Le risque est majeur sur un site marchand, où un panier ou une adresse peuvent fuiter. Les règles d'exclusion doivent couvrir le panier, le compte, le tunnel de commande et toute page affichant un état de connexion. Cette configuration demande une attention réelle et un test avec deux navigateurs distincts. Elle constitue le principal risque fonctionnel d'une mise en place. Elle mérite une recette formelle avant mise en production. Le test consiste à ouvrir une session connectée dans un navigateur, une session anonyme dans un autre, et à vérifier qu'aucune information ne fuit de l'une vers l'autre. Ce contrôle prend cinq minutes et il évite un incident majeur.

La duplication d'adresses

Une mauvaise configuration peut rendre le site accessible à la fois par son domaine et par une adresse technique du réseau. Les deux versions deviennent alors explorables et le contenu se retrouve dupliqué. La parade consiste à n'autoriser l'accès qu'au domaine principal et à déclarer les adresses canoniques. Ce contrôle se fait en tentant d'accéder au site par l'adresse technique. Il révèle un problème dans une proportion non négligeable des installations. Sa correction est simple une fois le problème identifié. Elle consiste à refuser les requêtes dont l'en-tête d'hôte ne correspond pas au domaine attendu, réglage disponible chez tous les fournisseurs. Une redirection permanente vers le domaine principal produit le même résultat.

La purge du cache après publication

Un nouveau contenu publié doit apparaître rapidement, ce qui suppose que le cache du réseau soit vidé pour les pages concernées. Sans mécanisme de purge, un article peut rester invisible plusieurs heures. Sur un site publiant régulièrement, ce décalage nuit à la fraîcheur perçue et retarde l'indexation. Les extensions dédiées déclenchent cette purge automatiquement à chaque publication. Vérifier qu'elle fonctionne réellement fait partie de la mise en place. Le contrôle consiste à publier une modification et à mesurer le délai d'apparition, depuis une session anonyme et non depuis le navigateur de l'administrateur. Ce dernier reçoit souvent une version non mise en cache, ce qui masque entièrement le problème.

Les redirections en double

Le réseau peut appliquer ses propres redirections en plus de celles du serveur d'origine, produisant des chaînes de deux ou trois étapes. Chaque étape ajoute un aller-retour et dilue le signal transmis. La vérification se fait avec un outil affichant la chaîne complète pour les quatre combinaisons d'adresse possibles. Cette anomalie est fréquente et facile à corriger. Elle passe inaperçue sans contrôle explicite. Elle mérite une place dans la liste de vérification post-installation.

Décider et mesurer

La question n'est pas de savoir si un réseau est utile dans l'absolu mais s'il l'est pour un site donné, ce qui se tranche avec quelques chiffres.

Relever la répartition géographique

Si quatre-vingt-quinze pour cent des visiteurs sont français et le serveur en France, le gain de proximité est faible. Si une part significative du trafic vient d'autres continents, il devient déterminant. Cette information se lit en deux minutes dans l'outil de mesure d'audience. Elle constitue le premier critère de décision et elle est rarement consultée. Elle oriente également le choix du fournisseur, tous ne disposant pas des mêmes points de présence. Un service concentré sur l'Amérique du Nord apporte peu à un site européen.

Mesurer le temps de réponse actuel

Le délai avant le premier octet, mesuré depuis plusieurs villes, indique la marge de progression disponible. Une valeur inférieure à deux cents millisecondes laisse peu d'espace au gain. Une valeur supérieure à six cents signale un problème que le cache de pages résoudrait spectaculairement. Cette mesure prend cinq minutes avec un outil en ligne gratuit. Elle doit être répétée à plusieurs moments de la journée. Elle constitue la base de la comparaison ultérieure.

Vérifier si un cache local suffirait

Sur beaucoup de sites, l'absence de cache de pages sur le serveur d'origine explique l'essentiel de la lenteur. Installer ce cache coûte quelques heures et produit un gain comparable à celui d'un réseau, sans abonnement ni complexité. La question à se poser est donc : le site dispose-t-il déjà d'un cache de pages efficace. Une réponse négative impose de traiter ce point avant d'envisager autre chose. Cette étape est régulièrement sautée au profit d'une solution externe. Elle produit pourtant le meilleur rapport entre effort et résultat.

Comparer avant et après

La mesure doit porter sur les mêmes pages, depuis les mêmes points, avant et après la bascule. Trois indicateurs suffisent : temps de réponse, affichage du contenu principal et taux de disponibilité. Les relever sur une semaine avant et une semaine après donne une comparaison solide. Les données de terrain confirmeront avec quelques semaines de décalage. Documenter ces valeurs permet d'évaluer le retour sur l'abonnement. Cette évaluation est rarement faite et elle devrait l'être systématiquement.

Surveiller l'exploration

Le nombre de pages explorées par jour, visible dans les outils du moteur, doit rester stable ou augmenter après installation. Une chute signale un blocage et impose une intervention immédiate. Cette surveillance doit être quotidienne pendant les deux premières semaines. Elle constitue le filet de sécurité qui évite les incidents durables. Une alerte automatique sur ce chiffre serait idéale et elle demande un peu de développement. Un contrôle manuel suffit sur la période critique.

Réévaluer périodiquement

Les besoins évoluent, l'audience change, l'hébergement d'origine peut être amélioré. Un réseau installé il y a trois ans peut être devenu superflu ou insuffisant. Une revue annuelle, avec les mêmes mesures qu'à l'installation, permet d'ajuster. Elle peut conduire à changer de fournisseur, à activer des fonctions non utilisées ou à supprimer un abonnement inutile. Cette revue prend une heure et elle évite de payer pour un service qui n'apporte plus rien. Elle s'inscrit naturellement dans la revue des outils du site.