Pourquoi Google abandonne-t-il définitivement le balisage data-vocabulary.org pour les fils d'Ariane ?

Qu'est-ce que data-vocabulary.org et pourquoi Google le retire-t-il ?

data-vocabulary.org était un vocabulaire de balisage structuré, concurrent de schema.org, utilisé notamment pour marquer les breadcrumbs (fils d'Ariane), les avis et certaines métadonnées. Google l'a longtemps toléré en parallèle de schema.org, mais ce support dual créait une fragmentation technique coûteuse à maintenir côté moteur.

La décision de le retirer répond à une stratification des standards : schema.org s'est imposé comme référence W3C, soutenu par tous les moteurs majeurs (Google, Bing, Yandex, Yahoo à l'époque). Maintenir deux parsers pour le même type de données n'a plus de sens stratégique pour Google, surtout quand l'un des deux est marginal.

Quels éléments sont concrètement touchés par cet abandon ?

Le cas le plus critique concerne les fils d'Ariane (breadcrumbs), largement utilisés avec data-vocabulary.org dans les CMS et thèmes anciens. Les breadcrumbs améliorent la lisibilité SERP, augmentent le CTR sur mobile et clarifient la hiérarchie du site pour Google — leur absence est un recul UX et SEO mesurable.

D'autres formats (reviews, events, produits) utilisaient aussi data-vocabulary, mais moins massivement que les breadcrumbs. La notification Search Console cible explicitement ce dernier cas, signe que c'est le volume d'usage le plus problématique à migrer rapidement.

Quel calendrier Google impose-t-il pour cette transition ?

Date butoir : 6 avril. Après cette date, Google ignore purement et simplement les balises data-vocabulary.org — elles ne génèrent plus de rich snippets, ni de breadcrumbs affichés. Les sites concernés ont reçu des notifications Search Console dès janvier/février, soit un délai de 2 à 3 mois pour migrer.

Ce délai est court pour les gros sites legacy avec des dizaines de milliers de pages. Google joue la carte du forcing technique, ce qui suggère que le coût de maintenance interne de l'ancien parser était devenu trop élevé par rapport au trafic concerné. Les sites qui traînent perdront de la visibilité SERP sans préavis supplémentaire.

• data-vocabulary.org devient totalement invisible pour Google après avril
• Les breadcrumbs sont l'élément le plus impacté, avec perte de CTR potentielle
• Le délai de migration (2-3 mois) est serré pour les architectures complexes
• schema.org est désormais le seul standard reconnu pour les données structurées
• Les notifications Search Console signalent les pages concernées — vérifiez-les sans attendre

Cette décision est-elle cohérente avec l'évolution technique de Google ?

Absolument. Google simplifie progressivement son stack de parsing, et ce retrait s'inscrit dans une logique de rationalisation des ressources crawler. Le moteur a toujours privilégié schema.org depuis sa création en 2011, data-vocabulary n'était qu'une tolérance transitoire. Maintenir deux parsers pour un même objectif (afficher un breadcrumb) coûte en temps CPU, en complexité de code et en surface de bugs.

Sur le terrain, on observe depuis plusieurs années que les innovations de rich snippets (FAQ, How-to, Product schema étendu) n'ont jamais été supportées sur data-vocabulary. Google n'a jamais développé de nouvelles features pour ce format — signe qu'il était déjà en fin de vie tacite. La vraie question est : pourquoi avoir attendu si longtemps pour officialiser l'abandon ?

Quels risques réels pour les sites qui ne migrent pas à temps ?

La perte des breadcrumbs en SERP est l'impact immédiat. Sur mobile, où les breadcrumbs remplacent souvent l'URL affichée, cela peut dégrader le CTR de 5 à 15 % selon les verticales (e-commerce, médias structurés en catégories). Un site qui affichait "Accueil > Électronique > Smartphones" se retrouvera avec une URL brute moins engageante.

Deuxième risque : perte de signaux de hiérarchie. Les breadcrumbs aident Google à comprendre l'architecture du site, surtout sur les gros catalogues. Sans eux, le moteur s'appuie uniquement sur le maillage interne et l'URL structure — suffisant dans l'idéal, mais moins robuste en pratique si le maillage est bancal.

Existe-t-il des cas où schema.org pose plus de problèmes que data-vocabulary ?

[A vérifier] En théorie, schema.org est plus verbeux (syntaxe JSON-LD vs. microdata compacte), ce qui peut légèrement alourdir le HTML. Sur les sites avec des contraintes de taille de page strictes (mobile first index, Core Web Vitals), chaque kilo-octet compte. Cela dit, l'impact réel est marginal (quelques dizaines d'octets par breadcrumb).

Certains vieux CMS (Drupal 7, Joomla 2.x) avaient des modules natifs pour data-vocabulary, mais pas toujours pour schema.org. La migration peut nécessiter un changement de module ou un développement custom — coût technique non nul pour les sites legacy. Si votre stack date d'avant 2015, préparez-vous à mettre les mains dans le code ou à upgrader le CMS.

Comment vérifier si mon site utilise encore data-vocabulary.org ?

Premier réflexe : ouvrez Google Search Console, section "Améliorations" > "Fil d'Ariane". Si vous voyez des avertissements mentionnant data-vocabulary, vous êtes concerné. Google liste les pages impactées, ce qui facilite l'audit — exportez la liste et priorisez les URLs à fort trafic.

Deuxième méthode : inspectez le HTML source de vos pages clés. Cherchez des attributs itemtype="http://data-vocabulary.org/Breadcrumb" ou itemtype="http://data-vocabulary.org/Review". Si vous en trouvez, c'est que votre CMS ou votre thème génère encore l'ancien format. Testez aussi avec l'outil de test des données structurées de Google (structure data testing tool ou rich results test) : il signale explicitement les formats obsolètes.

Quelle est la procédure de migration vers schema.org ?

Le plus simple : JSON-LD inséré dans le <head> ou en fin de <body>. Pour un breadcrumb, le code ressemble à ça (très schématique) : un objet BreadcrumbList contenant une liste d'éléments ListItem avec position, name et URL. Pas besoin de toucher au HTML visible, le script JSON suffit.

Si vous utilisez un CMS récent (WordPress 5.x+, Shopify, PrestaShop 1.7+), il existe des plugins ou modules natifs qui génèrent schema.org automatiquement. Vérifiez vos extensions actuelles : beaucoup ont ajouté le support schema.org depuis plusieurs années. Si vous êtes en microdata data-vocabulary dans le HTML, il faudra soit remplacer les attributs itemprop/itemtype, soit basculer sur JSON-LD (préférable, plus maintenable).

Quels pièges éviter lors de la migration ?

Erreur classique : dupliquer le balisage. Si vous passez de microdata à JSON-LD, supprimez l'ancien balisage inline — sinon vous envoyez deux breadcrumbs à Google, ce qui peut créer des incohérences. Le moteur priorisera JSON-LD, mais autant nettoyer proprement.

Deuxième piège : mauvaise hiérarchie dans le breadcrumb. schema.org est strict sur l'ordre des éléments (position 1, 2, 3…). Si vous inversez ou sautez une position, Google peut ignorer le breadcrumb entier. Testez chaque template de page (catégorie, produit, article) avec le Rich Results Test avant de déployer en prod.

Troisième point : URLs absolues obligatoires. Dans le JSON-LD, chaque "item" doit pointer vers une URL complète (https://...), pas un chemin relatif. Certains CMS génèrent des chemins relatifs par défaut — vérifiez votre output et corrigez si nécessaire.

• Auditer Search Console (section Fil d'Ariane) pour identifier les pages concernées
• Tester le HTML source avec l'outil Rich Results Test de Google
• Migrer vers JSON-LD (plus simple et maintenable que microdata)
• Supprimer l'ancien balisage data-vocabulary après vérification du nouveau
• Vérifier que les URLs du breadcrumb sont absolues (https://...)
• Tester chaque type de template (catégorie, produit, article) avant déploiement global