Sommaire de l’article
Le test se déroule en quatre portes: cohérence avec le contenu visible, validité syntaxique, découverte après déploiement et comparaison de performance. Passer une porte ne prouve pas que la suivante sera franchie.
Ce que Schema Article peut et ne peut pas faire
Les données structurées donnent aux moteurs des informations explicites sur une page. Pour un article, elles décrivent notamment le titre, l’auteur, les dates et l’image. Google recommande d’ajouter les propriétés applicables, de valider le code et de surveiller la page après déploiement.
Google ne garantit pas l’affichage d’un résultat enrichi, même lorsque le balisage est valide. Il précise aussi qu’aucun schema spécial n’est requis pour AI Overviews ou AI Mode. Le bon objectif est donc l’exactitude et l’éligibilité, pas une promesse de citation.
Porte 1: correspondance avec la page visible
Comparez champ par champ:
| Propriété | Contrôle |
|---|---|
| headline | correspond au titre principal visible |
| author | même personne ou organisation que sur la page |
| datePublished | vraie date de première publication |
| dateModified | changement éditorial substantiel et visible |
| image | pertinente, accessible et indexable |
| mainEntityOfPage | URL canonique de l’article |
Ne balisez pas un auteur absent de la page. Ne changez pas dateModified à chaque build. N’ajoutez pas une FAQ structurée si les questions et réponses ne sont pas visibles.
Porte 2: validation automatisée
Testez le JSON-LD comme JSON, puis utilisez le Rich Results Test pour les fonctionnalités Google et Schema Markup Validator pour le vocabulaire schema.org. Corrigez les erreurs critiques et examinez les avertissements.
Ajoutez un contrôle dans la CI: extraction de tous les blocs application/ld+json, parsing, unicité des URLs canoniques et présence de l’auteur lorsque le gabarit l’exige. Ce contrôle évite les régressions de template.
Porte 3: vérification après déploiement
Le HTML local ne prouve pas ce que sert la production. Après publication, ouvrez l’URL sans authentification, vérifiez le code 200, le canonical, le JSON-LD rendu et l’accès à l’image. Utilisez ensuite l’inspection d’URL de Search Console lorsque c’est pertinent.
Soumettez un sitemap à jour. L’indexation et l’affichage restent à la discrétion de Google et peuvent prendre du temps.
Porte 4: mesure sans fausse causalité
Google suggère un test avant/après sur des pages comparables et suffisamment observées. Conservez plusieurs mois de données si le trafic le permet, choisissez des pages peu saisonnières et évitez de modifier simultanément le titre, le contenu, le maillage et le schema si vous cherchez à isoler l’effet du balisage.
Mesurez impressions, clics, CTR et apparence dans les rapports de résultats enrichis disponibles. Une corrélation n’est pas une preuve causale, mais un protocole stable rend la décision plus défendable.
Checklist de mise en production
- Le type Article correspond au contenu principal.
- Chaque propriété décrit un élément réel.
- L’auteur dispose d’une URL stable.
- Les dates sont en ISO 8601 et honnêtes.
- L’image est crawlable et pertinente.
- Le JSON est valide.
- Le canonical et mainEntityOfPage concordent.
- La page est testée en production.
- Les erreurs Search Console sont surveillées.