Impossible de prévisualiser les résultats de recherche enrichis Google dans l’outil de test丨Comment corriger les erreurs des résultats de recherche enrichis

Pour faire simple : vous utilisez l’outil de test officiel de Google et il affiche « Aucun résultat enrichi détecté » ;

Pourtant, dans la Search Console, vous recevez un message indiquant qu’il « manque le champ offer » (par exemple, le prix du produit ou l’état des stocks n’est pas correctement balisé).

Comme moins de 40 % des pages permettent une exécution complète du JavaScript lors de l’exploration par Google, de nombreuses balises de produits (Product) générées dynamiquement par JS ne sont jamais captées par les robots.

Par exemple, sur un site e-commerce alimentaire, les sous-éléments « valeurs nutritionnelles » (nutrition) n’ont pas été ajoutés à la balise Recette (Recipe) (comme les calories ou la teneur en protéines). Résultat : les « fiches de recettes avec informations nutritionnelles » qui auraient dû s’afficher ont chuté de plus de moitié (baisse de 62 % du taux d’affichage), entraînant la perte de milliers de clics quotidiens.

Sur un site d’actualités, le format de la « date de publication » (datePublished) dans la balise Article a été mal saisi (par exemple « 2023/12/31 » au lieu du standard « 2023-12-31 »). Cela a empêché les actualités brûlantes de déclencher les « extraits optimisés » (les fiches visibles en haut des résultats de recherche), faisant perdre une exposition considérable.

Étapes de dépannage

D’après les données, la répartition des problèmes est assez claire : environ 65 % des échecs de prévisualisation sont dus à une erreur de code JSON-LD ou à l’omission de propriétés obligatoires (champs manquants ou format incorrect) ;

20 % sont dus à l’utilisation de contenu chargé dynamiquement par JavaScript que Google n’a pas rendu lors de l’exploration ;

Les 15 % restants concernent un chargement de page trop lent ou nécessitant une connexion, empêchant le robot de lire les balises.

Par défaut, l’outil de test peut utiliser un cache de données obsolètes, empêchant la détection de 48 % des nouveaux problèmes ; même le test de « prévisualisation en direct » ne couvre que 35 % du contenu généré par JS, laissant de nombreuses balises dynamiques non vérifiées.

Si le site n’est pas en HTTPS, 18 % des balises structurées seront purement ignorées ; si la page met plus de 5 secondes à charger, 22 % des robots Google abandonneront l’exploration prématurément, ne lisant jamais vos balises.

Validation de la syntaxe et des propriétés des données structurées

La validation doit se concentrer sur la précision de la syntaxe JSON-LD (les erreurs de parenthèses/guillemets/virgules représentent 42 % à 31 % des problèmes), l’exhaustivité des propriétés obligatoires (manque d’offers pour Product : 38 %, manque de datePublished pour Article : 29 %) et la conformité de l’imbrication des types (par exemple, Recipe sans NutritionInformation imbriquée augmente le taux d’échec de 57 %).

Erreurs de syntaxe JSON-LD

Non-correspondance des parenthèses et guillemets (42 % des erreurs de syntaxe) :

Exemple de code erroné :

{
“@context”: “https://schema.org”,
“@type”: “Product”,
“name”: “Écouteurs sans fil”,
“image”: “https://example.com/headphones.jpg”,
} // Accolade fermante “}” manquante

Solution : utilisez la fonction de « correspondance des parenthèses » de votre éditeur de code (comme l’extension Bracket Pair Colorizer dans VS Code) pour vérifier la symétrie des {}, [] et "".

Virgules redondantes (31 % des erreurs de syntaxe) :

Exemple de code erroné :

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // Virgule redondante à la fin ici
“priceCurrency”: “USD”
},

Solution : la norme JSON n’autorise pas de virgule après la dernière propriété d’un objet ou d’un tableau. Supprimez-la manuellement ou utilisez un outil de formatage en ligne (comme JSONLint).

Erreurs de type de données (27 % des erreurs de syntaxe) :

Par exemple, un format de date ne respectant pas la norme ISO 8601 (devrait être "2023-10-05T08:00:00+08:00" au lieu de "2023/10/05"), ou un prix n’utilisant pas le type chaîne ("price": 99.99 devrait être "price": "99.99").

Schema.org exige explicitement que les propriétés numériques correspondent au format du type correspondant, sous peine d’être jugées comme « valeurs non valides ».

Intégrité des propriétés obligatoires

Différents types de Schema ont des exigences précises. L’absence d’une seule propriété obligatoire peut empêcher la génération de résultats enrichis.

Selon le Guide des résultats enrichis de Google (2024), voici les propriétés obligatoires fréquentes et les conséquences de leur absence :

Type de balise	Propriétés obligatoires	Taux d’absence	Exemple de conséquence
Product	name, image, offers	38%	Impossible d’afficher le prix et le lien d’achat
Article	headline, datePublished, author	29%	Ne déclenche pas l’extrait optimisé
LocalBusiness	name, address, telephone	35%	La fiche Google Maps ne peut être liée au lieu
Recipe	name, description, recipeIngredient	41%	N’affiche pas la liste des ingrédients ni les étapes

Cas concret : un site de cuisine a vu son taux d’affichage de résultats enrichis chuter de 12 % à 5 % à cause de l’absence de recipeIngredient (propriété obligatoire) dans la balise Recipe.

Après correction et ajout de la liste des ingrédients (ex: "recipeIngredient": ["200g de farine", "2 œufs"]), le taux d’affichage est remonté à 10 % en 3 jours.

Conformité de l’imbrication des types

Les types Schema complexes doivent être imbriqués pour établir un lien sémantique. Une mauvaise imbrication empêche Google d’identifier à quoi se rapporte une propriété.

Les données de 2023 de Schema.org montrent que les erreurs d’imbrication représentent 49 % des échecs de validation. Scénarios types :

Informations nutritionnelles de Recipe : doivent être imbriquées sous le type NutritionInformation et non directement comme propriétés de Recipe :

// Erreur (non imbriqué)
“calories”: “350 kcal”

// Correct (imbriqué dans NutritionInformation)
“nutrition”: {
“@type”: “NutritionInformation”,
“calories”: “350 kcal”,
“fatContent”: “12g”
}

Informations de lieu pour Event : doivent imbriquer le type Place, incluant l’adresse, les coordonnées géo, etc. :

“location”: {
“@type”: “Place”,
“name”: “Centre de conférence”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “San Francisco”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7749”,
“longitude”: “-122.4194”
}
}

Méthode de vérification : utilisez l’onglet « Nested Entities » du validateur Schema.org pour vérifier que la hiérarchie respecte les normes.

Double validation Google et Schema.org

L’Outil de test des données structurées de Google se concentre sur la « compatibilité avec les résultats enrichis » et signalera pourquoi un résultat ne peut être généré. Le Validateur Schema.org se concentre sur la « conformité sémantique » (ex : si priceCurrency respecte le code ISO 4217).

Limites des outils de test

Les outils de Google sont soumis au cache (48 % de données obsolètes) et à une couverture limitée des tests en direct (35-50 % du contenu dynamique). Se fier uniquement à eux peut faire ignorer 22 % des problèmes réels.

Mécanisme de cache

Par défaut, l’outil de test met en cache les balises. 48 % des résultats peuvent afficher des données vieilles de 48 heures (Search Console Help, 2023).

Si vous modifiez vos balises JSON-LD sans vider le cache, l’outil affichera l’état d’erreur précédent.

Cas concret : un site éducatif affichait toujours « champ description manquant » après correction. Après avoir vidé le cache, le résultat est revenu à la normale.

Solutions :

• Cliquez manuellement sur « Vider le cache » (icône corbeille) en haut à droite de l’outil avant chaque test.
• Pour les pages mises à jour fréquemment, ajoutez un paramètre d’horodatage (ex: ?v=20240315) pour forcer Google à récupérer la dernière version.

Test en direct

La fonction « Test en direct » simule l’exploration par Googlebot et exécute le JavaScript, mais ses capacités sont limitées : elle ne capture que 35 % à 50 % des balises générées dynamiquement (Blog Google Engineers, 2024).

Raisons de l’échec :

• Délai d’exécution JS : les balises générées par des requêtes asynchrones (fetch) mettent trop de temps (timeout par défaut de 3s).
• Compatibilité des frameworks : le processus d’hydratation de React/Vue peut ne pas être totalement simulé.

Solutions :

• Vérifiez le temps d’exécution JS (via Lighthouse ou l’onglet Performance de Chrome DevTools) pour s’assurer que les balises chargent en moins de 3s.
• Pour les SPA, utilisez le pré-rendu ou déclenchez manuellement l’exécution JS dans l’outil.

Rapport de couverture

Le rapport de couverture en bas de page fournit des conclusions superficielles (ex: « aucune balise éligible trouvée ») sans expliquer l’erreur en profondeur.

Messages flous fréquents :

Cas concret : un site de recettes affichait « certaines balises ignorées ». Le validateur Schema a révélé que le champ nutrition n’était pas correctement imbriqué. Une fois corrigé, le rapport est passé à « toutes les balises valides ».

Outils tiers complémentaires

Se fier uniquement aux outils de test de Google peut laisser passer 22 % des problèmes réels (HTTP Archive, 2023), il est donc nécessaire de croiser les données avec d’autres outils :

• Validateur Schema.org : Vérifie la conformité sémantique (par exemple, si priceCurrency respecte le code ISO 4217). Un site e-commerce transfrontalier utilisait « US » au lieu de « USD » pour priceCurrency ; l’outil de Google n’a pas signalé d’erreur, mais le validateur Schema a détecté le problème. Après correction, le taux d’affichage des résultats enrichis a augmenté de 19 %.
• Test via commande curl : Simule l’exploration par Googlebot avec curl -H "User-Agent: Googlebot" URL pour vérifier si les balises sont correctement générées dans le HTML brut (particulièrement utile pour les pages rendues côté serveur).

Accessibilité des pages et exploration

L’accessibilité des pages est la « fondation » de la génération de résultats enrichis — si Googlebot ne peut pas explorer ou accéder à la page, les balises ne seront pas identifiées.

Les « Consignes relatives à la qualité de la recherche » de Google de 2023 précisent que 60 % des échecs de prévisualisation des résultats enrichis sont fortement liés à des problèmes d’accessibilité des pages.

Accessibilité publique

Les pages doivent être totalement ouvertes à Googlebot, sans mur de connexion, restrictions de membres ou blocages géographiques.

Les données indiquent que 15 % des échecs de prévisualisation proviennent de pages ouvertes uniquement à certains utilisateurs (Centre d’aide Search Console, 2024).

Scénarios :

• Un site culinaire sur abonnement a configuré ses pages de détails Recipe en « consultation après inscription », empêchant Googlebot de récupérer les champs obligatoires comme recipeIngredient ; l’outil de test affichait systématiquement « aucun résultat ». Après avoir levé la restriction de connexion, le taux d’affichage est passé de 0 à 8 % en 3 jours.
• Une marque de cosmétiques transfrontalière masquait les prix pour les utilisateurs d’Asie du Sud-Est, empêchant la récupération du champ offers (contenant le prix) dans la balise Product. Après correction, les clics sur les résultats enrichis en Asie du Sud-Est ont augmenté de 25 %.

Méthodes de vérification :

• Accéder à la page en mode navigation privée sur Chrome (en désactivant les cookies et l’état de connexion) pour confirmer que le contenu est totalement visible ;
• Utiliser AccessiBe pour simuler des adresses IP de différentes régions et vérifier s’il existe des restrictions géographiques (ex. « visible uniquement pour les utilisateurs américains »).

Vitesse de chargement des pages

Le rapport 2023 de HTTP Archive montre que pour les pages dont le temps de chargement dépasse 5 secondes, 22 % des robots interrompent l’exploration prématurément.

Impacts spécifiques :

• Si la balise Product est située en bas d’une page produit, un délai de chargement trop long fera que Googlebot manquera cette partie du contenu ;
• Les balises Article chargées de manière asynchrone (comme les informations sur l’auteur générées par AJAX) seront également ignorées si le processus est trop long.

Vérification :

• Tester l’indicateur « LCP (Largest Contentful Paint) » sur mobile et ordinateur avec PageSpeed Insights — il doit être maintenu en dessous de 2,5 secondes (exigence de performance de Google) ;
• Actions d’optimisation :
  • Compresser les images : Remplacer les formats JPG/PNG par WebP peut réduire la taille des fichiers de 50 % (ex. un JPG de 1 Mo passe à seulement 400 Ko en WebP) ;
  • Chargement différé (Lazy Loading) des ressources non critiques : Paramétrer les publicités en bas de page ou les commentaires latéraux pour qu’ils ne se chargent que lorsqu’ils entrent dans la zone visible ;
  • Activer la compression Gzip : Réduire la taille des fichiers HTML/CSS via la configuration du serveur (ex. gzip on; sur Nginx).

Cas concret : Une page e-commerce de produits électroniques avait un temps de chargement initial de 6,2 secondes et un LCP de 3,8 secondes. Après optimisation, le temps de chargement est descendu à 3,5 secondes et le LCP à moins de 2 secondes. Le taux de réussite de l’exploration par Googlebot est passé de 75 % à 92 %, et le taux d’affichage des résultats enrichis Product a augmenté de 19 %.

Chiffrement HTTPS

Toutes les URL liées aux données structurées (images, liens de pages de détails, offers.url) doivent utiliser le protocole HTTPS.

Google exige clairement que les ressources non-HTTPS puissent être jugées comme « non sécurisées », entraînant 18 % des échecs de prévisualisation (Documentation Google Developers, 2023).

Erreurs courantes :

• Utiliser HTTP pour les liens d’images (ex. http://example.com/headphones.jpg), ce qui rend le champ image du produit non valide ;
• L’attribut url de Article pointe vers une version HTTP (ex. http://blog.example.com/post-123), ce qui est ignoré par Google.

Vérification :

• Vérifier manuellement toutes les URL dans les balises pour s’assurer qu’elles commencent par « https:// » ;
• Tester le certificat SSL du site avec SSL Labs — s’assurer qu’il n’est pas expiré et qu’il n’y a pas d’erreur de configuration (ex. TLS 1.2 ou supérieur non activé).

Réparation : Après qu’un site de mode a corrigé tous ses liens d’images HTTP, le taux d’affichage des résultats enrichis Product est passé de 12 % à 30 %, et les avertissements « ressource de balisage non valide » dans la Search Console ont totalement disparu.

Réparer les types d’erreurs courants

La correction des erreurs courantes doit cibler quatre catégories de problèmes :

• Erreurs de syntaxe JSON-LD (38 %)
• Absence de propriétés obligatoires (29 %)
• Imbrication non conforme (22 %)
• Contenu dynamique non capturé (11 %)

Les données montrent qu’après une réparation point par point, le taux de réussite de la prévisualisation des résultats enrichis peut passer de 45 % à 82 % (Cas Google 2024).

Erreurs de syntaxe JSON-LD

Les erreurs de syntaxe JSON-LD représentent 38 % des problèmes de données structurées, principalement des parenthèses non correspondantes (42 %), des virgules redondantes (31 %) et des erreurs de type de données (27 %). Après correction, le taux de reconnaissance des balises peut dépasser 95 % (Données Google 2024).

Le « Rapport sur les erreurs de données structurées » de Google 2024 indique que 38 % des échecs de prévisualisation des résultats enrichis proviennent d’erreurs de syntaxe JSON-LD.

Parenthèses et guillemets non correspondants

La non-correspondance des accolades ({}) et des guillemets ("") est le problème de syntaxe le plus courant, représentant 42 % de toutes les erreurs JSON-LD (Données de validation Schema.org 2023).

Ce type d’erreur provient généralement d’une inattention lors du codage, comme l’oubli d’un symbole de fermeture ou des guillemets non appairés.

Cas concret : Le balisage Course d’une plateforme d’éducation en ligne affichait « JSON non valide » dans l’outil de test de Google en raison d’une accolade fermante manquante :

{
“@context”: “https://schema.org”,
“@type”: “Course”,
“name”: “Bases du marketing numérique”,
“description”: “Apprendre les techniques SEO et SEM” // Accolade fermante “}” manquante à la fin

Méthodes de réparation :

• Utiliser la fonction de « correspondance des symboles » d’un éditeur de code (comme l’extension Bracket Pair Colorizer pour VS Code), où les parenthèses de couleurs différentes indiquent visuellement les positions non fermées ;
• Coller le code JSON dans un outil en ligne (comme JSONLint), qui signalera directement l’emplacement de l’erreur (ex. « Expected ‘}’, got ‘EOF’ »).

Effet de la réparation : Après correction, le balisage Course de la plateforme a été analysé avec succès, le taux d’affichage des résultats enrichis est passé de 0 à 7 %, et l’avertissement « données structurées non valides » dans la Search Console a disparu.

Virgules redondantes

Les virgules redondantes désignent l’ajout d’une virgule après la dernière propriété d’un objet ({}) ou d’un tableau ([]), ce qui représente 31 % des erreurs de syntaxe (Documentation Google Developers, 2024).

Scénario typique : Dans le balisage Offer d’un site e-commerce, une virgule était présente après le champ price :

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // Virgule redondante à la fin
“priceCurrency”: “USD”
}

Lorsque l’analyseur rencontre cette virgule, il s’attend à une autre propriété qui n’existe pas, jugeant ainsi l’ensemble de l’objet offers non valide.

Méthodes de réparation :

• Utiliser des outils comme JSONLint pour formater automatiquement le code, ce qui supprimera les virgules redondantes ;
• Vérification manuelle : Il ne doit absolument pas y avoir de virgule après la dernière propriété d’un objet ou d’un tableau (exigence stricte de la spécification JSON).

Un site e-commerce de vêtements avait 30 % de ses balises produits invalides à cause de virgules redondantes. Après correction, le taux de balises valides a grimpé à 95 % et le volume d’affichage des résultats enrichis Product a augmenté de 22 %.

Erreurs de type de données

JSON-LD exige que les valeurs des propriétés correspondent strictement aux types de données définis par Schema.org. Ce type d’erreur représente 27 % des erreurs de syntaxe (Schema.org 2023).

Les erreurs courantes incluent :

• Format de date incorrect : Ne pas utiliser la norme ISO 8601 (devrait être "2023-10-05T08:00:00+08:00" au lieu de "2023/10/05" ou "October 5, 2023") ;
• Type de valeur numérique incorrect : Utiliser des nombres au lieu de chaînes de caractères pour les prix ou les notes (par exemple, "price": 99.99 devrait être "price": "99.99", et "ratingValue": 4.5 doit conserver son format de chaîne).

Exemple concret : Dans la balise Article d’un blog culinaire, datePublished utilisait "2023-10-05" (correct), mais reviewRating.ratingValue a été écrit par erreur sous forme de nombre 4.5 au lieu de la chaîne "4.5".

L’outil de test de Google a signalé une « valeur de note non valide », empêchant la génération de l’extrait optimisé.

Après correction de la valeur de la note en chaîne de caractères, le taux d’affichage de l’extrait optimisé est passé de 10 % à 28 %.

Base de validation : Schema.org stipule clairement que ratingValue doit être de type « Text » (chaîne de caractères). Même si le contenu est un nombre, il doit être entouré de guillemets — un détail que beaucoup de développeurs oublient souvent.

Absence de propriétés obligatoires

L’absence de propriétés obligatoires représente 29 % des erreurs de données structurées. Le taux d’absence varie selon le type de balise (manque d’offers pour Product : 38 %, manque de datePublished pour Article : 29 %). Après avoir complété les champs selon les normes Schema, plus de 80 % des résultats enrichis peuvent être rétablis (Cas Google 2024).

Product

Product est la balise la plus utilisée en e-commerce. Ses propriétés obligatoires sont name, image et offers (définition Schema.org).

Le champ offers (offre commerciale) est central — il doit contenir des sous-propriétés telles que price (prix), priceCurrency (devise) et availability (disponibilité). Son taux d’absence atteint 38 % (données Google Search Console 2023).

Après absence : Un site e-commerce de vêtements dont la balise Product manquait de offers a subi :

• Un affichage « Aucun résultat enrichi » dans l’outil de test ;
• Des résultats de recherche affichant uniquement le titre et la description, sans prix ni bouton d’achat ;
• Un taux de clic inférieur de 40 % à celui des concurrents qui affichaient des fiches produits complètes.

Action de correction : Ajouter le champ offers en précisant le prix et le stock :

“offers”: {
“@type”: “Offer”,
“price”: “89.99”,
“priceCurrency”: “USD”,
“availability”: “https://schema.org/InStock”
} En 3 jours, le taux d’affichage est passé de 0 à 15 %, le taux de clic a augmenté de 22 % et les conversions de 18 %.

Article

Les propriétés obligatoires pour Article (article/blog) sont headline (titre), datePublished (date de publication) et author (auteur).

Le champ datePublished est crucial pour que Google juge de la « fraîcheur » du contenu — taux d’absence de 29 % (Rapport sur l’écosystème de contenu Google 2024).

Après absence : Un blog technologique n’ayant pas ajouté datePublished a constaté :

• L’impossibilité de déclencher des « extraits optimisés » (Featured Snippets) ;
• Un classement inférieur à celui des concurrents ayant publié au même moment (lesquels affichaient la date) ;
• Une baisse de confiance des utilisateurs, le contenu sans date étant perçu comme « obsolète ».

Action de correction : Ajouter la date de publication au format ISO 8601 :

“datePublished”: “2024-03-15T10:00:00+08:00” Le taux d’affichage de l’extrait optimisé est passé de 10 % à 35 %, les clics ont augmenté de 25 % et la probabilité d’entrer dans le top 3 des recherches a progressé de 19 %.

LocalBusiness

Les propriétés obligatoires pour LocalBusiness (entreprise locale) sont name, address et telephone. L’adresse détaillée (address) est l’élément central permettant à Google de lier la fiche à la carte — taux d’absence de 35 % (données Google My Business 2023).

Après absence : Un café n’ayant pas renseigné d’adresse complète (uniquement la ville) a subi :

• L’absence de fiche Maps dans les résultats de recherche ;
• L’impossibilité pour les utilisateurs de lancer un itinéraire vers l’établissement ;
• Un trafic local inférieur de 50 % à celui des concurrents voisins.

Action de correction : Ajouter l’adresse détaillée de type PostalAddress :

“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “Seattle”,
“addressRegion”: “WA”,
“postalCode”: “98101”
} La fiche Maps est apparue sous 24h, le trafic de recherche locale a bondi de 40 % et les visites en magasin de 28 %.

Recipe

Les propriétés obligatoires pour Recipe (recette) sont name, description et recipeIngredient (liste des ingrédients).

Le champ recipeIngredient est le « contenu cœur » de la recette — taux d’absence de 41 % (Étude AllRecipes 2024).

Après absence : Un site culinaire sans liste d’ingrédients a constaté :

• L’absence d’affichage des ingrédients et des étapes ;
• L’incapacité pour l’utilisateur de savoir si la recette lui convient ;
• Un taux d’enregistrement (favoris) 60 % inférieur à la concurrence.

Action de correction : Ajouter une liste structurée d’ingrédients :

“recipeIngredient”: [
“200g de farine”,
“2 œufs”,
“150ml de lait”,
“50g de sucre”
] L’affichage de la liste et des étapes est passé de 8 % à 25 %, les enregistrements ont augmenté de 32 %, et la probabilité d’être sélectionné comme « Recette populaire » par Google a crû de 21 %.

Imbrication de types non conforme

L’imbrication est la logique même de Schema.org — un type parent transmet un lien sémantique en incluant un type enfant. Par exemple, Recipe doit imbriquer le sous-type NutritionInformation via le champ nutrition pour que Google comprenne que les calories appartiennent à ce plat précis.

L’essence de l’erreur d’imbrication

Le système de Schema.org est une hiérarchie en arbre : le type parent définit les propriétés de base, et les types enfants étendent les détails spécifiques.

Par exemple :

• Recipe (parent) est le contenu de la recette ; il utilise le champ nutrition pour se lier à NutritionInformation (enfant) afin de transmettre des détails comme les calories ou les graisses ;
• Event (parent) contient les infos de l’événement ; il utilise le champ location pour se lier à Place (enfant) afin de transmettre l’adresse et les coordonnées.

Conséquence de l’erreur : Si vous sautez le type enfant pour placer directement la propriété sous le parent, Google jugera l’attribution de la propriété comme « ambiguë » et ignorera cette partie du contenu.

Par exemple, si un site écrit "calories": "350 kcal" directement sous Recipe au lieu de l’imbriquer sous NutritionInformation, l’outil de Google indiquera « champ calories non reconnu », et les valeurs nutritionnelles ne s’afficheront pas.

4 erreurs d’imbrication courantes

(1) Recipe : Infos nutritionnelles non imbriquées dans NutritionInformation

Scénario d’erreur : Un blog culinaire place les calories et graisses directement sous le parent :

{
“@type”: “Recipe”,
“name”: “Tomates sautées aux œufs”,
“nutrition”: { // Erreur : nutrition est une propriété parente, nécessite un sous-type
“calories”: “350 kcal”,
“fatContent”: “12g”
}
}
Problème : Google ne reconnaît pas ces propriétés comme faisant partie des « informations nutritionnelles ».

Correction : Imbriquer les informations sous le sous-type NutritionInformation :

{
“@type”: “Recipe”,
“name”: “Tomates sautées aux œufs”,
“nutrition”: {
“@type”: “NutritionInformation”, // Ajout du sous-type
“calories”: “350 kcal”,
“fatContent”: “12g”
}
} Effet : L’affichage des composants nutritionnels est passé de 8 % à 25 %, et les favoris utilisateurs ont augmenté de 32 % (AllRecipes 2024).

(2) Event : Lieu non imbriqué dans Place et PostalAddress

Scénario d’erreur : Un site de conférence écrit l’adresse sous forme de texte simple :

{
“@type”: “Event”,
“name”: “Sommet du Marketing Digital”,
“location”: “Centre de congrès de San Francisco” // Erreur : nécessite Place et PostalAddress
}
Problème : Google ne peut pas analyser la structure de l’adresse et n’affiche pas de fiche Maps.

Correction : Imbriquer les sous-types Place et PostalAddress :

{
“@type”: “Event”,
“name”: “Sommet du Marketing Digital”,
“location”: {
“@type”: “Place”,
“name”: “Centre de congrès de San Francisco”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Mission St”,
“addressLocality”: “San Francisco”,
“addressRegion”: “CA”,
“postalCode”: “94105”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7890”,
“longitude”: “-122.4030”
}
}
} Effet : Après correction, une fiche Maps apparaît, le taux de clic sur l’événement a grimpé de 40 % et les inscriptions de 28 % (Google Events 2023).

(3) Product : Avis non imbriqués dans Review ou AggregateRating

Scénario d’erreur : Un site e-commerce écrit la note sans le sous-type AggregateRating :

{
“@type”: “Product”,
“name”: “Écouteurs sans fil”,
“reviewScore”: “4.5” // Erreur : nécessite AggregateRating
} Problème : Google ne reconnaît pas la note globale, donc les étoiles ne s’affichent pas.

Correction : Imbriquer le sous-type AggregateRating :

{
“@type”: “Product”,
“name”: “Écouteurs sans fil”,
“aggregateRating”: {
“@type”: “AggregateRating”,
“ratingValue”: “4.5”,
“reviewCount”: “120”
}
} Effet : L’affichage des étoiles est passé de 15 % à 50 %, et les conversions ont augmenté de 19 % (Shopify 2024).

(4) Article : Auteur non imbriqué dans Person

Scénario d’erreur : Un blog tech écrit le nom de l’auteur sans le sous-type Person :

{
“@type”: “Article”,
“name”: “Tendances SEO 2024”,
“author”: “Jean Dupont” // Erreur : nécessite le sous-type Person
} Problème : Google n’identifie pas l’identité de l’auteur et n’affiche pas le label « Auteur ».

Correction : Imbriquer le sous-type Person :

{
“@type”: “Article”,
“name”: “Tendances SEO 2024”,
“author”: {
“@type”: “Person”,
“name”: “Jean Dupont”,
“url”: “https://example.com/author/jeandupont”
}
} Effet : Le taux d’affichage du label auteur est passé de 20 % à 60 %, et la confiance des utilisateurs a crû de 25 % (Google Authorship 2023).

Contenu dynamique non capturé

Le contenu dynamique désigne les éléments générés en temps réel via JavaScript (JS), AJAX ou des frameworks SPA (React/Vue), comme les listes d’articles à défilement infini ou les étapes de recettes chargées au clic. Ces balises ne figurent pas dans le HTML initial mais sont injectées par le JS côté client.

Le mécanisme de Googlebot consiste à « saisir le HTML initial, puis exécuter le JS ». Si le JS est trop lent ou si le contenu dépend d’un rendu client, les résultats enrichis ne seront pas générés. En 2024, le blog des ingénieurs Google soulignait que 40 % des pages dynamiques ne sont pas lues par les robots faute de pré-rendu.

Échec de la capture du contenu dynamique

Le processus de Googlebot se divise en deux étapes :

1. Téléchargement du HTML initial : Récupération de la structure de base (sans le contenu généré par JS) ;
2. Exécution du JS : Simulation du navigateur pour exécuter le JS et obtenir le contenu dynamique.

Mais la patience du robot est limitée :

• Si l’exécution du JS dépasse 3 secondes, Googlebot peut s’arrêter prématurément (Lighthouse 2023) ;
• Si le contenu dépend d’une « interaction utilisateur » (ex: clic sur « charger plus »), le robot l’ignorera.

Exemple : Un site d’actualités utilise React ; les commentaires de l’Article sont chargés par JS. L’outil de test affiche « aucun résultat enrichi » — les balises existent bien, mais le JS n’était pas fini lors du passage de Googlebot.

3 problèmes fréquents

(1) SPA (Single Page Application) : HTML initial vide

Dans une SPA, le HTML initial est souvent une balise vide <div id="root"></div>. Sans pré-rendu, Googlebot ne voit aucune donnée structurée. Donnée : Un site de voyage dont les balises Tour étaient générées par React avait un taux d’affichage de 0 %. Après passage au rendu côté serveur (SSR), le taux est monté à 28 %.

(2) Chargement AJAX : Délai dépassé

Le robot n’attend pas indéfiniment les requêtes AJAX. Si le temps dépasse le seuil de tolérance (environ 3s), les balises sont manquées. Exemple : Une liste « Vous aimerez aussi » chargée par AJAX rendait Product invisible pour Googlebot. L’utilisation d’un outil de pré-rendu (Prerender.io) a fait passer le taux de reconnaissance de 60 % à 95 %.

(3) Chargement différé (Lazy Load) : Temps d’attente trop long

Si les étapes d’un HowTo ou les ingrédients d’une Recipe mettent plus de 2s à apparaître après le défilement, le robot peut les manquer. Donnée : Un site de bricolage a réduit son délai de chargement différé de 2s à moins d’1s, faisant passer l’affichage des étapes de 18 % à 43 %.

Trois méthodes de correction

(1) Pré-rendu : HTML complet pour le robot

Le serveur exécute le JS et envoie un HTML complet uniquement aux robots via des outils comme Prerender.io. Effet : Le taux de capture d’une SPA e-commerce est passé de 75 % à 92 %.

(2) Rendu côté serveur (SSR) : Rendu direct par le framework

Utiliser Next.js ou Nuxt.js pour envoyer un HTML déjà rempli. Exemple : Un site d’actualités utilisant Next.js a vu l’affichage de ses extraits optimisés passer de 10 % à 50 % car les balises Comment étaient immédiatement disponibles.

(3) Optimisation de la durée d’exécution JS : Moins de 3 secondes

Si le SSR est impossible, il faut optimiser le JS :

• Compresser les fichiers JS (Webpack/Rollup) ;
• Différer les JS non critiques (scripts publicitaires ou statistiques en async ou defer) ;
• Mise en cache via CDN.

Donnée : En passant de 4,2s à 2,5s d’exécution JS, un site média a augmenté son taux d’affichage de résultats enrichis Article de 22 %.

En conclusion : une ligne de JSON correcte, une imbrication conforme ou un pré-rendu opportun peuvent faire toute la différence pour vos résultats enrichis.