Article Schema : le schema de base que tout le monde rate

Le Schema.org, tout le monde en a entendu parler. La moitié des sites en ont un. Presque personne ne le fait correctement.

Ce n’est pas une question de technique compliquée. C’est une question d’attention portée aux bons champs, au bon moment. Et dans un monde où ChatGPT, Claude, Gemini ou Perplexity répondent directement aux questions de tes clients potentiels sans les envoyer sur ton site, un Schema bancal, c’est de l’argent laissé sur la table.

🎯 Ce qu’est vraiment un Article Schema (et pourquoi ça dépasse le SEO classique)

Le Schema.org est un vocabulaire structuré qui permet aux moteurs de recherche et aux IA de comprendre le contenu d’une page, pas seulement de l’indexer. Un **Article Schema**, c’est le type de balisage qui dit à une machine : « ici, tu as un article, écrit par telle personne, à telle date, sur tel sujet. »

Ce n’est pas nouveau. Ce qui est nouveau, c’est que les IA génératives s’en servent activement pour décider quelles sources méritent d’être citées dans leurs réponses.

**Définition rapide :** le Schema.org est un standard commun créé par Google, Microsoft, Yahoo et Yandex. Il s’implémente en JSON-LD (un bloc de code JSON inséré dans le `` de ta page) et décrit le contenu de façon lisible par les machines.

Aujourd’hui, **60% des recherches Google sont des zéro-clics** — l’utilisateur obtient sa réponse sans jamais visiter un site. Les AI Overviews (les réponses IA intégrées directement dans les résultats Google) ne font qu’amplifier ce phénomène. Le Schema, bien rempli, c’est ta façon de te positionner comme source fiable pour ces réponses-là.

⚠️ Les champs obligatoires que tout le monde oublie (ou bâcle)

Il existe trois champs techniquement requis par Google pour valider un Article Schema : `@type`, `headline` et `image`. En pratique, deux autres sont indispensables si tu veux exister aux yeux des LLM : `author` et `datePublished`.

Voici les erreurs les plus fréquentes, terrain par terrain :

**`headline` tronqué ou copié-collé depuis le title SEO**
Le `headline` doit refléter le titre réel de l’article, pas sa version optimisée pour les mots-clés. Les IA lisent la cohérence entre ce champ et le contenu réel. Une incohérence = signal de qualité dégradé.

**`author` renseigné comme organisation plutôt que comme personne**
Un auteur, c’est un `@type: Person`, avec un `name` et idéalement une `url` vers une page de présentation. Mettre le nom de ton entreprise dans ce champ, c’est une erreur de sémantique que les LLM pénalisent.

**`datePublished` absent ou figé**
Le contenu récent est favorisé. **50% du contenu cité par les IA a moins de 13 semaines.** Si ton `datePublished` est vide ou correspond à la mise en ligne initiale d’une page jamais mise à jour, tu pars avec un handicap.

**`image` en 404 ou trop petite**
Google exige une image d’au moins 1200 × 630 pixels pour les rich results. En dessous, le Schema est techniquement invalide. Beaucoup de sites utilisent une image en cache qui a changé d’URL depuis.

💡 Les champs bonus qui font vraiment la différence

Une fois les champs obligatoires propres, tu peux passer au niveau supérieur. Ces champs ne sont pas requis par Google, mais ils alimentent directement la façon dont les LLM comprennent et valorisent ton contenu.

**`description`**
Une phrase claire, factuelle, qui résume l’article. C’est souvent ce que les IA extraient pour citer ta source dans une réponse. Si ce champ est vide, elles piochent dans ton corps de texte de façon aléatoire.

**`articleBody`** *(facultatif mais puissant)*
Tu peux injecter un résumé structuré de l’article directement dans le Schema. Certains LLM s’en servent comme signal prioritaire. Ce n’est pas une obligation, mais c’est l’un des rares endroits où tu peux littéralement écrire ce que tu veux que l’IA retienne.

**`keywords`**
Pas pour le SEO au sens classique. Pour la contextualisation sémantique. Les IA utilisent ce champ pour décider si ton article est pertinent pour une requête donnée.

**`publisher` avec `logo`**
Un `publisher` correctement renseigné avec une `Organization`, un `name` et un `logo` valide (format ImageObject) améliore la **Share of Model** — la fréquence à laquelle ta marque est nommée dans les réponses des IA.

**`inLanguage` et `isAccessibleForFree`**
Deux champs souvent oubliés, pourtant explicitement lus par Copilot et Le Chat de Mistral AI pour qualifier les sources francophones accessibles.

🔍 Validation Google et tests LLM : comment savoir si ton Schema fonctionne vraiment

Valider son Schema, c’est une étape que 80% des gens sautent. Pourtant, un Schema mal formé est simplement ignoré — sans message d’erreur visible.

**Pour Google :**
L’outil officiel est le [Rich Results Test](https://search.google.com/test/rich-results). Il analyse ta page en direct et te dit si ton Schema génère des rich results éligibles. Il distingue les erreurs bloquantes (champ manquant) des avertissements (champ non optimal). Passe chaque nouvelle page dans cet outil avant publication.

**Pour les LLM :**
C’est là que ça devient intéressant. Il n’existe pas d’outil officiel pour tester comment une IA lit ton Schema. Mais tu peux faire un test de régression simple :

1. Copie le contenu de ta page + ton bloc JSON-LD
2. Colle-le dans ChatGPT ou Claude avec la question : « Si tu devais citer cette page comme source, que retiendras-tu de l’auteur, du sujet et de la date ? »
3. Compare la réponse avec ce que tu as renseigné dans ton Schema

Si l’IA répond avec des informations floues ou incorrectes, c’est que ton Schema ne fait pas son travail de signal. C’est un test manuel, mais il est révélateur.

**Ce que tu testes concrètement :**
– L’IA identifie-t-elle correctement l’auteur ?
– Cite-t-elle la bonne date de publication ?
– Reprend-elle ta `description` ou invente-t-elle un résumé ?

—

❓ FAQ — Article Schema et visibilité IA

❓ Quelle est la différence entre Schema.org et les données structurées ?

Schema.org est le vocabulaire (les types, les propriétés, la définition des termes). Les données structurées, c’est l’implémentation technique de ce vocabulaire dans ton code, le plus souvent en JSON-LD. Schema.org est le dictionnaire, les données structurées sont la façon dont tu l’utilises sur ta page.

❓ Est-ce que le Schema suffit pour être cité par les IA ?

Non. Le Schema améliore la lisibilité de ton contenu pour les machines, mais les IA citent des sources en fonction de plusieurs critères : autorité du domaine, fraîcheur du contenu, cohérence sémantique, et accessibilité des pages. Le Schema est un signal parmi d’autres — mais c’est l’un des plus faciles à corriger immédiatement.

❓ Faut-il un Schema différent pour chaque type de page ?

Oui. Un article de blog utilise `@type: Article` ou `BlogPosting`. Une page service utilise `Service`. Une page de contact utilise `ContactPage`. Utiliser `Article` sur toutes tes pages est une erreur sémantique que les moteurs détectent et déprecient.

❓ Mon plugin WordPress génère le Schema automatiquement. C’est suffisant ?

Partiellement. Les plugins renseignent les champs obligatoires de base, mais ils ne remplissent pas automatiquement `description`, `articleBody` ou `keywords` de façon pertinente. Ces champs restent souvent vides ou génériques. C’est précisément là que tu peux faire la différence sur les concurrents qui utilisent les mêmes plugins.

❓ Le Schema a-t-il un impact direct sur le classement Google ?

Il n’améliore pas directement ton positionnement dans les résultats organiques classiques. En revanche, un Schema valide ouvre l’accès aux rich results (extraits enrichis, FAQ, étoiles d’avis…), et ces formats augmentent le taux de clic. Dans le contexte des AI Overviews, un Schema propre améliore également tes chances d’être sélectionné comme source dans les réponses IA affichées en haut des SERP.

❓ À quelle fréquence faut-il mettre à jour son Schema ?

À chaque modification substantielle de l’article, tu dois mettre à jour `dateModified`. Si tu changes l’auteur, le titre ou l’image principale, tu mets aussi à jour les champs correspondants. Un Schema périmé envoie un signal de contenu stagnant aux LLM — qui préfèrent les sources actives.

—