Un composant qui ne s’affiche pas laisse un espace vide dans la page.
Le texte qu’il devait porter disparaît alors du HTML rendu. Avec les seo web components, chaque contenu doit rester visible pour Google. Cet article vous montre comment le vérifier et le garantir.
SEO web components : le Shadow DOM n’empêche pas l’indexation du contenu
Google exécute le JavaScript, puis analyse le HTML produit. Le Shadow DOM ne bloque donc rien.
Pendant le rendu, Google aplatit le Shadow DOM et le DOM léger. Il analyse la représentation finale, qui réunit la structure interne et le contenu affiché.
Le DOM léger regroupe les éléments placés entre les balises du composant. Le Shadow DOM désigne l’arbre interne attaché au composant. Les deux participent au rendu final.
Le composant doit produire du HTML sémantique : titres, paragraphes, listes, liens. Un texte placé uniquement dans un canevas reste invisible pour la recherche.
Le contenu doit s’afficher sans interaction. Un texte qui n’apparaît qu’après un clic, un défilement ou une autorisation ajoute une dépendance technique inutile.
Le code source initial et le HTML rendu décrivent deux états distincts. Le premier correspond à la réponse HTTP ; le second intègre les modifications produites par JavaScript.
Un élément crée un point d’insertion dans le Shadow DOM. Il affiche le contenu que l’appelant place dans le DOM léger.
Le slot par défaut reçoit les enfants sans attribut slot. Un slot nommé ne reçoit que les éléments portant le nom correspondant.
Le test des résultats enrichis affiche le HTML rendu par Google. Il permet de contrôler textes, liens, données structurées et éléments générés par les composants.
L’outil Inspection de l’URL, dans la Search Console, propose le même contrôle. Le test en direct fournit le HTML, une capture d’écran, les ressources chargées et les erreurs JavaScript.
Recherchez directement dans le HTML rendu :
- le titre éditorial, visible après exécution du composant ;
- les paragraphes injectés dans le Shadow DOM ;
- les contenus projetés via les slots ;
- les liens dotés d’un attribut href exploitable ;
- les données structurées présentes dans le DOM final.
Le Shadow DOM encapsule la structure sans bloquer l’indexation
Trois technologies forment un Web Component
L’élément personnalisé fournit une balise réutilisable, comme . Vous l’enregistrez dans le registre customElements.
L’élément stocke une structure HTML non affichée au chargement. Le composant la clone ensuite dans son Shadow Root.
L’enregistrement passe par customElements.define(). La classe étend HTMLElement, puis crée le Shadow Root avec attachShadow().
class ProductCard extends HTMLElement { constructor() { super() ; this.attachShadow({ mode : « open » }) ; } } customElements.define(« product-card », ProductCard) ;
Le mode open rend le Shadow Root accessible en JavaScript. Le mode closed bloque cet accès externe. Il ne rend pas le contenu non indexable.
L’encapsulation protège les styles et la structure
L’encapsulation sépare le composant de son usage. Elle ne crée aucune barrière d’indexation. Seul compte le HTML rendu et visible.
Le mode closed renforce la confidentialité du DOM interne. Il n’apporte ni avantage SEO automatique ni garantie de non-indexation.
Le risque réel vient d’un rendu incomplet. Une erreur JavaScript, une ressource bloquée ou un composant non exécuté laisse un hôte vide.
Trois points à contrôler avant indexation
- Aucune erreur JavaScript ne bloque le rendu de l’hôte.
- Les ressources du composant ne sont bloquées ni par le serveur ni par le robots.txt.
- Le contenu de l’élément apparaît dans le HTML rendu, sans interaction de l’utilisateur.
Google explore, rend puis indexe les pages JavaScript
Le traitement suit trois phases distinctes
Googlebot commence par une requête HTTP. Il vérifie d’abord robots.txt. Si l’accès est autorisé, il récupère le HTML initial.
Il extrait ensuite les liens présents dans les attributs href. Les liens ajoutés par JavaScript restent exploitables après rendu. Condition : ce doivent être de vrais éléments.
Google indexe enfin le HTML rendu. Un contenu présent seulement dans la réponse initiale n’est donc pas forcément celui retenu.
Les ressources essentielles suivent les mêmes règles d’accès que la page. Un fichier JavaScript bloqué par robots.txt empêche le rendu du composant qui en dépend.
robots.txt bloque l’exploration. noindex bloque l’indexation. Ces deux directives ont des objectifs différents : ne les interchangez pas.
Le rendu initial doit rester compatible SEO
Une directive noindex présente dans le HTML initial peut conduire Google à ignorer le rendu JavaScript. La supprimer après exécution arrive trop tard.
Placez noindex uniquement sur les pages réellement exclues. Une page destinée à la recherche doit livrer son contenu principal sans cette instruction.
Le statut HTTP doit correspondre au contenu. Une page d’erreur servie en 200 devient une erreur 404 logicielle, avec un risque d’indexation indésirable.
Avant de publier une page JavaScript
- Vérifiez que robots.txt n’interdit ni la page ni les fichiers JavaScript qui la rendent.
- Placez noindex uniquement sur les pages réellement exclues.
- Renvoyez un statut 404 pour toute page d’erreur, jamais un 200.
Le rendu serveur expose le contenu avant JavaScript
Le serveur produit le HTML en amont
Le serveur génère le HTML du composant avant de l’envoyer. Le contenu est donc là dès la réponse HTTP, avant l’hydratation.
La structure est visible avant l’exécution du composant. Le risque d’un hôte vide pendant le premier rendu baisse.
Le contenu serveur doit être identique au contenu client. Si les deux versions diffèrent, l’hydratation échoue et l’affichage se contredit.
Lit permet de rendre les composants côté serveur
Le code exécuté côté serveur ne doit pas utiliser d’API réservées au navigateur. Les mesures du DOM et les interactions restent côté client.
Lit place le contenu des Shadow Roots dans des templates déclaratifs. Le navigateur les convertit en Shadow Roots dès l’analyse du HTML, sans attendre JavaScript.
Après livraison du HTML, l’hydratation rend les comportements réactifs. Elle demande les mêmes données et le même template côté serveur et client.
Vérifiez le résultat après déploiement. Le HTML doit contenir les titres, textes, liens et données structurées, pas seulement les balises hôtes.
Contrôle du HTML livré
- Vérifiez que les titres figurent dans le HTML brut, sans exécuter JavaScript.
- Vérifiez que les textes et les liens sont présents dans la réponse HTTP.
- Vérifiez que les données structurées figurent dans le même HTML.
- Refusez tout rendu qui ne contient que les balises hôtes.
Les Web Components réutilisables exigent des tests de rendu
Vérifiez chaque couche de contenu
Un audit distingue trois couches. Le HTML de la page vient en premier. Le DOM léger fourni au composant suit. Le Shadow DOM généré par celui-ci complète l’ensemble.
Le contenu éditorial principal doit apparaître dans l’une de ces trois couches. Il rejoint ensuite le HTML rendu. Trois points à vérifier :
- Le texte principal figure dans le HTML de la page ou dans le DOM léger.
- Le Shadow DOM le restitue sans le masquer.
- Une présence limitée au code JavaScript ne suffit pas.
Un slot nommé mal orthographié sort le contenu de son emplacement. Le composant reste alors incomplet. Testez chaque slot, instance par instance.
Un slot vide peut afficher un texte par défaut. Ce texte ne doit jamais remplacer un contenu SEO essentiel.
Contrôler les slots avant publication
- Vérifier l’orthographe exacte de chaque nom de slot
- Tester chaque instance du composant séparément
- Confirmer qu’aucun texte par défaut ne remplace un contenu SEO essentiel
- Repérer le contenu éditorial principal dans le HTML rendu
Interprétez les tests avec méthode
Le diagnostic suit cet ordre, du test en direct à la vérification finale :
- Le test en direct vient en premier, après chaque modification : il récupère la version actuelle de l’URL, alors que Google conserve l’état indexé.
- Ouvrez ensuite le HTML testé et cherchez le texte principal, les liens, les attributs structurés et les nœuds issus des slots. Une capture d’écran seule ne suffit pas.
- Contrôlez les ressources chargées et les erreurs JavaScript : un fichier bloqué, une exception ou une réponse serveur défaillante expliquent souvent un composant absent du rendu.
- Ajoutez une empreinte dans le nom des fichiers JavaScript et CSS, comme main.2bb85551.js. Googlebot met fortement en cache les ressources : sans nouveau nom, il peut réutiliser l’ancien fichier.
- Terminez par le HTML rendu après chaque correction. Il doit confirmer le contenu final, pas seulement l’absence d’erreur dans la console.
Sources
Le Shadow DOM ne bloque pas l’indexation, mais un rendu incomplet la fait échouer. Avant toute mise en production, testez chaque composant avec le test en direct de la Search Console. Vérifiez dans le HTML rendu que le titre, les paragraphes, les liens et les données structurées apparaissent bien. Corrigez ensuite les ressources bloquées, puis renommez vos fichiers JavaScript avec une empreinte.