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é.
Illustration générée par IA · Écran et fiches de données. Scène illustrative.
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.
| 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 .
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.
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.
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.
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é.
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.
04 / Références officielles
Références officielles
Présenter un contexte
APPROFONDISSEMENT / PRATIQUE
Contrôler la cohérence au-delà de la syntaxe
La qualité d’un dispositif web se vérifie sur des pages et des interactions réelles. Un contrôle doit expliquer le défaut, son effet pour le lecteur et la manière de reconnaître une correction satisfaisante.
Complément éditorial ajouté le .
Situation de départ
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.
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.
Appliquer la démarche sur un premier cas
Choisir un parcours court avec une entrée, une information recherchée et une action finale. Décrire le résultat attendu avant de l’exécuter. Ajouter un cas dégradé ou une variante de contenu afin de repérer les conditions dans lesquelles le dispositif cesse de fonctionner correctement ou devient difficile à comprendre.
Restituer le résultat et ses limites
Après une modification, refaire le cas qui a révélé le défaut et examiner les éléments partagés avec les autres pages. Conserver l’exemple corrigé et le résultat de la recette permet de distinguer une amélioration confirmée d’un changement simplement publié. Les anomalies restantes doivent être décrites avec leur périmètre exact.
CAS PRATIQUE / EXEMPLE PÉDAGOGIQUE
Des objets valides décrivent deux identités différentes
L’exemple est une situation pédagogique de contrôle web. Il relie le défaut à un parcours concret et décrit une manière de vérifier la correction, plutôt que considérer la seule publication du changement comme une preuve de résolution.
Contexte de l’exemple
Une page et son pied de page déclarent la même organisation avec des noms et URLs différents. La syntaxe est correcte, mais les objets donnent des informations incompatibles.
Démarche proposée
Inventorier les identifiants et les propriétés répétées. Comparer aux informations visibles et déterminer la référence maintenue. Contrôler les relations entre les objets après correction.
Conclusion et prochaine étape
L’anomalie est documentée comme incohérence de fond. Le résultat de validation reste un contrôle de syntaxe et ne remplace pas la vérification de l’identité décrite.
Liste de contrôle pour appliquer cet exemple
- Décrire le parcours et le résultat attendu avant la modification.
- Reproduire le défaut avec des conditions et contenus identifiables.
- Examiner les composants partagés et les pages qui en dépendent.
- Refaire le cas corrigé et conserver les limites de la recette.
Questions pour approfondir la pratique
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.
Comment choisir les pages à retester après une correction ?
Partir du composant ou de la règle modifiée, puis identifier les pages qui l’utilisent. Retester le cas initial et quelques variantes réellement différentes : contenu long, interaction, langue ou largeur. Le relevé indique les situations observées et celles qui restent hors du contrôle pour éviter de présenter une recette partielle comme une validation exhaustive.
Que conserver pour permettre à une autre personne de reproduire le défaut ?
Noter URL, étape, conditions utiles, résultat attendu et résultat obtenu. Un exemple de saisie non sensible ou une capture peut compléter le relevé. Préciser l’état du dispositif et les éventuelles étapes préparatoires facilite la reprise, surtout lorsque l’anomalie dépend d’un cache, d’une session ou d’une variante de contenu.
ATELIER DÉTAILLÉ / MISE EN APPLICATION
Retrouver la cause d’une incohérence répétée
Cet atelier propose une séquence en cinq étapes pour appliquer les repères de la page. Les entrées, les observations et la conclusion sont conservées ensemble afin de faciliter la vérification et la reprise du travail.
01 / Préparer les informations utiles
Préparer les objets déclarés, leurs identifiants et les pages où ils apparaissent. Choisir les propriétés dont les valeurs divergent ou ne correspondent plus au contenu visible.
02 / Exécuter la démarche
Comparer occurrences et modèles de production. Vérifier relations, URLs et dates. Corriger la source commune lorsque l’erreur se répète, puis valider les pages qui en dépendent.
03 / Examiner une situation alternative
Si les différences décrivent réellement deux objets, conserver des identifiants distincts. Une consolidation automatique peut effacer une séparation nécessaire à la compréhension.
04 / Décider de la suite
La correction est validée lorsque les valeurs et relations sont cohérentes dans le périmètre contrôlé. Les avertissements et contradictions de fond restent distingués dans le relevé.
05 / Transmettre les éléments de contrôle
Transmettre objets, propriétés, anomalies et résultats. Le dossier doit expliquer pourquoi une valeur a été retenue et permettre de revoir sa justification après une évolution du contenu.
LIVRABLE COMMENTÉ / GRILLE DE LECTURE
Un registre d’incohérences entre objets et occurrences
Le registre décrit identifiant, propriété, occurrence et divergence. Il permet de retrouver la cause commune d’une erreur répétée et de distinguer plusieurs objets qui doivent rester séparés.
Sur petit écran, faites défiler la grille pour lire les trois colonnes.
| Élément observé | Interprétation permise | Suite à prévoir |
|---|---|---|
| Les occurrences décrivent le même objet de façon cohérente. | Les valeurs communes concordent dans les pages examinées. | Conserver l’inventaire et contrôler les relations entre objets. |
| Un modèle produit une valeur fausse sur plusieurs pages. | La correction doit viser la source partagée et ses résultats. | Modifier le modèle puis retester les objets dépendants. |
| Des objets différents sont réunis sous le même identifiant. | Le rapprochement peut effacer une distinction utile à la lecture. | Examiner leur identité et attribuer des références cohérentes aux objets distincts. |
Relecture du livrable
Le relecteur doit pouvoir remonter d’une anomalie à son origine. Les différences légitimes sont expliquées au lieu d’être corrigées automatiquement comme si toute variation constituait une erreur.
RESTITUTION / EXEMPLE DE FORMULATION
Restitution : Contrôler la cohérence au-delà de la syntaxe
Point à clarifier
Une correction de modèle doit être vérifiée dans les objets qu’il produit.
Avant de transmettre
Relier chaque clôture à une occurrence contrôlée plutôt qu’à la seule modification du modèle.
Exemple de conclusion qualifiée
La source de la valeur a été corrigée et les occurrences dépendantes ont été examinées. Les différences légitimes entre objets sont conservées avec leur justification.