Choisir les pages et les types
Inventoriez les modèles de pages, les types de schéma réellement utiles et les variantes linguistiques. Écartez les types sans relation avec le contenu.
GUIDE / PROTOCOLE
Contrôler les données structurées
Un balisage valide ne compense ni une page ambiguë, ni une information absente, ni une identité mal établie.
Réponse directe
Comment auditer les données structurées sans confondre syntaxe et vérité ?
Partez de la page rendue et de son URL canonique. Relevez les entités et propriétés déclarées, confrontez chaque affirmation au contenu visible, puis vérifiez la syntaxe et les critères du type de résultat visé.
01 / Méthode de contrôle
Méthode de contrôle
Comparer HTML et balisage
Contrôlez noms, auteurs, dates, images, liens et relations dans le HTML visible et dans le JSON-LD. Rendez visible une information importante ou retirez-la du balisage.
Valider à deux niveaux
Utilisez un validateur Schema.org pour la structure, puis le test de résultat enrichi pour les fonctionnalités Google concernées. Notez erreurs et avertissements séparément.
Rejouer après changement
Testez les modèles et quelques pages réelles après déploiement, puis surveillez les rapports disponibles. Vérifiez aussi les autres langues et les URL canoniques.
EN PRATIQUE
Une correction est terminée quand ses conséquences sont relues
Une page appartient à un ensemble : résumé, titre, tableaux, liens, versions linguistiques et données structurées. Corriger une phrase exige de retrouver les endroits où elle est reprise, puis de vérifier que chaque version raconte encore la même chose.
Quel contrôle effectuer en premier ?
Choisissez la situation observée. Chaque piste précise une première vérification, la preuve utile et la limite de ce contrôle.
Deux pages donnent des informations incompatibles
- Premier contrôle
- Isolez la même affirmation sur les deux pages, puis comparez source, date de validité et périmètre. Désignez la page de référence et le responsable de l’arbitrage avant de recopier une correction partout.
- Preuve à conserver
- Deux URL, formulations exactes, références, date d’effet, décision retenue et liste des pages ou extraits qui reprennent l’information.
- Limite à garder en tête
- La page la plus récente n’est pas forcément la plus juste. Un changement de date de publication ne résout pas une différence de définition ou une source manquante.
Les versions linguistiques ne disent plus la même chose
- Premier contrôle
- Comparez une affirmation sensible dans chaque langue : nombre, date, condition, exclusion et lien source. Identifiez la version validée et les traductions réellement synchronisées.
- Preuve à conserver
- URL de chaque langue, identifiant du contenu, passage, version source, date de validation et écart encore ouvert.
- Limite à garder en tête
- Une navigation traduite et des liens de langue corrects ne prouvent pas l’équivalence du fond. Une mise à jour partielle doit rester visible pour les personnes chargées de publier.
Les données structurées contredisent la page visible
- Premier contrôle
- Reliez chaque propriété importante au passage affiché : identité, date, offre ou question-réponse. Vérifiez d’abord le contenu et la correspondance, puis la syntaxe du balisage.
- Preuve à conserver
- URL, type de balisage, propriété, valeur déclarée, passage visible et résultat du contrôle après correction.
- Limite à garder en tête
- Un validateur syntaxique ne confirme ni la vérité ni l’éligibilité à un affichage enrichi. Ne balisez pas un contenu absent ou trompeur pour tenter de corriger sa visibilité.
Pour approfondir
| Situation | À éviter | Correction utile |
|---|---|---|
| Chiffre corrigé | Modifier seulement le paragraphe. | Relire tableau, légende, synthèse et donnée structurée associés. |
| Page déplacée | Changer le lien visible uniquement. | Vérifier destination, ancre et retour vers le parcours. |
| Version traduite | Copier les mots en conservant un exemple devenu faux. | Relire aussi unité, date, source, liens et portée du résultat. |
Repérer
Quelles affirmations dépendent de la modification ?
Propager
Quelles pages et langues les reprennent ?
Relire
Les nombres, liens et limites concordent-ils partout ?
Contrôle final
Une date de mise à jour signale une édition réelle. Elle ne redéfinit ni la date de la source ni celle de l’observation. Conservez ces rôles distincts dans le texte et les références.
Références documentaires
Consulté le .
Atelier de lecture
Un JSON lisible qui attribue le mauvais auteur
La page DEMO est un article français signé Lina DEMO. Le laboratoire DEMO y est présenté séparément comme organisme ; les objets n’ont aucune existence réelle.
Données et traces fictives pour apprendre : aucun résultat présenté ici ne provient d’un service interrogé en direct.
Quatre vérifications après la syntaxe
Le balisage fictif mélange identité, attribution et langue. Aucun validateur externe n’est exécuté ici : le tableau montre ce qu’un examen du rendu doit distinguer.
Si le tableau dépasse l’écran, faites-le défiler horizontalement ; les flèches du clavier fonctionnent lorsque la zone est sélectionnée.
| Contrôle | État DEMO | Ce que cela établit | Correction à examiner |
|---|---|---|---|
| Syntaxe JSON | Accolades, chaînes et tableaux bien formés | Le texte peut être analysé comme JSON | Poursuivre le contrôle sémantique. |
| Identité @id | Même #entity pour Lina et le laboratoire | Deux objets distincts confondus dans ce cas | Donner des identifiants cohérents aux objets réellement décrits. |
| Auteur de l’article | Lina visible ; laboratoire dans author | Attribution non conforme à la page | Reprendre l’auteur étayé, sans transformer l’organisme en personne. |
| Langue déclarée | Article français ; inLanguage=en | La déclaration vise une autre langue | Vérifier l’entité article et cette variante de page. |
Qu’autorise un contrôle syntaxique réussi ?
Ouvrir chaque proposition pour comparer son diagnostic. Plusieurs contrôles peuvent rester nécessaires.
Certifier l’auteur et l’identité des entités
Non. Les valeurs peuvent être grammaticalement valides tout en désignant le mauvais objet.
Promettre un résultat enrichi dans le moteur
Non. L’éligibilité et la présentation ne sont pas une conséquence garantie de la syntaxe.
Continuer par l’identité, le contenu visible et les règles du type
Oui. Noter séparément syntaxe, cohérence éditoriale et contrôle des critères applicables.
Trace fictive d’audit du balisage
Page : article DEMO en français Auteur visible : Lina DEMO Anomalie : #entity partagé personne/organisme Anomalie : author pointe vers le laboratoire Anomalie : inLanguage=en pour cet article français Décision : balisage à corriger, aucun résultat enrichi certifié
Les fragments #entity et inLanguage sont des indices d’exemple. Ils ne sont pas des constats sur le code de ce site et ne constituent pas un schéma complet à copier.
Documentation des règles, distincte des exemples fictifs
02 / Preuves à conserver
Preuves à conserver
Inventaire de modèles
URL, type de page, schéma attendu, propriétaire éditorial et date de contrôle.
Comparaison des champs
Valeur balisée, preuve dans la page, source du champ et écart éventuel.
Rapport de validation
Outil, URL testée, date, erreurs, avertissements et capture du résultat.
Décision de correction
Champ corrigé ou supprimé, responsable et vérification après publication.
Comparer avec les autres situations et exercices
POINT DE CONTRÔLE
Avant de conclure
Une erreur de lecture fréquente et la vérification qui permet de l’éviter.
Conclusion trop rapide
Une syntaxe JSON-LD valide ne suffit pas si le balisage décrit une information absente, ancienne ou contredite par la page visible.
Contrôle décisif
Comparer chaque propriété importante au contenu affiché, à l’URL canonique et au type attendu. Valider séparément la syntaxe et les règles du moteur visé, puis contrôler le rendu après déploiement.
APRÈS LE CONTRÔLE
Décider selon le constat
Le JSON-LD est valide mais décrit une information absente de la page
Corrigez le balisage ou rendez le fait visible et vérifiable. La validité syntaxique ne remplace pas la cohérence avec le contenu lu.
Deux pages déclarent la même entité avec des attributs contradictoires
Choisissez une source éditoriale de référence, harmonisez les champs et contrôlez les traductions avant une nouvelle validation.
Arbitrage et trace de décision
Arbitrage et trace de décision
Ce que le contrôle doit permettre de décider, et la preuve à conserver pour réexaminer ce choix.
Preuve suffisante
Comparer le JSON-LD rendu au texte visible, à l’URL canonique et aux propriétés requises du type choisi. Vérifier plusieurs gabarits et langues, pas un seul exemple.
Décision suivante
Supprimer les propriétés non étayées, corriger les champs incohérents puis valider le HTML rendu. Documenter les types réellement utilisés et leur entretien éditorial.
Cas de contrôle approfondis
Situations types pour préparer un contrôle. Elles ne décrivent pas des missions ou observations réalisées.
Le balisage promet plus que le texte
Ce qu’il faut examiner
Relier chaque propriété structurée à une information visible et à sa pièce justificative.
Décision et action
Retirer les valeurs non soutenues ; un balisage valide syntaxiquement ne valide pas une note, un prix ou une relation.
Preuve à conserver
Propriété, texte visible, preuve et correction retenue.
Un identifiant désigne deux objets
Ce qu’il faut examiner
Comparer les occurrences du même @id dans les pages et leurs attributs d’identité.
Décision et action
Réserver l’identifiant à un objet cohérent ; distinguer personne, organisation et page sans multiplier les identités du même objet.
Preuve à conserver
Occurrences, objets concernés et règle d’identification corrigée.
Le balisage dépasse le contenu visible
Ce qu’il faut examiner
Comparer assertions du JSON-LD, texte affiché et sources associées.
Décision et action
Retirer ou corriger les propriétés que la page ne justifie pas.
Preuve à conserver
Propriété, valeur visible, source et résultat du contrôle.
REPÈRES DOCUMENTÉS
JSON canonique : un contrat précis, pas seulement des clés triées
JCS, décrit dans la RFC informative 8785, définit une représentation déterministe pour des opérations cryptographiques. Son périmètre est plus strict qu’un JSON quelconque et plus complet qu’une suppression des espaces.
| Repère | Valeur ou forme | Ce que cela désigne |
|---|---|---|
| INPUT | I-JSON · noms uniques | Les noms de propriétés doivent être uniques et les données compatibles avec I-JSON. Un parseur ayant déjà écrasé un doublon peut masquer une entrée invalide : contrôler ce point avant la perte d’information. |
| WHITESPACE | aucun blanc entre jetons | Aucun espace entre jetons n’est émis. Cette règle ne supprime pas les espaces contenus dans les chaînes : retirer tous les blancs du texte brut changerait les données. |
| NUMBERS | ECMAScript · IEEE 754 binary64 | Les nombres suivent la sérialisation ECMAScript de valeurs binaires64. NaN et Infinity sont refusés ; les besoins de précision supérieure exigent un contrat de représentation adapté, souvent une chaîne explicite. |
| PROPERTY ORDER | récursif · unités UTF-16 | Le tri s’applique récursivement aux noms décodés, comparés en unités UTF-16 non signées, sans classement linguistique local. Trier les octets UTF-8 ou les points de code peut donner un autre ordre. |
| ARRAY ORDER | conservé | L’ordre des éléments de tableau reste inchangé, même si les objets qu’ils contiennent doivent être traités. Un tri universel des listes modifierait leur sens plutôt que leur seule présentation. |
| UNICODE | conservé · sortie UTF-8 | Les chaînes Unicode restent telles quelles : JCS n’applique pas NFC ou NFKC. La sortie finale est encodée en UTF-8. Une canonicalisation JSON et une normalisation linguistique ne sont pas la même transformation. |
Ordre de référence publié pour sept noms JSON
RFC 8785 § 3.2.3. Les libellés anglais restent ceux du jeu d’essai. Les unités UTF-16 sont explicitées pour rendre le tri vérifiable, notamment pour le caractère hors du plan multilingue de base.
| Nom en points de code | Unités UTF-16 | Libellé source (anglais) |
|---|---|---|
| U+000D | 000D | Carriage Return |
| U+0031 | 0031 | One |
| U+0080 | 0080 | Control |
| U+00F6 | 00F6 | Latin Small Letter O With Diaeresis |
| U+20AC | 20AC | Euro Sign |
| U+1F600 | D83D DE00 | Emoji: Grinning Face |
| U+FB33 | FB33 | Hebrew Letter Dalet With Dagesh |
RFC 8785 § 3.2.3. Copyright © 2020 IETF Trust and the persons identified as document authors. UTF-16 units added for explanation.
À retenir pour le dossier
Une empreinte de sortie JCS doit être annoncée comme telle et accompagnée du profil appliqué. Elle ne remplace pas l’empreinte des octets originaux reçus ; conserver les deux objets si la traçabilité l’exige.
JSON.stringify suffit-il à produire du JCS ?
Pas à lui seul. Il ne vérifie pas toutes les contraintes d’entrée ni le tri récursif requis. L’exemple de tri ci-dessous vient de la RFC et permet notamment de repérer un tri Unicode inadapté.
Documentation primaire
Documentation consultée le .
REPÈRES DOCUMENTÉS
JSON Merge Patch : supprimer, conserver ou remplacer une valeur
Une mise à jour partielle doit annoncer son format. JSON Merge Patch décrit des valeurs à fusionner avec la cible ; JSON Patch décrit une liste d’opérations. Ces deux documents n’ont ni le même type de média ni le même traitement de null. Le simulateur permet d’examiner une fusion sans appeler une API.
| Repère | Valeur ou forme | Ce que cela désigne |
|---|---|---|
| member absent | keep | Une propriété omise du patch reste inchangée si la cible est un objet. Une propriété présente avec null demande sa suppression ; si elle manque déjà, cette demande n’ajoute rien. Une chaîne vide, false et zéro sont des valeurs à conserver, pas des ordres de suppression. |
| member: null | delete | Un patch objet se fusionne récursivement. Si la cible correspondante est un tableau, un scalaire ou null, elle devient d’abord un objet vide. Ainsi, le patch {} appliqué au nombre 7 produit {}, et non 7. |
| {} | object target | Un patch qui n’est pas un objet remplace toute la cible à ce niveau. Un tableau est donc remplacé en bloc : il n’est ni concaténé ni rapproché par indice ou par identifiant. |
| null / [] / scalar | replace | Le null placé à la racine du patch remplace la cible entière par null. Le null membre d’un objet patch supprime ce membre. Pour attribuer explicitement null à une propriété, une opération JSON Patch peut être plus adaptée. |
| JSON values | ≠ text diff | Le calcul concerne les valeurs JSON. Espaces, indentation et ordre de présentation des propriétés ne sont pas préservés. Un résultat de fusion valide peut encore violer le schéma ou les règles métier de l’API. |
Simuler une fusion JSON Merge Patch
Exemples pédagogiques originaux ; aucun document réel n’est modifié.
Deux valeurs JSON, 4 000 unités UTF-16 maximum chacune, profondeur maximale de 20 conteneurs et 500 valeurs par entrée. Profil numérique : entiers écrits sans décimale ni exposant, de −9 007 199 254 740 991 à +9 007 199 254 740 991. Noms de membres uniques ; chaînes Unicode sans substitut isolé. Ces limites appartiennent à cet outil.
Calcul local ; aucune saisie n’est envoyée ou conservée. Le résultat reste affiché dans la page.
Simulation actualisée.
Valeur résultante
{
"title": "B",
"keep": true
}Dix fusions : cible, patch et résultat
| Étape | Cible initiale | Patch à appliquer | Valeur résultante |
|---|---|---|---|
| 1 | {
"title": "A",
"note": "old",
"keep": true
} | {
"note": null,
"title": "B"
} | {
"title": "B",
"keep": true
} |
| 2 | {
"items": [
"A",
"B",
"C"
]
} | {
"items": [
"B"
]
} | {
"items": [
"B"
]
} |
| 3 | [
1,
2
] | {
"x": 1
} | {
"x": 1
} |
| 4 | {
"x": 1
} | null | null |
| 5 | [] | {
"missing": null
} | [] |
| 6 | 7 | [] | [] |
| 7 | {
"a": {
"x": 1,
"y": 2
},
"z": 3
} | {
"a": {
"x": null
}
} | {
"a": {
"y": 2
},
"z": 3
} |
| 8 | {
"a": null,
"b": 5
} | {
"b": 0,
"c": false,
"d": ""
} | {
"a": null,
"b": 0,
"c": false,
"d": ""
} |
| 9 | {
"items": [
"A",
"B"
]
} | {
"items": [
"X"
]
} | {
"items": [
"X"
]
} |
| 10 | {
"__proto__": {
"x": 1
},
"constructor": 2
} | {
"__proto__": {
"y": 3
}
} | {
"__proto__": {
"x": 1,
"y": 3
},
"constructor": 2
} |
À retenir pour le dossier
La simulation ne modifie aucune ressource et ne vérifie ni droits, ni contrat d’API, ni concurrence. Le profil numérique et les limites de saisie protègent la lecture dans le navigateur ; ils ne définissent pas tout JSON. Garder séparément l’identifiant et la version de la cible réellement mise à jour.
Un objet vide signifie-t-il toujours « ne rien changer » ?
Non. Dans Merge Patch, {} conserve une cible objet, mais remplace une cible non objet par un objet vide. Le sens dépend donc du type de la cible au même niveau. Un test de schéma après la fusion reste distinct de cette règle.
Documentation primaire
Documentation consultée le .
Relecture avant décision
Ces questions complètent la méthode. Elles aident à vérifier ce qui est réellement établi, sans effacer les réserves du relevé.
Faits visibles
Chaque date, prix, rôle, avis ou disponibilité balisés possède-t-il un équivalent visible et justifié ? Retirer les propriétés déduites ou périmées plutôt que remplir les champs artificiellement.
Voir une décision commentée
Exemple fictif : l’état concerne uniquement le critère et le périmètre décrits.
- Observation fictive
- Le JSON-LD affiche un prix de 100 ; la page présente 120 pour la même offre et la même période.
- État déclaré
- Écart observé
- Décision et prochain contrôle
- Rétablir une valeur visible et justifiée commune. Contrôler aussi les variantes et la donnée qui génère le balisage.
Syntaxe et portée
Le type, les propriétés et les relations passent-ils le validateur adapté ? Séparer validité du balisage, règles de la fonctionnalité de recherche et affichage réellement observé.
Voir une décision commentée
Exemple fictif : l’état concerne uniquement le critère et le périmètre décrits.
- Observation fictive
- Le validateur ne signale pas d’erreur ; aucune observation du résultat de recherche n’est disponible.
- État déclaré
- Non vérifié
- Décision et prochain contrôle
- Conserver la validation syntaxique et laisser l’affichage effectif non vérifié. Ne pas promettre de résultat enrichi.
Exemple ou offre actuelle
Le balisage distingue-t-il données fictives, anciennes valeurs et offre réellement visible ? Un exemple pédagogique ne doit pas devenir une promesse commerciale structurée.
Documentation consultée : Google Search Central · Structured data policies ·
Voir une décision commentée
Exemple fictif : l’état concerne uniquement le critère et le périmètre décrits.
- Observation fictive
- Un exercice annonce des données fictives ; son balisage le décrit comme ressource pédagogique, sans offre de vente.
- État déclaré
- Vérifié dans ce périmètre
- Décision et prochain contrôle
- La nature du contenu est cohérente dans ce périmètre. Refaire le contrôle si le contenu devient une offre réelle.
OUTILS / REGISTRES
Informations à relever
Comparer les propriétés déclarées avec le contenu visible et les pièces sources. Un JSON valide peut rester faux ; une validation technique ne remplace pas la vérification éditoriale.
- Date de consultation et fuseau
- URL exacte
- Type de document
- Affirmation à vérifier
- Résultat observé
- Critère de validation
- Décision / prochaine action
- Responsable du contrôle
- Prochain contrôle
03 / FAQ
Questions fréquentes
Le JSON-LD suffit-il à obtenir un résultat enrichi ?
Non. Le type doit être pertinent, la page et le balisage respecter les règles applicables, et l’affichage reste à la discrétion du moteur.
Faut-il baliser toutes les FAQ ?
Non. Une FAQ utile peut rester en HTML sans balisage spécifique ; ne créez pas de questions pour obtenir une fonctionnalité.
Que faire si deux langues ont des titres différents ?
Chaque version doit décrire son propre contenu visible et conserver des URL, noms et langues cohérents.
Peut-on décrire une prestation absente de la page ?
Non. La donnée structurée doit représenter la page et ne pas ajouter une promesse que le lecteur ne peut pas vérifier.
Comment contrôler les valeurs répétées sur plusieurs pages ?
Partir des identifiants et des propriétés communes. Comparer leurs valeurs aux références du site, puis vérifier les modèles qui les produisent pour corriger la cause et les occurrences dépendantes.
04 / Références officielles
Références officielles
05 / Poursuivre la lecture
Poursuivre la lecture
Présenter un contexte
REPÈRES DOCUMENTÉS
Contrat JSON Schema : présent, non nul et propriété autorisée sont trois contrôles
JSON Schema permet de décrire la structure attendue d’un document. Ce repère vise le dialecte 2020-12, qui doit être annoncé et pris en charge par le validateur. Les fragments sont pédagogiques. Les règles d’objet ci-dessous supposent que le contrat demande également type: object ; required seul ne transforme pas une valeur quelconque en objet.
| Repère | Valeur ou forme | Ce que cela désigne |
|---|---|---|
| $schema | https://json-schema.org/draft/2020-12/schema | Cette URI déclare le dialecte. Un validateur configuré pour un autre dialecte peut interpréter certains mots-clés différemment ou ne pas prendre en charge ceux attendus ; conserver le dialecte et la version de l’outil avec le résultat. |
| properties | Propriété présente | Le mot-clé applique un sous-schéma aux propriétés nommées lorsqu’elles existent. Écrire un type pour id dans properties ne rend pas sa présence obligatoire : il faut une contrainte de présence distincte. |
| required: ["id"] | Présence ≠ non-nullité | La liste exige la présence de la clé id dans l’objet. Une valeur null compte comme une propriété présente ; sa validité dépend ensuite du sous-schéma de cette propriété. |
| type: ["string", "null"] | Chaîne ou JSON null | Cette union autorise explicitement une chaîne ou JSON null. Avec required, elle peut imposer une clé tout en autorisant une valeur absente au sens métier ; sans required, la clé peut aussi manquer. |
| additionalProperties: false | Portée des déclarations sœurs | Ce contrôle considère les propriétés et motifs définis dans le même objet de schéma. Dans une composition allOf, il ne découvre pas automatiquement les propriétés déclarées dans un autre sous-schéma. |
| unevaluatedProperties: false | Propriétés évaluées dans les sous-schémas | Ce mot-clé tient compte des propriétés évaluées par les sous-schémas applicables, y compris dans une composition réussie. Il sert à fermer certains schémas composés ; vérifier sa prise en charge réelle plutôt que l’assimiler à additionalProperties. |
À retenir pour le dossier
La conformité structurelle ne prouve pas qu’un identifiant existe dans un registre ni qu’une relation est vraie. Séparer erreur de syntaxe JSON, erreur de schéma et contrôle métier. Un validateur qui ne connaît pas le dialecte ne fournit pas une garantie complète en affichant simplement valide.
Peut-on déclarer id comme chaîne pour obliger chaque objet à avoir un id ?
Non : properties contrôle la valeur si la clé existe. Déclarer type: object, ajouter required pour la présence, puis choisir si null est autorisé. Ces décisions répondent à des besoins différents.
Documentation primaire
- JSON Schema · Object validation guide
- JSON Schema 2020-12 · Validation vocabulary
- JSON Schema 2020-12 · Core and unevaluated properties
Documentation consultée le .
APPROFONDISSEMENT / PRATIQUE
Contrôler la cohérence au-delà de la syntaxe
Un validateur accepte le balisage alors qu’un nom, une date ou une URL ne correspond plus à la page. Le contrôle doit rapprocher les données déclarées des informations affichées.
Mis à jour le .
Vérifications prioritaires
Examiner les objets, leurs identifiants et leurs relations. Vérifier les URLs finales, les dates et les propriétés répétées sur plusieurs pages, puis relever les contradictions.
Pièges d’interprétation
Un avertissement de validation n’a pas toujours le même impact qu’une donnée fausse. La priorité dépend de la propriété, de son usage et de l’information qu’elle cherche à représenter.
Document de travail à conserver
Le registre distingue erreur de syntaxe, propriété absente et contradiction de fond. Chaque correction comporte un contrôle du balisage et de la page visible.