Official statement
Other statements from this video 8 ▾
- 10:25 Google indexe-t-il vraiment toutes les pages qu'il explore ?
- 11:48 Votre serveur lent tue-t-il votre crawl budget sans que vous le sachiez ?
- 22:16 Les canonicals sont-elles vraiment évaluées comme les balises noindex par Google ?
- 23:49 Le JavaScript bloque-t-il vraiment l'indexation de vos pages par Google ?
- 31:39 Faut-il regrouper vos petits sites en un seul domaine pour améliorer votre SEO ?
- 34:39 Le Dynamic Rendering est-il encore une solution viable pour gérer le JavaScript en SEO ?
- 42:00 Faut-il vraiment optimiser toutes vos images pour Google Images ?
- 52:11 Faut-il vraiment corriger toutes les erreurs 404 dans Search Console ?
Google accepts JSON-LD anywhere on a page, but imposes a strict rule for HTML-embedded data: it must be visible to the user. If you mark up hidden content with microdata or RDFa, Google may ignore it or penalize you for manipulation. JSON-LD remains the most flexible and least risky method for incorporating structured data.
What you need to understand
Why does Google differentiate between JSON-LD and direct HTML tags?
JSON-LD (JavaScript Object Notation for Linked Data) is a format for structured data that fits into a <script> tag, independent from the visible HTML. Google prefers it because it clearly separates the semantic layer from the visual presentation.
Microdata and RDFa, on the other hand, are directly integrated into the HTML tags of the content. They require the marked-up content to be displayed on-screen; otherwise, Google considers it a manipulation attempt: you are marking something the user cannot see.
What does 'visible to the user' actually mean?
Content is visible if it appears naturally on the page without any specific action from the user. This excludes CSS-hidden texts (display:none, visibility:hidden), content pushed off-screen with negative positions, or text in the same color as the background.
On the other hand, content revealed through interaction (accordions, tabs) raises questions. Google generally tolerates them, but there is a gray area: if the content is never displayed on initial load, it’s better to use JSON-LD for marking it up.
Can JSON-LD really be placed anywhere?
Technically yes. You can insert your <script type="application/ld+json"> block in the <head>, at the end of the <body>, or even in the middle of the content. Google will parse it anyway.
The common practice is to place it in the <head> to facilitate maintenance and centralization. Some CMSs dynamically inject JSON-LD in the footer, which also works well.
- JSON-LD: free placement, no visibility constraint for the marked-up content.
- Microdata / RDFa: the marked-up content must be displayed to the user, or risk a penalty.
- CSS-hidden content cannot be marked up with microdata without risk.
- Google has recommended JSON-LD as the preferred format for several years.
- The flexibility of JSON-LD simplifies implementation on complex or multi-template sites.
SEO Expert opinion
Does this statement clarify on-the-ground ambiguities?
Partially. Mueller confirms what SEOs have long observed: Google tolerates deviations with JSON-LD better than with microdata. In practice, sites are regularly penalized for marked-up hidden content with microdata, while the same content in JSON-LD passes without issue.
The problem is that Mueller does not specify the exact margin of maneuver. Can you mark up a product in JSON-LD that does not exist on the page? A review that is not displayed? The official answer remains unclear. [To be checked] on borderline cases, since Google can still trigger a manual action if the gap between JSON-LD and visible content is too large.
Why does Google enforce this visibility rule for microdata?
Historically, webmasters have abused hidden texts to stuff pages with keywords or false structured information (fake reviews, fake prices, fake availability). Google has hardened its position: if it's in the HTML and the user does not see it, it's suspicious.
With JSON-LD, Google takes a calculated risk: the format is easier to audit automatically, and blatant abuses (non-existent products, fake data) can be detected by cross-referencing with actual content. But this tolerance is not a free pass to invent data.
What borderline cases still pose problems?
Accordion or tabbed content: technically visible but not on initial load. Google generally tolerates them, but if a competitor reports you, a manual action is still possible. Prefer JSON-LD for these gray areas.
Paged or infinite scroll pages: marking up microdata for products that only appear after scrolling or clicking
Practical impact and recommendations
Que faut-il faire concrètement sur vos sites ?
Auditez vos implémentations microdata et RDFa existantes. Vérifiez que chaque élément balisé est bien visible par l'utilisateur sans action particulière. Si vous avez des contenus masqués balisés, migrez-les en JSON-LD ou affichez-les.
Pour les nouveaux projets, privilégiez systématiquement JSON-LD. C'est plus simple à maintenir, moins risqué, et Google le recommande explicitement. La plupart des CMS modernes (WordPress avec extensions, Shopify, PrestaShop) génèrent désormais du JSON-LD par défaut.
Quelles erreurs éviter absolument ?
Ne balisez jamais en microdata un contenu en display:none ou visibility:hidden. Google le détecte facilement et peut vous pénaliser pour cloaking sémantique. Si le contenu doit être masqué (accordéon, modal), passez en JSON-LD.
Évitez les incohérences entre JSON-LD et contenu visible. Par exemple, baliser un prix de 99€ en JSON-LD alors que la page affiche 119€ peut déclencher une alerte. Google croise de plus en plus les données structurées avec le rendu DOM et les captures visuelles.
Comment vérifier que votre implémentation est conforme ?
Utilisez le Rich Results Test de Google pour valider la syntaxe et la détection des données structurées. Mais attention : cet outil ne vérifie pas la cohérence avec le contenu visible, juste la validité du code.
Complétez avec un audit visuel : désactivez JavaScript, CSS, et vérifiez que les contenus balisés en microdata sont toujours affichés. Pour le JSON-LD, croisez manuellement les données avec ce que voit l'utilisateur. Un crawler comme Screaming Frog peut extraire le JSON-LD et le comparer au texte visible.
- Migrer les données structurées critiques (produits, avis, FAQ) vers JSON-LD
- Supprimer ou afficher tout contenu masqué balisé en microdata
- Vérifier la cohérence entre JSON-LD et contenu visible (prix, disponibilité, avis)
- Tester le rendu avec JavaScript désactivé pour repérer les contenus cachés
- Auditer régulièrement avec Rich Results Test et Search Console
- Documenter les choix d'implémentation pour faciliter les futures migrations
❓ Frequently Asked Questions
Peut-on mélanger JSON-LD et microdata sur la même page ?
Un contenu en accordéon fermé peut-il être balisé en microdata ?
Le JSON-LD dans le footer est-il aussi efficace que dans le head ?
Google peut-il pénaliser un JSON-LD qui ne correspond pas au contenu visible ?
Faut-il supprimer les anciennes implémentations microdata lors d'une migration JSON-LD ?
🎥 From the same video 8
Other SEO insights extracted from this same Google Search Central video · duration 57 min · published on 18/10/2018
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.