Dynamic Serving : fonctionnement, risques et audit

En bref — Le dynamic serving consiste à utiliser une seule adresse Web tout en envoyant une page différente aux téléphones et aux ordinateurs : le serveur identifie le type d’appareil et renvoie un HTML différent. Cette méthode fonctionne, mais Google préfère le responsive design (une page unique dont la mise en page s’adapte simplement à l’écran), car le dynamic serving est facile à mal configurer. Si vous l’utilisez, le serveur doit envoyer l’en-tête spécial Vary: User-Agent afin que les caches ne remettent pas la mauvaise version à la mauvaise personne.

Qu’est-ce que le dynamic serving ?

Un site peut gérer les visiteurs mobiles de trois façons :

1. Responsive design — une page, un seul HTML, et une mise en page qui s’adapte à la taille de l’écran. C’est la solution recommandée par Google.
2. Dynamic serving — une adresse Web unique, mais le serveur envoie un HTML différent aux téléphones et aux ordinateurs. Même URL, page différente en dessous.
3. URL distinctes — un site mobile entièrement séparé, à sa propre adresse, comme m.example.com.

Le dynamic serving est l’option intermédiaire. Lorsqu’un navigateur demande une page, il indique au serveur ce qu’il est — téléphone, tablette ou ordinateur — au moyen de ce qu’on appelle le user-agent. Le serveur lit cette information et choisit la version de la page à renvoyer. Deux personnes peuvent donc saisir exactement la même URL, l’une sur téléphone et l’autre sur ordinateur portable, et recevoir des HTML réellement différents.

L’en-tête Vary: User-Agent

Voilà le piège. La page change selon l’appareil, mais pas l’URL. Tout système qui met les pages en cache — navigateur, CDN ou fournisseur d’accès — peut donc enregistrer par erreur la version pour ordinateur et la remettre ensuite à une personne sur téléphone. Pour l’éviter, le serveur doit joindre une indication à chaque réponse : Vary: User-Agent. Elle signifie que « le contenu de cette page dépend de l’appareil ; il ne faut donc pas réutiliser une copie mise en cache pour un autre type d’appareil ». Oubliez cet en-tête et les internautes, comme Google, risquent de voir la mauvaise version.

Pourquoi Google le déconseille

Le dynamic serving suppose que le serveur déduise correctement l’appareil à partir du user-agent, et cette détection est réellement difficile à maintenir. De nouveaux appareils apparaissent, des tablettes sont prises pour des téléphones, et les versions pour ordinateur et mobile peuvent facilement diverger sans bruit. Google risque alors de voir une version erronée ou défectueuse de la page. Son conseil est donc simple : utilisez plutôt le responsive design, avec une seule version qui ne peut pas se désynchroniser.

L’erreur la plus courante

Ne confondez pas dynamic serving et « dynamic rendering ». Les deux termes se ressemblent et les deux techniques impliquent que le serveur examine le user-agent, mais elles répondent à des problèmes différents. Le dynamic serving fournit un HTML différent aux téléphones et aux ordinateurs. Le dynamic rendering fournit aux robots des moteurs de recherche une version prérendue d’une page très dépendante de JavaScript. Ce sont deux notions et deux documentations Google distinctes ; la différence est détaillée dans l’onglet Avancé.

En 2026, le dynamic serving est surtout une configuration dont vous héritez sur un ancien site ou un grand site d’entreprise, pas une solution que l’on recommande de construire aujourd’hui. Pour la version complète — les deux fonctions de l’en-tête Vary, le coût CDN ignoré par la plupart des guides, la question du cloaking et la méthode de détection — passez à l’onglet Avancé.

En bref — Dynamic serving = même URL, HTML/CSS différent selon le user-agent, avec détection côté serveur et signalement par l’en-tête de réponse Vary: User-Agent. C’est l’une des trois configurations mobiles, avec le responsive design (recommandé par Google) et les URL distinctes (m-dot). L’en-tête Vary remplit deux fonctions : (1) empêcher les caches de servir la version du mauvais appareil et (2) historiquement, aider Googlebot à découvrir la version mobile. Il a cependant un coût réel : Vary: User-Agent fragmente les clés du cache CDN pour chaque chaîne de user-agent distincte et multiplie la charge à l’origine. La détection est sujette aux erreurs (listes obsolètes, tablettes prises pour des téléphones), et une détection défectueuse ou l’absence de Vary peut présenter à Google une version erronée ou cassée : c’est là que se situe le véritable risque de cloaking. Ne le confondez pas avec le dynamic rendering (pré-rendu du JavaScript pour les robots, notion distincte avec sa propre documentation). En 2026, c’est une configuration historique dont il faut sortir lors d’un audit, pas une architecture à adopter pour un nouveau site.

Définition précise du dynamic serving

Voici la définition donnée par Google dans ses bonnes pratiques sur l’indexation mobile-first : “Dynamic serving: Uses the same URL regardless of device. This configuration relies on user-agent sniffing and the Vary: user-agent HTTP response header to serve a different version of the HTML to different devices.” (traduction) « Dynamic serving : utilise la même URL quel que soit l’appareil. Cette configuration s’appuie sur la détection du user-agent et sur l’en-tête de réponse HTTP Vary: user-agent pour servir une version différente du HTML selon l’appareil. » L’ancienne page dédiée de Google le formulait encore plus concrètement : “a setup where the server responds with different HTML (and CSS) on the same URL depending on which user agent requests the page (mobile, tablet, or desktop).” (traduction) « une configuration dans laquelle le serveur répond avec un HTML — et un CSS — différent sur la même URL selon le user-agent qui demande la page : mobile, tablette ou ordinateur ».

C’est l’une des trois configurations mobiles. Un tableau en trois lignes permet de les distinguer clairement :

Deux de ces trois configurations dépendent de l’en-tête Vary. Google précise que les URL distinctes, “like dynamic serving, this configuration relies on the user-agent and Vary HTTP headers.” (traduction) « comme le dynamic serving, cette configuration s’appuie sur le user-agent et les en-têtes HTTP Vary ». Seul le responsive design ne comporte aucun élément susceptible de se désynchroniser, ce qui explique précisément pourquoi Google le recommande (voir le guide sur le responsive design et la place de ces trois méthodes dans le hub SEO mobile).

Fonctionnement : détection du user-agent et en-tête Vary

Le serveur examine la chaîne du user-agent entrant — l’identifiant envoyé par chaque client —, détermine s’il s’agit d’un téléphone, d’une tablette ou d’un ordinateur, puis renvoie le HTML correspondant. Comme l’URL est identique pour tout le monde, il doit ensuite annoncer que la réponse varie selon le user-agent. C’est le rôle de l’en-tête Vary: User-Agent. Les anciennes consignes de Google précisent qu’il remplit deux fonctions distinctes, qu’il ne faut pas confondre :

Selon ces consignes, l’en-tête empêche d’abord un cache de renvoyer la version pour ordinateur à un utilisateur mobile, ou l’inverse. Il aide aussi Googlebot à repérer plus rapidement les URL qui proposent un contenu optimisé pour mobile.

La première fonction concerne donc la justesse du cache : un enjeu d’expérience utilisateur et de fiabilité, indépendant des moteurs de recherche. La seconde concerne la découverte lors du crawl. La plupart des glossaires concurrents ne mentionnent que la première, ou mélangent les deux. Dans une vraie réponse HTTP, l’en-tête ressemble à ceci :

HTTP/1.1 200 OK
Content-Type: text/html
Vary: User-Agent
Content-Length: 5710

Si votre serveur envoie déjà un en-tête Vary pour une autre raison, par exemple Accept-Encoding, ajoutez User-Agent à la liste au lieu de remplacer la valeur existante.

Cette distinction mérite d’être explicite : Vary est un mécanisme HTTP ordinaire de gestion du cache, pas une invention SEO. Il indique au cache quels en-têtes de la requête intégrer à sa clé afin de stocker la bonne variante ; il ne détecte pas les appareils et ne comprend rien au SEO. La logique de user-agent du serveur s’en charge séparément. L’utilisation de l’en-tête comme signal de découverte lors du crawl — la deuxième fonction ci-dessus — correspond à la description qu’en fait Google, et non à une exigence du protocole de cache que tous les caches appliqueraient de la même manière. Envoyez-le systématiquement pour une URL donnée, y compris dans les réponses 304 Not Modified et les réponses par défaut ou de repli, faute de quoi le cache peut conserver des métadonnées incohérentes sur ce qu’il stocke.

Le coût oublié par la plupart des guides : la fragmentation du cache CDN

Voici l’aspect que presque toutes les pages bien classées omettent. Vary: User-Agent n’est pas gratuit : il fragmente le cache. Un cache construit ses clés en partie à partir des en-têtes énumérés dans Vary. Avec Vary: User-Agent, il conserve donc une copie distincte pour chaque chaîne de user-agent rencontrée : chaque version de navigateur, chaque version de système d’exploitation et chaque robot. Cela représente des milliers de variantes pour un contenu qui ne possède en réalité que deux ou trois versions. La perte de réutilisation dépend toutefois de la gestion des clés par votre CDN : certains normalisent ou regroupent les chaînes similaires, la plupart ne le font pas. Il n’existe donc pas de baisse universelle du taux de réussite à citer. Tout multiplicateur précis, y compris celui de SiteGround ci-dessous, doit être traité comme l’estimation d’un fournisseur et non comme une garantie pour votre infrastructure.

SiteGround estime que cette fragmentation peut transformer 100 visites identiques en 5 à 30 requêtes dynamiques et multiplier d’autant la consommation de ressources. Ce chiffre décrit son propre système et ne constitue pas une règle universelle. L’effet est particulièrement fort sur les robots : “If such [a] bot starts crawling your site and you have the Vary: User-Agent header, each request it makes to your site would be a dynamic one and will eat up your resources.” (traduction) « Si un tel robot commence à explorer votre site alors que l’en-tête Vary: User-Agent est présent, chacune de ses requêtes sera dynamique et consommera vos ressources. »

Le problème n’est pas nouveau. Dès 2013, Cindy Krum avertissait dans Search Engine Land que certains CDN d’entreprise interprétaient l’en-tête comme un signal indiquant que le contenu “cannot be cached or served from the CDN and must be fetched directly from your server” (traduction) « ne peut pas être mis en cache ni servi depuis le CDN et doit être récupéré directement sur votre serveur », ce qui pouvait “rendering your CDN completely useless” (traduction) « rendre votre CDN totalement inutile » pour les pages en dynamic serving. Ce comportement propre à certains fournisseurs en 2013 a évolué, mais la tension technique demeure : Vary: User-Agent fragmente les clés du cache. C’est une raison majeure du recul de cette méthode, même chez les sites qui ne s’inquiétaient pas du SEO. SiteGround souligne aussi que “most of the sites don’t actually serve different HTML for their mobile versions. It’s the responsive CSS that does all the heavy lifting” (traduction) « la plupart des sites ne servent pas réellement un HTML différent à leur version mobile ; le responsive CSS fait tout le travail ». Beaucoup d’en-têtes Vary: User-Agent observés sont donc de simples vestiges de configuration sur des sites devenus responsives.

Le dynamic serving est-il du cloaking ?

Non, pas en soi. Le risque dépend du résultat et de l’intention, pas de la technique. Détecter un appareil et lui servir un contenu adapté est acceptable. Le danger vient soit (a) d’une erreur de détection ou de l’absence de Vary, qui sert par accident à Googlebot une version erronée ou cassée, soit (b) de la volonté de présenter aux moteurs de recherche un contenu sensiblement différent de celui vu par les internautes. Les anciennes consignes de Google sur le dynamic serving étaient très claires sur ce piège :

Les anciennes consignes demandaient de ne jamais cibler Googlebot lors de la détection. Ses user-agents doivent recevoir la même version que les appareils mobiles auxquels ils déclarent correspondre.

Le parallèle apparaît dans la documentation toujours en ligne de Google sur le dynamic rendering, qui énonce le principe général pour ce cas voisin de rendu JavaScript : “As long as your dynamic rendering produces similar content, Googlebot won’t view dynamic rendering as cloaking,” (traduction) « tant que votre dynamic rendering produit un contenu similaire, Googlebot ne le considérera pas comme du cloaking », alors que “serving completely different content to users and crawlers can be considered cloaking.” (traduction) « servir un contenu complètement différent aux internautes et aux robots peut être considéré comme du cloaking ». Le même raisonnement vaut pour le dynamic serving : un contenu substantiellement identique, adapté à chaque appareil, convient ; une mauvaise configuration qui ressemble à du cloaking constitue le vrai danger.

Dynamic serving et dynamic rendering : ne les confondez pas

C’est la distinction la plus nette que beaucoup de contenus concurrents manquent ; elle mérite donc une séparation franche :

• Dynamic serving = variation selon l’appareil. Même URL, HTML différent entre mobile et ordinateur. C’est le sujet de cette page. Google a intégré ses consignes au guide sur l’indexation mobile-first.
• Dynamic rendering = variation du rendu JavaScript pour les robots. Une version prérendue ou rendue côté serveur d’une page très dépendante de JavaScript leur est servie, tandis que les internautes reçoivent la version rendue côté client. Cette technique possède sa propre documentation Google, toujours en ligne. Bing la présente dans son article de 2018 sur bingbot : “Dynamic rendering is about detecting user agent and rendering content differently for humans and search engine crawlers” (traduction) « le dynamic rendering consiste à détecter le user-agent et à rendre le contenu différemment pour les humains et les robots des moteurs de recherche ». Attention : il est ici question du rendu JavaScript pour bingbot, pas d’un service selon l’appareil.

Les deux notions sont faciles à confondre, car elles utilisent toutes deux la détection du user-agent et soulèvent la question du cloaking. Elles répondent pourtant à des problèmes différents et relèvent de documentations distinctes.

La détection du user-agent est réellement sujette aux erreurs

Les anciennes consignes de Google énuméraient des modes d’échec toujours actuels : les listes de user-agents exigent un entretien constant et ne reconnaissent pas les agents nouvellement apparus ; les correspondances sont faciles à inverser — “sometimes detecting a desktop user agent as a mobile one or detecting a mobile user agent as a desktop” (traduction) « parfois en détectant un user-agent d’ordinateur comme mobile, ou un user-agent mobile comme celui d’un ordinateur ». Autre erreur classique : “a common mistake for sites is to inadvertently treat tablet devices as smartphones.” (traduction) « une erreur courante consiste à traiter involontairement les tablettes comme des smartphones ». Le résumé de Google — “Use the Vary HTTP header to signal your changes depending on the user agent. Detect user agent strings correctly.” (traduction) « Utilisez l’en-tête HTTP Vary pour signaler les changements selon le user-agent. Détectez correctement les chaînes de user-agent. » — paraît simple, mais condense toute la charge de maintenance en deux phrases.

Google rencontre ces erreurs depuis une décennie. En janvier 2015, Pierre Far de Google signalait les principaux problèmes d’implémentation qu’il observait : la bonne gestion des variantes JavaScript, CSS et d’images entre appareils, et pas seulement l’en-tête Vary. Un rappel que « ajouter l’en-tête » n’a jamais constitué toute la solution.

Pourquoi le responsive design est désormais la solution par défaut

Deux évolutions ont fait du dynamic serving une méthode historique. Premièrement, Google recommande le responsive design “because it’s the easiest design pattern to implement and maintain” (traduction) « parce qu’il s’agit du modèle de conception le plus facile à mettre en œuvre et à maintenir » depuis au moins 2015 : une seule version, sans aucun risque lié à la détection de l’appareil. Deuxièmement, l’indexation mobile-first s’est achevée en 2023–2024, ce qui a accru les conséquences d’une erreur de service selon l’appareil. Google explore, indexe et classe désormais principalement la version mobile. Une mauvaise configuration ne lui présente donc pas seulement une mauvaise page mobile, mais un contenu indexé principal erroné. La même incitation à abandonner les configurations propres à chaque appareil qui vaut pour les URL m-dot distinctes vaut aussi pour le dynamic serving : réunissez tout sur une URL responsive et cette catégorie de problèmes disparaît.

Pour une vue complète du mobile — parité du contenu, Core Web Vitals sur mobile, facilité d’utilisation, interstitiels et place actuelle d’AMP — consultez le hub SEO mobile et la checklist SEO mobile.

Comment vérifier si un site utilise le dynamic serving

La vérification est rapide et concrète : demandez deux fois la même URL avec des chaînes de user-agent différentes et comparez. Si le HTML diffère et que la réponse contient Vary: User-Agent, il s’agit de dynamic serving. Si le HTML est identique et que seule la mise en page s’adapte via CSS, le site est responsive. L’onglet Scripts propose les versions curl, DevTools et bookmarklet. Le signal d’alerte est un HTML qui varie selon l’appareil sans en-tête Vary : cette mauvaise configuration risque de présenter la mauvaise version aux caches et aux robots.

Résumé par l’IA

Synthèse de la version avancée :

• Dynamic serving = même URL, HTML/CSS différent selon le user-agent (ordinateur, mobile ou tablette), avec détection côté serveur et signalement par l’en-tête de réponse Vary: User-Agent.
• Une des trois configurations mobiles : responsive design (même URL et même HTML, media queries CSS — solution recommandée par Google), dynamic serving (même URL, HTML différent) et URL distinctes ou m-dot (URL et HTML différents). Deux des trois dépendent de Vary.
• L’en-tête Vary: User-Agent remplit deux fonctions : (1) empêcher les caches (navigateurs, CDN, fournisseurs d’accès) de servir à un visiteur mobile la page pour ordinateur mise en cache, ou inversement ; (2) historiquement, aider Googlebot à découvrir la version mobile. La plupart des contenus concurrents ne mentionnent que la première.
• Il a un coût réel : Vary: User-Agent fragmente les clés du cache CDN pour chaque chaîne de user-agent distincte (navigateur, système ou robot) et multiplie les requêtes à l’origine ; SiteGround estime ce facteur à 5–30×. C’est une raison importante, mais rarement évoquée, pour laquelle les sites l’ont abandonné.
• Le risque de cloaking dépend du résultat, pas de la technique. Servir un contenu adapté à l’appareil est acceptable. Le danger vient d’une erreur de détection ou de l’absence de Vary, qui donne la mauvaise version à Googlebot, ou de la volonté de servir un autre contenu aux robots. Ne traitez jamais « Googlebot » comme un cas particulier : traitez l’appareil qu’il déclare comme n’importe quel autre appareil.
• La détection du user-agent est sujette aux erreurs : listes obsolètes, ordinateurs pris pour des mobiles et tablettes prises pour des téléphones.
• Ce n’est pas du dynamic rendering (pré-rendu du JavaScript pour les robots) : il s’agit d’une autre notion, documentée séparément par Google et Bing.
• Méthode historique en 2026. Google recommande le responsive depuis environ 2015, et l’achèvement de l’indexation mobile-first en 2023–2024 a accru les risques d’une mauvaise configuration. On la rencontre surtout lors de la migration d’un site ancien ou d’entreprise vers une autre solution.
• Pour la détecter : demandez la même URL avec un user-agent pour ordinateur puis pour mobile, comparez le HTML et vérifiez l’en-tête Vary: User-Agent.

Documentation officielle

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

Google

• Bonnes pratiques pour l’indexation mobile-first — page qui contient désormais les définitions du dynamic serving et des URL distinctes (l’ancienne page dédiée y a été intégrée), ainsi que la recommandation de Google en faveur du responsive design.
• Dynamic Serving (ancienne documentation dédiée, archivée) — l’ancienne page, beaucoup plus détaillée (dernière mise à jour en janvier 2021). Elle explique les « deux fonctions de l’en-tête Vary » et les erreurs de détection du user-agent. L’URL active redirige maintenant en 301 vers le guide sur l’indexation mobile-first, qui ne reprend pas la plupart de ces précisions.
• Le dynamic rendering comme solution de contournement — notion voisine mais distincte de rendu JavaScript, avec la précision selon laquelle un contenu similaire ne constitue pas du cloaking. Cette source n’est citée ici que pour établir la différence.
• L’annonce de l’indexation mobile-first pour l’ensemble du Web (mars 2020) — contexte expliquant pourquoi le service selon l’appareil compte davantage aujourd’hui.

Bing / Microsoft

• Série bingbot : JavaScript, dynamic rendering et cloaking (octobre 2018) — consignes de Bing sur le dynamic rendering (JavaScript pour les robots), et non sur le dynamic serving selon l’appareil. Bing ne semble pas publier de documentation dédiée au dynamic serving selon l’appareil et à Vary, contrairement à ce que Google proposait historiquement ; le moteur privilégie plus largement les configurations responsives à URL unique.

Citations des sources

Déclarations publiques de Google et de professionnels du secteur. Les liens vers la documentation Google active pointent directement vers le passage cité ; les sources archivées ou relayées sont signalées.

Google — définition et recommandation (documentation active)

• “Dynamic serving: Uses the same URL regardless of device. This configuration relies on user-agent sniffing and the Vary: user-agent HTTP response header to serve a different version of the HTML to different devices.” (traduction) — Documentation Google Search Central. « Dynamic serving : utilise la même URL quel que soit l’appareil. Cette configuration s’appuie sur la détection du user-agent et sur l’en-tête de réponse HTTP Vary: user-agent pour servir une version différente du HTML selon l’appareil. » Accéder à la citation
• “Separate URLs: Serves different HTML to each device, and on separate URLs. Like dynamic serving, this configuration relies on the user-agent and Vary HTTP headers to redirect users to the device-appropriate version of the site.” (traduction) « URL distinctes : sert un HTML différent à chaque appareil, sur des URL distinctes. Comme le dynamic serving, cette configuration s’appuie sur le user-agent et les en-têtes HTTP Vary pour rediriger les utilisateurs vers la version du site adaptée à leur appareil. » Accéder à la citation
• “Google recommends Responsive Web Design because it’s the easiest design pattern to implement and maintain.” (traduction) « Google recommande le responsive web design, car il s’agit du modèle de conception le plus facile à mettre en œuvre et à maintenir. » Accéder à la citation

Google — les deux fonctions de l’en-tête Vary (ancienne documentation dédiée archivée, dernière mise à jour en janvier 2021)

• “The Vary HTTP header has two important and useful implications: It signals to caching servers used in ISPs and elsewhere that they should consider the user agent when deciding whether to serve the page from cache or not. Without the Vary HTTP header, a cache may mistakenly serve mobile users the cache of the desktop HTML page or vice versa. It helps Googlebot discover your mobile-optimized content faster.” (traduction) — Google Search Central, Dynamic Serving (archive). « L’en-tête HTTP Vary a deux implications importantes et utiles : il indique aux serveurs de cache utilisés par les fournisseurs d’accès et ailleurs qu’ils doivent tenir compte du user-agent lorsqu’ils décident de servir ou non la page depuis le cache. Sans l’en-tête HTTP Vary, un cache peut servir par erreur aux utilisateurs mobiles la copie en cache de la page HTML pour ordinateur, ou inversement. Il aide Googlebot à découvrir plus rapidement votre contenu optimisé pour mobile. »
• “Be very careful of cloaking when detecting user agents… it should not be looking specifically for Googlebot. All Googlebot user agents identify themselves as specific mobile devices, and you should treat these Googlebot user agents exactly like you would treat these devices.” (traduction) — Google Search Central, Dynamic Serving (archive). « Soyez très prudent quant au cloaking lors de la détection des user-agents… La détection ne doit pas rechercher spécifiquement Googlebot. Tous les user-agents de Googlebot s’identifient comme des appareils mobiles précis, et vous devez les traiter exactement comme ces appareils. »

Google — dynamic rendering (notion distincte) (documentation active)

• “As long as your dynamic rendering produces similar content, Googlebot won’t view dynamic rendering as cloaking.” (traduction) « Tant que votre dynamic rendering produit un contenu similaire, Googlebot ne le considérera pas comme du cloaking. » Accéder à la citation

SiteGround — le coût CDN de Vary: User-Agent (secteur)

• “With the User-Agent [header] enabled, the system will keep different copies for each combination of OS and browser version visiting your site… you will have 5-30 dynamic requests for the same 100 visits. So the very same site will use 5-30 times the resources.” (traduction) « Lorsque l’en-tête User-Agent est activé, le système conserve des copies différentes pour chaque combinaison de système d’exploitation et de version de navigateur qui visite le site… Vous aurez 5 à 30 requêtes dynamiques pour 100 visites identiques. Le même site utilisera donc 5 à 30 fois plus de ressources. » — SiteGround, « Pourquoi l’en-tête HTTP Vary peut poser problème »

Quelle configuration mobile choisir ?

Dans presque tous les cas, vous devriez aboutir au responsive design. Cet arbre parcourt néanmoins la décision réelle, y compris les situations où le dynamic serving ou les URL distinctes sont envisagés, et indique quoi faire lorsque vous en avez hérité.

En bref : le responsive est la bonne réponse dans presque tous les cas. Le dynamic serving et le m-dot sont des configurations qu’il faut faire disparaître progressivement des sites qui les utilisent déjà, pas des modèles à retenir pour un nouveau projet.

Checklist d’audit du dynamic serving

• Demandez la même URL avec des user-agents représentatifs d’un ordinateur et d’un mobile, puis confirmez si le HTML diffère intentionnellement.
• Envoyez Vary: User-Agent sur chaque réponse dont la représentation varie selon la catégorie d’appareil, y compris les réponses en cache et les erreurs lorsque cela s’applique.
• Maintenez l’équivalence entre les versions pour le contenu principal, les titres, les liens internes, les images et textes alternatifs, les métadonnées, les directives robots et les données structurées.
• Vérifiez que Googlebot Smartphone reçoit la même représentation mobile qu’un navigateur mobile ordinaire ; ne traitez jamais le robot comme un cas spécial.
• Contrôlez les clés et le comportement du cache CDN afin qu’une catégorie d’appareil ne reçoive pas le document mis en cache d’une autre.
• Répétez chaque requête plusieurs fois à travers le CDN ou la couche de cache, pas seulement à l’origine, avec des user-agents d’ordinateur, mobile, tablette et robot. Un empoisonnement du cache n’apparaît qu’après le préchauffage et une nouvelle demande de la variante, pas lors de la première récupération.
• Incluez dans la matrice de repli les tablettes, les user-agents inconnus et les requêtes sans en-tête user-agent.
• Supprimez Vary: User-Agent lorsque le site est réellement devenu responsive et que la réponse ne varie plus.
• Documentez un chemin de migration vers le responsive design lorsque le dynamic serving est un héritage plutôt qu’une exigence.

Dynamic serving — aide-mémoire

Définition : même URL, HTML/CSS différent selon le user-agent, signalé par Vary: User-Agent.

Les trois configurations mobiles

L’en-tête Vary: User-Agent — deux fonctions

1. Justesse du cache — empêche les navigateurs, CDN et fournisseurs d’accès de servir la version en cache du mauvais appareil.
2. Découverte lors du crawl — a historiquement aidé Googlebot à trouver la version mobile.

À quoi il ressemble

HTTP/1.1 200 OK
Vary: User-Agent

Le coût caché

• Vary: User-Agent fragmente les clés du cache CDN pour chaque chaîne de UA (navigateur, système ou robot).
• Estimation de SiteGround : 5 à 30× plus de requêtes à l’origine pour un trafic identique.
• Si le HTML est en réalité identique selon l’appareil, l’en-tête est un vestige de mauvaise configuration : supprimez-le.

Règle concernant le cloaking

• Servir un contenu adapté à l’appareil est acceptable.
• Une erreur de détection ou l’absence de Vary qui donne la mauvaise version à Googlebot constitue le vrai risque.
• Ne traitez jamais « Googlebot » comme un cas particulier : traitez l’appareil qu’il déclare comme n’importe quel autre.

Erreurs de détection courantes

• Listes de chaînes de user-agents obsolètes, qui ignorent les nouveaux appareils.
• Ordinateur détecté comme mobile, ou inversement.
• Tablettes prises pour des smartphones : le grand classique.

À ne pas confondre avec : le dynamic rendering, c’est-à-dire le pré-rendu du JavaScript pour les robots — autre notion, autre documentation.

Réalité de 2026 : une méthode historique. Google recommande le responsive depuis environ 2015, et l’achèvement de l’indexation mobile-first en 2023–2024 a accru les conséquences d’une erreur. Auditez-la pour en sortir ; ne l’adoptez pas pour un nouveau site.

Détecter le dynamic serving sur n’importe quelle URL

Le test essentiel consiste à demander la même URL avec un user-agent d’ordinateur puis de mobile, à comparer le HTML et à vérifier l’en-tête Vary: User-Agent. Si le HTML diffère, il s’agit de dynamic serving — ou de m-dot si l’URL change. Si la réponse varie sans aucun en-tête Vary, signalez cette mauvaise configuration.

curl — comparer les réponses pour ordinateur et mobile (macOS / Linux)

URL="https://example.com/"
DESKTOP="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Safari/537.36"
MOBILE="Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Mobile Safari/537.36"

# Fetch both, hash the body — different hashes = different HTML per device
curl -sA "$DESKTOP" "$URL" | shasum
curl -sA "$MOBILE"  "$URL" | shasum

# Is the site even sending Vary: User-Agent? (headers only)
curl -sI "$URL" | grep -i '^vary:'

curl — se faire passer pour Googlebot Smartphone (vérifier ce que reçoit le robot)

GBOT="Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
curl -sA "$GBOT" "https://example.com/" | shasum
# Compare to the $MOBILE hash above — they should match. If Googlebot gets the
# desktop version, that's the misconfiguration that can look like cloaking.

Windows (PowerShell) — même comparaison

$Url = "https://example.com/"
$Desktop = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Safari/537.36"
$Mobile  = "Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Mobile Safari/537.36"

(Invoke-WebRequest $Url -UserAgent $Desktop).RawContentLength
(Invoke-WebRequest $Url -UserAgent $Mobile ).RawContentLength
(Invoke-WebRequest $Url -Method Head).Headers["Vary"]

Chrome DevTools — sans terminal

1. Ouvrez DevTools (F12 / Cmd+Opt+I), puis l’onglet Network conditions (⋮ → More tools → Network conditions).
2. Décochez « Use browser default », choisissez un UA mobile — ou collez la chaîne de Googlebot Smartphone — puis rechargez. Comparez la page rendue et, dans le panneau Network, les Response Headers de la requête du document pour Vary.
3. Revenez à un UA d’ordinateur et rechargez : un HTML différent sur la même URL est le signal recherché.

Extrait pour la console du navigateur — vérifier l’en-tête Vary de la page active

// Paste in the DevTools Console on the page you're testing
fetch(location.href, { method: "HEAD", cache: "no-store" })
  .then(r => console.log("Vary:", r.headers.get("vary") || "(none)"));

Bookmarklet — vérifier Vary en un clic

javascript:(async()=>{const r=await fetch(location.href,{method:"HEAD",cache:"no-store"});alert("Vary: "+(r.headers.get("vary")||"(none set)"));})();

Remarque : fetch n’expose que les en-têtes de réponse autorisés par le serveur via CORS pour les requêtes interorigines. Les contrôles dans la console ou par bookmarklet sont donc surtout fiables sur l’origine de la page consultée. Pour une lecture définitive de l’en-tête, utilisez curl -I ou le panneau Network de DevTools.

Outils d’audit des réponses dépendantes de l’appareil

• curl : répétez la même requête avec des user-agents explicites d’ordinateur, de mobile et de Googlebot Smartphone ; comparez les en-têtes, l’état, la taille du corps et les empreintes du contenu.
• Panneau Network de Chrome DevTools : remplacez le user-agent, désactivez le cache et inspectez la réponse réelle du document au lieu de supposer que l’émulation d’un appareil la modifie.
• Inspection d’URL dans Search Console : examinez le HTML rendu que Googlebot Smartphone a reçu pour des URL représentatives.
• Crawler configurable par user-agent : lancez des crawls mobile et ordinateur séparés, puis comparez à grande échelle titres, headings, URL canoniques, directives, données structurées et liens internes.
• Analyse du cache CDN : segmentez réussites, échecs et clés de cache par catégorie d’appareil pour repérer la fragmentation ou les fuites entre appareils.

Anti-patterns du dynamic serving

Les modes d’échec qui transforment une solution « fonctionnelle » en configuration qui vous nuit activement :

1. Servir un HTML différent sans en-tête Vary: User-Agent. C’est la faute capitale. Sans cet en-tête, un cache peut stocker la version pour ordinateur et la remettre à un téléphone — ou remettre la page pour ordinateur à Googlebot Smartphone. Le contenu varie, mais rien ne le signale aux caches ni aux robots : la mauvaise version se propage. Si vous servez un HTML propre à l’appareil, l’en-tête est indispensable.

2. Ajouter Vary: User-Agent à un site qui est en réalité responsive. C’est l’erreur inverse, et elle est fréquente. Si le HTML est identique entre les appareils, l’en-tête n’apporte rien et fragmente le cache CDN pour chaque chaîne de user-agent — SiteGround estime le nombre de requêtes à 5–30×. Ne l’ajoutez pas « par précaution » : utilisez-le uniquement quand le HTML varie réellement selon l’appareil.

3. Traiter « Googlebot » comme un cas particulier dans la détection. Détecter la catégorie d’appareil est acceptable. Rechercher spécifiquement Googlebot et lui servir autre chose mène au cloaking accidentel. Googlebot se présente comme un appareil mobile précis : traitez-le exactement comme cet appareil.

4. Laisser les HTML pour ordinateur et mobile perdre leur parité. Deux versions signifient deux ensembles à synchroniser. Avec l’indexation mobile-first, c’est la version mobile qui est indexée. Le contenu, les données structurées, les images et textes alternatifs ou les liens présents uniquement sur ordinateur ont donc, du point de vue de l’indexation, disparu.

5. Conserver des listes de user-agents obsolètes et prendre les tablettes pour des téléphones. Les listes de détection se périment : les nouveaux appareils ne correspondent à aucune règle, des ordinateurs sont pris pour des mobiles et des tablettes pour des smartphones. Une détection configurée une fois puis oubliée classera discrètement de plus en plus de trafic dans la mauvaise catégorie.

6. Considérer le dynamic serving comme une « option » neuve à choisir. En 2026, ce n’est plus l’une de trois solutions équivalentes. Google recommande le responsive depuis environ 2015 et l’indexation mobile-first a accru les risques. Pour un nouveau projet, choisissez le responsive ; le dynamic serving est une dette historique à réduire.

7. Le confondre avec le dynamic rendering. Utiliser les documents sur le pré-rendu JavaScript — ou l’article de Bing sur bingbot — pour configurer un service selon l’appareil. Problème différent, solution différente : les mélanger produit des consignes qui ne conviennent à aucun des deux.

Pannes courantes du dynamic serving

Les utilisateurs mobiles reçoivent parfois la page pour ordinateur

Symptôme : la bonne réponse mobile apparaît lors d’une requête à froid, mais le HTML pour ordinateur apparaît après des accès au cache. Cause probable : la réponse varie selon le user-agent sans clé de cache correspondante ni Vary: User-Agent. Correction : corrigez l’en-tête à l’origine et la configuration du CDN, purgez les objets concernés, puis répétez des requêtes entre appareils sur des entrées de cache préchauffées.

Googlebot Smartphone voit moins de contenu

Symptôme : l’Inspection d’URL ne contient pas certains textes, liens, données structurées ou images disponibles sur ordinateur. Cause probable : les modèles mobiles ont divergé ou la détection de l’appareil a mal orienté Googlebot. Correction : rétablissez la parité depuis la source de contenu commune et testez l’agent exact du robot pour smartphone avec celui d’un téléphone ordinaire.

Un site responsive utilise mal son cache

Symptôme : le HTML est identique sur tous les appareils, mais le CDN stocke de nombreuses variantes par user-agent. Cause probable : un ancien en-tête Vary: User-Agent a survécu à la migration vers le responsive design. Correction : vérifiez que la réponse ne varie réellement plus, supprimez l’en-tête, purgez les variantes et confirmez que le cache se regroupe.

Valider une modification du dynamic serving

Tester l’accord entre représentation et en-tête

Test à effectuer : demandez la même URL avec des user-agents d’ordinateur et de mobile, puis relevez les empreintes du corps et l’en-tête Vary. Résultat attendu : des corps intentionnellement différents déclarent tous deux Vary: User-Agent ; des corps responsives identiques ne portent pas de variation inutile selon l’appareil. Interprétation d’un échec : le signal envoyé au cache et le comportement de l’origine se contredisent. Fenêtre de surveillance : immédiate. Déclencheur de retour arrière : des corps différents peuvent partager le même objet de cache sans variation.

Tester l’isolation après préchauffage du cache

Test à effectuer : préchauffez l’URL avec une catégorie d’appareil, puis demandez- la avec l’autre, dans les deux ordres. Résultat attendu : chacune reçoit toujours la représentation prévue. Interprétation d’un échec : la clé du cache CDN ignore la variation selon l’appareil. Fenêtre de surveillance : immédiatement après une modification du CDN ou de l’en-tête. Déclencheur de retour arrière : une requête mobile reçoit le HTML pour ordinateur, ou inversement.

Tester la parité du contenu mobile

Test à effectuer : comparez un échantillon des rendus pour ordinateur et mobile sur le contenu principal, les métadonnées, les directives, les liens et les données structurées. Résultat attendu : la mise en page peut différer, mais le sens indexable et les signaux restent équivalents. Interprétation d’un échec : la divergence des modèles modifie ce que l’indexation mobile-first peut exploiter. Fenêtre de surveillance : lors de la mise en production, puis après un nouveau crawl dans l’Inspection d’URL. Déclencheur de retour arrière : la représentation mobile supprime un élément indexable ou ajoute une directive restrictive.

Testez vos connaissances : Dynamic Serving

Cinq questions rapides sur le dynamic serving et l’en-tête Vary. Choisissez une réponse pour chacune, puis vérifiez.

Ressources à consulter

Mes articles connexes

• The Beginner’s Guide to Technical SEO — pour replacer la configuration mobile, le crawl et l’indexation dans leur contexte général.
• JavaScript SEO Issues & Best Practices — utile pour la notion de dynamic rendering souvent confondue avec le dynamic serving : la partie JavaScript pour les robots, et non le service selon l’appareil.

Mes conférences

• How Search Works (SlideShare) — ma présentation du crawl, du rendu, de l’indexation et du classement, notamment de la manière dont Googlebot explore comme un smartphone — raison pour laquelle les mauvaises configurations selon l’appareil sont pénalisantes avec l’indexation mobile-first. (Avertissement permanent : “This is my understanding of systems… not going to be 100% complete or accurate.” (traduction) « Voici ma compréhension des systèmes… elle ne sera pas complète ni exacte à 100 %. »)

Dans le reste du secteur

• Bonnes pratiques pour l’indexation mobile-first (Google) — emplacement actuel des définitions du dynamic serving et des URL distinctes, ainsi que de la recommandation en faveur du responsive design.
• Dynamic Serving (ancienne documentation Google archivée) (Google, via Wayback Machine) — page retirée et plus détaillée sur les deux fonctions de Vary et les erreurs de détection du user-agent.
• Le dynamic rendering comme solution de contournement (Google) — notion distincte de rendu JavaScript, avec la précision selon laquelle un contenu similaire ne constitue pas du cloaking.
• Configuration d’un site mobile et en-tête HTTP Vary (Search Engine Land, Cindy Krum, 2013) — conflit entre les CDN d’entreprise et l’en-tête Vary. La source est ancienne, mais la tension sous-jacente liée à la fragmentation du cache demeure.
• Pourquoi l’en-tête HTTP Vary peut poser problème (SiteGround) — explication accessible de la fragmentation du cache par Vary: User-Agent et estimation d’un coût en ressources de 5–30×.
• Les trois principaux problèmes de Google avec les sites mobiles en dynamic serving (Search Engine Roundtable, 2015) — problèmes d’implémentation JavaScript, CSS et images signalés par Pierre Far, témoignage ancien du fait que même Google rencontrait ces erreurs.

Journal des modifications