Le référencement DOM consiste à rendre lisible pour les moteurs la page telle qu'elle existe une fois que le navigateur l'a construite : le Document Object Model. Google n'indexe pas seulement le HTML envoyé par le serveur. Il indexe surtout le DOM rendu, c'est-à-dire la page obtenue après l'exécution du JavaScript. Un titre, un paragraphe ou un lien qui n'apparaît qu'après une action de l'utilisateur, ou qui est construit d'une manière que le robot ne suit pas, peut donc rester invisible. Tout l'enjeu est de vérifier que la version lue par Googlebot correspond à celle que voit le visiteur.
- Le DOM est l'arbre d'éléments que le navigateur bâtit à partir du HTML, du CSS et des scripts.
- Google indexe la version rendue de cet arbre, avec un robot qui se présente comme un smartphone.
- Un contenu absent du DOM rendu, ou chargé seulement après un clic, risque de ne pas être pris en compte.
- Le contrôle se fait avec l'inspection d'URL de la Search Console, puis par un test sur un appareil réel.
DOM source et DOM rendu : deux versions d'une même page
Le raccourci Ctrl+U affiche le code source, donc la réponse brute du serveur. L'inspecteur du navigateur (F12) montre autre chose : un arbre vivant, que chaque script peut modifier, compléter ou vider. Sur un site classique rendu côté serveur, les deux versions se ressemblent beaucoup. Sur une application construite en rendu côté client, l'écart peut être énorme.
Prenons un cas fréquent en audit. Le code source d'une fiche ne contient qu'un <div id="app"></div>, quelques balises meta génériques et une série de fichiers JavaScript. Le titre du produit, sa description, son prix et les liens vers les produits voisins n'existent qu'après l'exécution des scripts. Pour un visiteur, la page est complète. Pour un outil qui lit seulement le HTML initial, elle est presque vide. Google, lui, se situe entre les deux : il sait exécuter le JavaScript, mais à ses conditions.
Comment Googlebot construit le DOM avant d'indexer
Le traitement d'une URL suit un parcours en plusieurs étapes, et chacune peut faire disparaître une partie du contenu :
Une conséquence est souvent sous-estimée : une balise noindex présente dans le HTML initial peut empêcher le rendu. La retirer ensuite en JavaScript ne sert à rien, car le robot ne va pas plus loin. Le cas inverse, un noindex ajouté par script, reste aléatoire et ne doit pas servir de méthode.
Les éléments du DOM qui comptent pour le classement
Tous les nœuds n'ont pas le même poids. Certains doivent figurer dès le HTML du serveur, d'autres peuvent arriver au rendu sans risque majeur.
ÉlémentEmplacement conseilléPiège fréquentBalise title et meta descriptionHTML initialValeur générique remplacée trop tard par le scriptBalise canonicalHTML initial, valeur uniqueCanonical modifiée par JavaScript et contradictoire avec la sourceMeta robotsHTML initialNoindex servi par défaut puis retiré côté clientLiens internesBalises a avec un attribut href réelNavigation en onclick ou en span cliquablesContenu principalHTML initial ou rendu sans interactionTexte chargé uniquement à l'ouverture d'un ongletImagesBalise img avec src ou lazy loading natifChargement déclenché par un événement de défilementDonnées structuréesHTML initial de préférenceBalisage injecté qui ne reflète plus le contenu visibleLes liens méritent une attention particulière. Google ne découvre de nouvelles URL qu'à partir de vraies balises <a href="...">. Un menu qui redirige grâce à un écouteur d'événement fonctionne parfaitement pour l'humain et coupe pourtant le maillage pour le robot.
Vérifier le rendu mobile sur un appareil réel
L'inspection d'URL de la Search Console reste la première source : elle affiche le HTML rendu par Googlebot, une capture d'écran et la liste des ressources qui n'ont pas pu être chargées. Cet outil a toutefois une limite. Il montre le résultat, sans les comportements qui y ont mené. Une bannière de consentement qui recouvre le texte, un menu dont les liens ne se créent qu'au toucher, ou un carrousel qui attend un geste de balayage passent facilement inaperçus.
D'où l'intérêt d'un test sur téléphone. Relié en USB à un poste de travail, l'appareil expose ses onglets dans chrome://inspect, et l'on peut parcourir le DOM réellement construit sur un écran mobile, avec un processeur modeste et une connexion imparfaite. Beaucoup de référenceurs gardent un smartphone d'entrée de gamme sur le bureau pour cette seule raison, et le choix de cet appareil, de sa version d'Android et de son navigateur mérite cette réflexion qu'on réserve d'ordinaire à l'achat d'un ordinateur. Un modèle trop récent masque les lenteurs, un système trop ancien produit des erreurs que Googlebot ne rencontrera jamais.
La méthode tient en peu de gestes : charger la page sans la toucher, copier le contenu de l'élément body depuis l'inspecteur distant, puis rechercher dedans les phrases clés et les liens attendus. Ce qui manque à ce stade manquera probablement aussi au robot.
Corriger un DOM qui cache le contenu aux robots
La solution la plus solide reste de servir le contenu essentiel dès le serveur. Le rendu côté serveur, la génération statique ou un pré-rendu des pages stratégiques permettent de garder une interface riche tout en livrant un HTML déjà complet. L'hydratation ajoute ensuite l'interactivité sans toucher au texte indexable.
Quand une refonte n'est pas envisageable, quelques corrections ciblées règlent déjà une bonne partie des cas :
- remplacer les éléments de navigation cliquables par de vraies balises de lien ;
- donner une URL propre à chaque état important (filtre, onglet, page de liste) au lieu d'un simple changement d'affichage ;
- débloquer dans robots.txt les dossiers de scripts et de styles nécessaires au rendu ;
- passer au lazy loading natif des images avec l'attribut loading ;
- afficher le contenu derrière les onglets dans le DOM, quitte à le masquer visuellement en CSS.
Le volume de l'arbre compte aussi. Lighthouse signale un DOM trop lourd au-delà d'environ 1 400 nœuds, et une profondeur excessive ralentit chaque recalcul de mise en page. Ce n'est pas un critère de classement direct, mais un arbre gonflé dégrade les signaux d'expérience et allonge le rendu, surtout sur les mobiles modestes.
Les cas limites qui reviennent en audit
Google exécute-t-il toujours le JavaScript d'une page ?
Dans la grande majorité des cas, oui, avec un Chromium récent. Le rendu peut cependant échouer si des ressources sont bloquées, si un script plante ou si la page met trop de temps à se stabiliser. Rien ne garantit que chaque appel réseau tardif sera attendu.
Un texte qui s'affiche après un clic sur « Lire la suite » est-il indexé ?
S'il est déjà présent dans le DOM et simplement masqué, il est généralement pris en compte. S'il est récupéré auprès du serveur au moment du clic, le robot ne le verra pas, puisqu'il ne déclenche aucune interaction.
Le Shadow DOM pose-t-il problème pour l'indexation ?
Google aplatit le contenu du Shadow DOM avec le reste de la page lors du rendu, ce qui le rend indexable. Il faut tout de même vérifier dans l'inspection d'URL que les textes et les liens des composants apparaissent bien dans le HTML rendu.
À partir de quelle taille un DOM devient-il gênant ?
Les outils de mesure d'Google commencent à alerter vers 800 nœuds et considèrent la situation comme problématique au-delà de 1 400. Une page plus lourde peut se classer, mais elle devient plus lente à afficher et plus coûteuse à rendre pour le robot.
