Commencer par un article dont on connaît les informations
Le premier contrôle est plus simple sur une page récente, dont la rédaction connaît l’auteur, la date et l’image retenue. Un ancien article importé peut ensuite révéler d’autres défauts, mais il cumule parfois des incertitudes qui compliquent le diagnostic. Pour ce premier essai, l’équipe peut préparer une fiche très courte avec l’adresse publique et les informations qu’elle s’attend à retrouver.
Imaginons un cas fictif : un média professionnel publie une enquête signée par deux journalistes, accompagnée d’une photo de terrain. L’article a été corrigé après publication pour préciser une date. La fiche de contrôle reprend ces éléments sans leur attribuer d’effet SEO. Elle servira à examiner la page et à poser des questions précises à la personne qui maintient le site.
Le vocabulaire Article de Schema.org décrit des articles, notamment de presse, et possède de nombreuses propriétés. La documentation Google constitue un autre niveau : elle indique les types et propriétés pris en charge pour ses usages. Une propriété disponible dans Schema.org n’est donc pas, à elle seule, une promesse de présentation particulière dans Google.
Ce point évite une mauvaise commande au prestataire : « remplir tous les champs ». Certains champs ne correspondent pas au contenu publié, d’autres ne servent pas l’objectif du contrôle. La rédaction doit fournir les informations exactes dont elle dispose. L’équipe technique peut ensuite expliquer lesquelles elle transmet, d’où elles proviennent et comment elles seront entretenues au fil des publications.
Examiner le résultat produit par le site
Le contrôle porte sur l’adresse publiée. Un réglage enregistré dans une extension indique une intention ; il reste à regarder ce que le thème et les outils installés produisent ensemble. La personne qui maintient le site peut extraire les données structurées et présenter leurs valeurs dans une forme lisible. Constater qu’un nom ou une image ne correspond pas à l’article n’exige pas de maîtriser toute la syntaxe.
La documentation Article de Google cite les types Article, NewsArticle et BlogPosting. Elle présente des propriétés recommandées, à renseigner lorsqu’elles s’appliquent au contenu. Qualifier toutes les pages du site d’articles d’actualité dans l’espoir d’un avantage ne découle pas de cette documentation.
Pour notre enquête fictive, le relevé peut contenir à la fois une description de l’article et des objets décrivant le site ou son organisation. Leur coexistence ne suffit pas à conclure à un défaut. Deux descriptions du même article qui portent des signatures contradictoires demandent, en revanche, une explication : quel outil fournit chacune de ces valeurs ?
Cette recherche détermine l’étendue de la correction. Un modèle commun défectueux peut toucher de nombreuses pages ; retoucher un seul article laisserait les autres en l’état. Une attribution issue d’un ancien import peut au contraire concerner uniquement certaines archives. Avant de supprimer un bloc de balisage, il faut comprendre d’où il vient et quelles pages utilisent la même information.
Rapprocher les champs des décisions de la rédaction
Le guide Article de Google documente notamment le titre, l’auteur, les dates et l’image. L’auteur peut être une personne ou une organisation ; l’image doit représenter le contenu. Les dates de première publication et de modification correspondent à des événements différents. Ces repères permettent une vérification concrète, mais le CMS doit encore fournir les bonnes valeurs pour chaque article.
Dans l’enquête fictive, la signature collective ne doit pas devenir le nom du compte administratif utilisé pour mettre en ligne le texte. La rédaction peut expliquer qui a réalisé le travail et comment cette attribution apparaît au lecteur. Si elle ne sait plus attribuer certaines archives, elle doit traiter cette incertitude au lieu d’inventer une personne pour compléter un champ. Le guide sur les pages auteurs d’un média développe le travail d’attribution et de présentation publique.
Le contrôle de l’image suit une logique voisine. La photo attendue est-elle bien celle qui accompagne le sujet ? Son adresse correspond-elle au fichier retenu ? Si le relevé montre un logo, il faut savoir s’il s’agit d’une donnée d’organisation ou de l’image qui décrit l’article. Une erreur d’interprétation du relevé pourrait conduire à modifier un élément qui remplissait correctement son rôle.
Pour les dates, la rédaction apporte l’historique qu’elle connaît. Une correction de contenu et une opération de maintenance du site ne racontent pas la même chose au lecteur. Le guide sur les dates de publication et de mise à jour aide à définir cette politique. Le contrôle du balisage vérifie ensuite que les valeurs produites correspondent à la politique retenue, au lieu de laisser chaque outil décider seul.
Ce qu’un test valide permet de conclure
Le test des résultats enrichis de Google accepte une URL ou un extrait de code. Il affiche les éléments détectés ainsi que les erreurs et suggestions. Pour tester une URL, les ressources doivent être accessibles au service depuis Internet sans authentification. Un test de code peut aider à préparer une correction, mais il ne prouve pas que cette correction a été déployée sur la page publique.
Lors d’une livraison, ces deux essais peuvent facilement être confondus. Une capture verte portant sur un exemple de code répond à une question de préparation. Il reste à tester l’adresse publique pour savoir ce qui a effectivement été livré. Le compte rendu doit préciser ce qui a été testé, à quelle date et sur quelle version. Sans ces repères, deux personnes peuvent parler de résultats différents en croyant décrire le même état.
Un outil peut lire correctement une valeur qui reste fausse. Le nom du compte d’import peut être une chaîne de caractères parfaitement valide ; seul le rapprochement avec la signature de l’enquête révèle le défaut. Les consignes générales de Google sur les données structurées demandent un balisage représentatif du contenu et rappellent les limites des contrôles automatisés de qualité.
Ces mêmes consignes précisent qu’un balisage correct ne garantit pas son affichage dans les résultats. La rédaction peut donc considérer une erreur technique corrigée comme un résultat réel, sans annoncer un gain de classement ou de trafic. La visibilité devra être observée séparément. Un contrôle de données structurées ne mesure pas non plus la probabilité qu’un assistant IA cite l’article.
Élargir le contrôle aux cas qui peuvent se comporter autrement
Une page récente ne représente pas tout le catalogue. Après le premier essai, la rédaction peut choisir quelques cas qui utilisent d’autres chemins de publication : article importé, texte à plusieurs auteurs, contenu signé par la rédaction, enquête mise à jour, article avec un accès réservé. Le choix vient des différences du site. Il n’existe pas de nombre d’URL qui garantisse, à lui seul, que toutes les archives fonctionnent.
Pour chaque cas, l’équipe note la valeur attendue et celle qui a été observée. Le signalement devient alors plus précis que « le schéma est mauvais », et les défauts semblables peuvent être regroupés. Si tous les articles importés portent la même attribution inattendue, l’hypothèse d’un problème d’import mérite d’être examinée. Elle reste une hypothèse jusqu’à la vérification de la chaîne qui fournit cette donnée.
Les contenus payants demandent une attention spécifique. Le guide Google Article renvoie à une documentation consacrée aux contenus accessibles par inscription ou abonnement. Il faut examiner ce cas avec la personne chargée du site, sans ouvrir l’accès public à un texte réservé pour faire réussir un test. La stratégie d’accès et le balisage doivent être traités ensemble, avec une vérification adaptée au service proposé aux lecteurs.
L’équipe peut conserver les pages de cet échantillon pour les prochains changements de thème ou d’extension. Le résultat attendu est connu : le prochain contrôle pourra repartir de ces cas plutôt que choisir de nouvelles pages au hasard. Il n’est pas nécessaire de refaire tout le catalogue après chaque correction de phrase ; le contrôle élargi devient pertinent lorsque la manière de produire les métadonnées change ou lorsqu’une anomalie suggère un défaut partagé.
Livrer une correction que l’on pourra retrouver
Une correction exploitable comporte l’adresse concernée, la valeur précédente, la valeur retenue et l’origine du défaut lorsqu’elle a été confirmée. Dans notre exemple, « remplacer l’auteur d’import par les deux signatures de l’enquête » décrit mieux le résultat attendu que « optimiser le SEO ». Cette formulation permet à la rédaction de vérifier le travail sans devoir croire une appréciation générale.
Après la modification, le contrôle reprend la page publique et les cas voisins qui pouvaient être affectés. L’équipe vérifie aussi l’affichage visible : une modification du champ auteur ne doit pas casser les liens vers les signatures. Le relevé final peut ainsi indiquer ce qui a été contrôlé dans les données et dans la page visible, ainsi que les archives qui restent éventuellement à traiter.
Si Google affiche encore une ancienne information, il faut distinguer ce que le site sert maintenant de ce que le moteur a déjà exploré. La date du contrôle de la page ne devient pas automatiquement une date de prise en compte dans les résultats. Ce décalage ne prouve pas un échec de la correction, et il ne permet pas non plus d’affirmer qu’elle sera affichée plus tard sous une forme particulière.
La personne responsable du modèle doit enfin savoir quelles informations la rédaction fournit et comment signaler une exception. Une nouvelle signature collective, un changement de fournisseur d’images ou une reprise d’archives peut justifier une vérification ciblée. Ces changements donnent une raison précise de rouvrir le relevé. L’équipe peut vérifier les pages concernées et retrouver le réglage à corriger si les valeurs ne correspondent plus au contenu publié.
Sources officielles
Documents utilisés pour vérifier les points techniques de cet article.