Le contenu CSS ::before et ::after est-il vraiment invisible pour Google ?

Pourquoi Google précise-t-il que ce contenu n'est pas indexé ?

Parce que les pseudo-éléments CSS ::before et ::after génèrent du contenu visuel directement via la feuille de style, sans jamais passer par le DOM. Le Document Object Model, c'est la structure que les crawlers lisent pour indexer une page.

Si un élément n'existe pas dans le DOM, il n'existe pas pour Googlebot. C'est aussi simple que ça. Les outils d'accessibilité, comme les lecteurs d'écran, ignorent également ce contenu — ce qui devrait déjà suffire à comprendre qu'il ne doit jamais porter d'information utile.

Que signifie exactement « contenu décoratif » ?

Un contenu décoratif, c'est tout ce qui relève de l'enrichissement visuel sans valeur informative : des icônes, des séparateurs, des guillemets stylisés, des effets graphiques. Des éléments qui améliorent l'expérience utilisateur mais dont l'absence ne change rien à la compréhension du contenu.

En revanche, si vous ajoutez du texte significatif — une mention, un label, un complément d'information — via ::before ou ::after, ce texte sera invisible pour Google et pour les utilisateurs en situation de handicap.

Quels sont les cas d'usage légitimes de ::before et ::after ?

• Ajouter des icônes décoratives (flèches, puces stylisées, pictogrammes)
• Insérer des séparateurs visuels ou des ornements typographiques
• Créer des effets graphiques (triangles, ombres, backgrounds complexes)
• Afficher des guillemets stylisés autour de citations
• Générer des numéros de liste personnalisés pour du contenu déjà présent dans le HTML

Cette déclaration coupe-t-elle court à certaines pratiques ?

Absolument. Certains ont tenté d'utiliser ::before et ::after pour injecter du contenu sémantique — parfois dans l'espoir de manipuler l'indexation, parfois par simple méconnaissance. Des labels comme « Nouveau », « Promo », ou pire, des compléments de titres entiers passés en CSS.

Google met les points sur les i : ce qui n'est pas dans le DOM n'existe pas pour le SEO. Point. Cette clarification devrait aussi rappeler aux devs front que l'accessibilité et le SEO partagent souvent les mêmes exigences techniques.

Y a-t-il des exceptions ou des cas limites à surveiller ?

Techniquement, non — la règle est claire. Mais dans la pratique, on voit encore des frameworks qui utilisent ::before pour afficher des icônes via des fonts (genre Font Awesome). Si ces icônes sont purement décoratives, aucun problème.

Le piège ? Quand ces icônes portent un sens (une étoile pour noter un produit, une coche pour valider une info) sans texte alternatif dans le HTML. Là, vous perdez à la fois en SEO et en accessibilité — et Google ne verra jamais cette information.

Google pourrait-il changer d'avis un jour ?

Peu probable. L'architecture même du web repose sur la séparation HTML/CSS/JS. Le HTML porte la structure et le contenu, le CSS gère la présentation. Tant que cette logique prévaut, les pseudo-éléments resteront hors du DOM — donc hors de portée des crawlers.

Et franchement ? C'est une bonne chose. Cela force à penser accessibilité dès la conception, au lieu de bidouiller des rustines CSS pour contourner des choix structurels bancals.

Que faut-il vérifier en priorité sur son site ?

Commencez par un audit du CSS pour repérer tous les usages de ::before et ::after. Cherchez les occurrences qui contiennent la propriété content: avec du texte entre guillemets — c'est là que se nichent les problèmes potentiels.

Ensuite, croisez avec une inspection manuelle des pages stratégiques : fiches produits, landing pages, articles. Si du contenu visible à l'écran disparaît quand vous désactivez le CSS, c'est un signal d'alarme.

Quelles erreurs éviter absolument ?

Ne jamais utiliser ::before ou ::after pour insérer des informations critiques : mentions légales, labels de disponibilité, compléments de titres, descriptions courtes. Tout ce qui a une valeur informative doit être dans le HTML, point final.

Évitez aussi de vous fier aux aperçus de rendu des outils SEO. Ils simulent parfois un navigateur complet et affichent le contenu CSS — mais ça ne signifie pas que Googlebot l'indexe. Le seul test fiable ? Regarder le code source brut (Ctrl+U).

Comment corriger les usages problématiques détectés ?

• Migrer tout contenu textuel significatif des pseudo-éléments vers le HTML proprement dit
• Utiliser des balises sémantiques appropriées (span, strong, em) pour le contenu précédemment injecté en CSS
• Ajouter des attributs aria-label ou du texte masqué visuellement (sr-only) pour les icônes porteuses de sens
• Auditer les frameworks CSS (Bootstrap, Tailwind, etc.) pour vérifier leur gestion des icônes et éléments décoratifs
• Tester l'accessibilité avec des lecteurs d'écran pour confirmer que l'information clé reste perceptible
• Documenter les usages légitimes de ::before/::after pour éviter les régressions futures