Faut-il vraiment supprimer le JSON-LD des pages en NOINDEX ?

Pourquoi Google rejette-t-il le JSON-LD sur les pages NOINDEX ?

La logique interne de Google repose sur un principe simple : une page non indexée n'existe pas dans l'index, donc toute donnée structurée qu'elle contient ne peut être rattachée à aucun document identifié. Le moteur ne stocke pas le contenu de ces pages, il ne peut donc pas exploiter le JSON-LD pour enrichir le Knowledge Graph ou générer des rich snippets.

Concrètement, si vous placez un schéma Product ou Review sur une page bloquée par une balise NOINDEX, Google ignore purement et simplement ce marquage. Le robot peut techniquement lire le code lors du crawl, mais aucune association sémantique n'est enregistrée puisque la page n'entre jamais dans la base d'indexation.

Cette règle s'applique-t-elle à tous les types de données structurées ?

Mueller ne précise pas de distinction selon le type de schéma. Pourtant, certains marquages comme BreadcrumbList ou SiteNavigationElement servent avant tout à cartographier la structure du site. On pourrait imaginer que Google les exploite même sans indexer la page porteuse, mais rien dans cette déclaration ne le confirme.

De même, les données de type Organization ou LocalBusiness alimentent souvent le Knowledge Panel de l'entité. Si ces schémas apparaissent sur une page NOINDEX (par exemple une page de mentions légales bloquée), Google ne les prendra probablement pas en compte. Il faut donc dupliquer ces marquages sur une page indexée pour garantir leur exploitation.

Que se passe-t-il si une page bascule de NOINDEX à INDEX ?

Le comportement de Google dans ce cas n'est pas explicité. On peut supposer qu'une fois la directive NOINDEX levée, le moteur réindexe la page et associe alors le JSON-LD présent. Mais aucun délai n'est garanti : si le crawl budget est limité ou si la page est jugée peu prioritaire, l'association peut prendre du temps.

Inversement, si vous passez une page de INDEX à NOINDEX, Google cesse progressivement de l'afficher dans les résultats et désassocie les données structurées qu'elle contenait. Ce processus n'est pas instantané : les rich snippets peuvent persister quelques jours avant de disparaître complètement.

• Une page NOINDEX n'alimente jamais l'index Google, donc son JSON-LD est ignoré pour les rich snippets et le Knowledge Graph.
• Aucun type de schéma n'est explicitement épargné par cette règle, même les marquages structurels ou d'entité.
• Les transitions INDEX/NOINDEX entraînent une association ou désassociation du JSON-LD, mais sans garantie de délai.
• Pour garantir l'exploitation d'un marquage critique, placez-le toujours sur une page indexée et accessible aux robots.

Cette déclaration est-elle cohérente avec les pratiques observées ?

Sur le terrain, on constate effectivement que les pages en NOINDEX ne génèrent jamais de rich snippets. Les tests menés avec des schémas Product ou FAQ sur des pages bloquées confirment l'absence totale d'affichage enrichi dans les SERPs. Jusqu'ici, la déclaration de Mueller colle à la réalité observable.

En revanche, un point reste flou : Google peut-il exploiter le JSON-LD d'une page NOINDEX pour enrichir la compréhension d'autres entités du site ? Par exemple, si une page NOINDEX contient un schéma Organization avec des sameAs pointant vers des profils sociaux, ces liens sociaux peuvent-ils alimenter le Knowledge Panel de l'entité, même si la page porteuse n'est pas indexée ? [A vérifier] — Mueller ne le précise pas, et aucune donnée publique ne tranche cette question.

Quelles nuances faut-il apporter selon le contexte ?

Cette règle concerne strictement Googlebot et l'index Google. D'autres robots (Bing, Yandex, moteurs verticaux) peuvent avoir des comportements différents. Certains crawlers spécialisés exploitent le JSON-LD indépendamment de l'indexation — par exemple, des agrégateurs de données produits ou des comparateurs de prix. Retirer systématiquement le JSON-LD des pages NOINDEX peut donc couper des flux de données utiles à d'autres canaux.

De plus, certaines pages NOINDEX sont volontairement exclues de l'index pour éviter le contenu dupliqué (fiches produits variantes, pages de filtre, versions imprimables) mais restent accessibles aux utilisateurs. Si ces pages génèrent du trafic direct ou par campagne, le JSON-LD peut améliorer l'expérience utilisateur via des extensions de navigateur, des outils de lecture ou des assistants vocaux qui parsent les données structurées. Le retirer purement pour satisfaire Google est donc discutable.

Dans quels cas cette règle ne s'applique-t-elle pas vraiment ?

Imaginons une page en NOINDEX mais accessible via le sitemap XML ou indexée temporairement avant que Google ne revoie la directive. Durant cette fenêtre, le JSON-LD peut techniquement être exploité. Mais ce scénario est rare et imprévisible, donc peu fiable pour une stratégie SEO.

Autre cas limite : les pages AMP en NOINDEX mais avec une version canonique indexée. Si le JSON-LD n'est présent que sur la version AMP bloquée, Google ne l'associera pas à la canonique. Il faut donc toujours placer le marquage sur la version canonique indexée, jamais uniquement sur une variante technique exclue de l'index.

Que faut-il faire concrètement sur un site en production ?

Première action : auditer toutes les pages NOINDEX qui contiennent du JSON-LD. Utilisez un crawler (Screaming Frog, Oncrawl, Sitebulb) avec l'option de détection des balises meta robots et l'extraction des schémas structurés. Croisez les deux datasets pour identifier les pages bloquées portant du marquage.

Ensuite, segmentez ces pages par intention : certaines sont volontairement exclues (pages de remerciement, espaces membres, pages de test), d'autres le sont par erreur de configuration. Pour les premières, retirez le JSON-LD si aucun autre robot ne l'exploite — cela allège le code et simplifie la maintenance. Pour les secondes, corrigez la directive NOINDEX et vérifiez que le marquage reste cohérent.

Quelles erreurs éviter lors de la migration ou refonte ?

L'erreur classique : basculer des pages de INDEX à NOINDEX sans déplacer les schémas critiques vers des pages indexées. Par exemple, une page catégorie bloquée par erreur qui contenait le seul schéma BreadcrumbList du site — résultat, Google perd toute vision de l'arborescence. Avant toute modification de directive d'indexation, faites un inventaire du JSON-LD présent et prévoyez les transferts nécessaires.

Autre piège : utiliser des tags canoniques ET NOINDEX simultanément. Google ignore généralement la canonical sur une page NOINDEX, donc le JSON-LD de la page canonique ne compense pas celui de la page bloquée. Si vous devez consolider des variantes, assurez-vous que la canonical est indexable et porte elle-même le marquage complet.

Comment vérifier que mon site est conforme aux attentes de Google ?

Utilisez la Search Console, section Amélioration > Données structurées. Les pages NOINDEX portant du JSON-LD n'apparaîtront généralement pas dans ce rapport, car Google ne les traite pas. Si vous voyez des erreurs ou avertissements sur des pages que vous pensiez bloquées, c'est un signal que la directive NOINDEX n'est pas appliquée correctement (balise dans un iframe, JavaScript mal exécuté, fichier robots.txt conflictuel).

Complétez avec un test manuel via l'outil d'inspection d'URL : collez une URL NOINDEX, demandez un test en direct, et vérifiez dans l'onglet "Plus d'infos" si Google détecte le JSON-LD. Si oui, il le lit techniquement, mais ne l'exploitera pas. C'est un bon indicateur pour décider si vous devez nettoyer ce code superflu.

• Auditer toutes les pages NOINDEX avec un crawler et extraire le JSON-LD présent.
• Retirer le JSON-LD des pages volontairement exclues si aucun autre canal ne l'exploite.
• Déplacer les schémas critiques (Organization, BreadcrumbList) vers des pages indexées avant toute bascule NOINDEX.
• Ne jamais compter sur une canonical pour transférer le JSON-LD d'une page NOINDEX.
• Vérifier dans la Search Console que les pages bloquées ne génèrent pas d'erreurs de données structurées résiduelles.
• Documenter l'emplacement de chaque schéma stratégique dans un tableau de bord centralisé pour éviter les pertes en refonte.