Niveau · Avancé
Lecture 5 min
DOM
Définition, différence avec le code source et rôle dans l’indexation par Google.
Le DOM (Document Object Model) est la représentation en mémoire d’une page, sous forme d’arbre de nœuds. Le navigateur le construit à partir du HTML reçu, puis JavaScript peut le modifier avant l’affichage. En SEO, c’est ce DOM final, et non le fichier HTML d’origine, que Google utilise pour indexer la page.
Un contenu injecté par JavaScript existe dans le DOM sans figurer dans le code source. Google ne le voit qu’après son étape d’affichage, qui n’est pas immédiate.
éléments dans le DOM d’une page mobile médiane, mesure du Web Almanac 2024.
éléments au 90e centile : la moitié haute du web construit des arbres nettement plus lourds.
étapes documentées par Google avant qu’une page existe dans l’index : exploration, affichage, indexation.
Comment fonctionne le DOM ?
Le navigateur transforme le HTML reçu en arbre d’objets manipulables. Chaque balise devient un nœud, chaque imbrication devient une relation parent-enfant, et JavaScript peut ensuite ajouter, déplacer ou supprimer ces nœuds sans que le fichier d’origine change.
Le standard DOM du WHATWG définit un modèle indépendant des plateformes pour les événements et les arbres de nœuds. C’est un standard vivant, révisé en continu plutôt que par versions figées : sa dernière mise à jour date du 25 août 2026. Le DOM n’est donc pas un format de fichier, mais une interface de programmation, une API : deux navigateurs partant du même HTML doivent aboutir au même arbre.
Niveau expert : Le DOM et l’arbre de rendu sont deux choses différentes. Un nœud masqué par une règle de style existe dans le DOM mais sort de l’arbre de rendu. Google sérialise le DOM après exécution du script, ce qui explique qu’un contenu masqué par défaut puisse être indexé, alors qu’un contenu chargé au clic ne l’est pas.
Pourquoi le DOM est important en SEO ?
Google n’indexe pas le fichier HTML, il indexe le DOM sérialisé. Search Central décrit trois étapes distinctes, exploration puis affichage puis indexation, et précise que c’est le code HTML affiché qui sert à indexer la page.
L’écart entre les deux se paie cher. Une page dont le contenu principal n’existe que dans le DOM dépend entièrement de l’étape d’affichage : Googlebot met la page en file d’attente, la rend dans un Chromium sans interface, puis indexe le résultat. Tout ce qui échoue pendant ce rendu, script bloqué par le fichier robots.txt, erreur d’exécution, appel réseau trop lent, disparaît de la version indexée. Google est explicite : un contenu absent du rendu HTML ne peut pas être indexé.
Le raccourci à éviter. « Le contenu est dans le DOM, donc Google le voit. » Il faut qu’il soit dans le DOM au moment où Google sérialise la page, sans action de l’utilisateur. Un contenu chargé au clic, au survol ou au défilement profond n’y figure pas.
| Critère | HTML source | HTML affiché (DOM) |
|---|---|---|
| Ce que c’est | Le fichier renvoyé par le serveur | L’arbre de nœuds après exécution de JavaScript |
| Comment le lire | Affichage du code source, ou requête curl | Onglet Elements du navigateur, ou outil d’inspection d’URL |
| Rôle chez Google | Point de départ de l’exploration | Base de l’indexation |
Comment voir le DOM que Google utilise ?
L’outil d’inspection d’URL de la Search Console affiche le HTML tel que Google le voit après rendu. C’est la seule source qui montre le DOM de Google, et non celui du navigateur du visiteur.
La méthode tient en une comparaison. D’un côté le code source brut, obtenu par une requête HTTP sans exécution de script. De l’autre le HTML affiché, lu dans l’outil d’inspection d’URL. Tout élément présent dans le second et absent du premier dépend du rendu. Si un titre, un prix ou un bloc de texte n’apparaît dans aucun des deux, il n’existe pas pour l’index, quelle que soit son apparence à l’écran.
Vérifier ce que Google indexe vraiment de vos pages.
Le contrôle compare le code source, le HTML affiché et les ressources bloquées au crawl, page type par page type. Je le mène dans le cadre d’un audit technique.
Comment diagnostiquer un problème de DOM ?
Le diagnostic consiste à isoler ce qui dépend du rendu. Trois contrôles suffisent à trancher entre un défaut de contenu et un défaut d’exécution.
Comparer source et rendu
Récupérer la page sans exécuter de script, puis la relire dans l’outil d’inspection d’URL. L’écart désigne ce qui dépend du rendu.
Vérifier les ressources bloquées
Un script interdit par le fichier robots.txt ne s’exécute pas chez Google. Le contenu qu’il devait injecter n’entre jamais dans le DOM sérialisé.
Tester sans interaction
Google ne clique pas, ne survole pas et ne remplit pas de formulaire. Tout contenu qui exige un geste reste hors du DOM indexé.
Exemple concret du DOM
Une vérification faible consiste à ouvrir la page et à constater que le prix s’affiche. La vérification solide consiste à chercher ce prix dans la réponse du serveur, avant toute exécution de script. La commande ci-dessous compte les occurrences d’un identifiant dans le HTML source :
curl -s https://exemple.fr/fiche-produit/ | grep -c 'prix-produit'Un résultat à zéro ne condamne pas la page : il indique seulement que le prix vient du DOM. Reste à confirmer, dans l’outil d’inspection d’URL, qu’il survit au rendu de Google.
Erreur fréquente observée en audit
Cas réel. Le motif se répète sur les catalogues récents : les caractéristiques produit sont injectées par un composant après le chargement, le code source ne contient qu’un conteneur vide, et les pages se positionnent sur la marque mais sur aucun attribut technique. La comparaison entre code source et HTML affiché tranche la question en quelques minutes.
Le DOM compte-t-il pour le GEO ?
Oui, et le risque augmente. Google documente son étape d’affichage et exécute JavaScript dans Chromium. Les crawlers des moteurs génératifs ne publient pas d’équivalent documenté : un contenu qui n’existe que dans le DOM peut donc être lu par Google et manquer à ces agents.
Deux idées reçues sur le DOM
Google ne lit pas le JavaScript. Google le lit : Search Central décrit l’affichage dans un Chromium sans interface, entre l’exploration et l’indexation. Ce qui est vrai, c’est que cette étape passe par une file d’attente et n’est donc pas immédiate.
Tout ce qui figure dans le DOM finit indexé. Google indexe le HTML affiché au moment où il sérialise la page. Un contenu qui n’apparaît qu’après un clic, un survol ou un défilement n’y figure pas, et le cas vaut aussi pour les composants web dont le contenu reste dans un arbre fantôme.
Questions fréquentes
Qu’est-ce que le DOM ?−
Le DOM, ou Document Object Model, est la représentation en mémoire d’une page sous forme d’arbre de nœuds. Le navigateur le construit à partir du HTML reçu, puis JavaScript peut le modifier. Le standard est maintenu par le WHATWG sous forme de standard vivant, dont la dernière mise à jour date du 25 août 2026.
Quelle différence entre le code source et le DOM ?+
Le code source est le fichier renvoyé par le serveur, avant toute exécution. Le DOM est l’arbre obtenu après analyse de ce fichier puis exécution des scripts. Google explore le premier, mais indexe le second, qu’il appelle le code HTML affiché.
Un DOM trop lourd nuit-il au référencement ?+
Indirectement. Un arbre volumineux allonge le temps de rendu et pèse sur les Core Web Vitals, en particulier sur la réactivité. Le Web Almanac mesurait en 2024 une médiane de 594 éléments par page mobile, et 1 716 au 90e centile : l’écart tient surtout aux gabarits génériques et aux conteneurs vides.
Faire expliquer ce terme par une IA
Ouvre le moteur de ton choix avec un prompt pré-rempli sur ce terme.
Sources
- WHATWG · DOM Living Standard · mise à jour du 25 août 2026
- Google Search Central · Principes de base du SEO JavaScript · mise à jour du 6 mars 2026
- Web Almanac 2024 · chapitre Markup · édition 2024
Termes liés
Damien Hernandez
Consultant SEO senior, 17 ans d'expérience (Accor, Louvre Hotels, Infopro Digital). Spécialiste SEO technique, analyse de logs et optimisation pour les moteurs génératifs (GEO).