Rich result Product disparu après un changement d’extension de paiement

« Élément manquant : offers ». C’est le message renvoyé par l’outil de test des résultats enrichis de Google au lendemain de la migration d’une extension de paiement sur un site d’artisanat vendant des pièces en céramique. Les étoiles d’avis et le prix, qui apparaissaient jusque-là sous les résultats de recherche pour plusieurs dizaines de fiches produit, avaient disparu du jour au lendemain.

Le contenu des fiches n’avait pourtant pas changé : ni les prix, ni les avis clients, ni la description des produits. Seule l’extension gérant les moyens de paiement avait été remplacée pour des raisons de coûts de transaction, sans lien apparent avec le balisage structuré des fiches produit.

Symptôme : disparition progressive des étoiles dans les résultats

Le premier signal est venu de la Search Console, dans le rapport dédié aux éléments Product, qui a commencé à signaler une baisse du nombre d’éléments valides détectés sur le site, sans erreur bloquante immédiate. Quelques jours plus tard, les étoiles d’avis, visibles jusque-là dans les résultats de recherche pour les fiches les plus consultées, ont cessé d’apparaître pour les visiteurs.

Diagnostic : un champ obligatoire devenu vide

L’inspection du code source d’une fiche produit concernée, via l’outil de test des résultats enrichis, a révélé que le bloc JSON-LD de type Product était toujours présent, mais que son champ offers, obligatoire pour l’affichage du prix dans un résultat enrichi, était devenu vide. Un examen plus poussé a montré que ce champ n’était en réalité jamais généré par le thème ni par l’extension de référencement, mais par l’ancienne extension de paiement elle-même, qui injectait les informations de prix et de disponibilité directement dans le balisage structuré de la fiche produit.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Bol en grès émaillé fait main",
  "offers": {}
}

La nouvelle extension de paiement, choisie uniquement sur des critères de coût de transaction, ne proposait tout simplement pas cette fonctionnalité annexe de génération de balisage structuré, considérée comme secondaire par son éditeur mais qui s’est révélée essentielle pour ce site.

Correctif : générer le balisage indépendamment du moyen de paiement

Plutôt que de dépendre d’une fonctionnalité annexe d’une extension de paiement, le correctif a consisté à générer le champ offers directement depuis les données produit natives de WooCommerce, indépendamment de l’extension de paiement active.

add_filter( 'woocommerce_structured_data_product', function( $markup, $product ) {
    $markup['offers'] = array(
        '@type'         => 'Offer',
        'price'         => $product->get_price(),
        'priceCurrency' => get_woocommerce_currency(),
        'availability'  => $product->is_in_stock()
            ? 'https://schema.org/InStock'
            : 'https://schema.org/OutOfStock',
    );
    return $markup;
}, 20, 2 );

Cette approche s’appuie sur le filtre natif woocommerce_structured_data_product, déjà présent dans le cœur de WooCommerce, ce qui rend le balisage totalement indépendant du choix futur de moyen de paiement.

Vérification après correctif

1. Repasser chaque fiche produit concernée dans l’outil de test des résultats enrichis pour confirmer la présence complète du champ offers.
2. Vérifier dans la Search Console que le nombre d’éléments Product valides remonte sur les jours suivants.
3. Contrôler visuellement, sur un échantillon de requêtes, le retour effectif des étoiles et du prix dans les résultats de recherche, ce dernier point pouvant prendre plusieurs jours après validation technique.

Prévention pour les prochains changements d’extension

• Établir la liste des fonctionnalités annexes réellement fournies par chaque extension avant tout remplacement, pas uniquement sa fonction principale déclarée.
• Centraliser la génération du balisage structuré sur une seule extension ou un seul bloc de code maison, jamais répartie entre plusieurs extensions dont l’une pourrait disparaître.
• Ajouter un contrôle automatisé, exécuté après chaque changement d’extension e-commerce, qui vérifie la présence du champ offers sur un échantillon de fiches produit.

Sur ce genre de site, le balisage structuré ne doit jamais dépendre d’une extension qui n’a pas pour vocation première de le générer : le jour où elle change, la moitié du site perd une fonctionnalité que personne n’avait identifiée comme critique.

En résumé

La disparition d’un résultat enrichi Product après un changement d’extension de paiement pointe presque toujours vers une dépendance cachée : une fonctionnalité annexe fournie par une extension dont ce n’était pas la mission première. Générer le balisage structuré directement depuis les données natives de la plateforme e-commerce, via un filtre du cœur, évite que ce type de disparition ne se reproduise au prochain changement de prestataire de paiement.