Synchronisation des prix WooCommerce dans l'aperçu WhatsApp
Une synchronisation des prix WooCommerce dans l'aperçu WhatsApp signifie que le montant affiché sur la carte est extrait de votre catalogue au moment où la carte est générée — et non figé dans une image créée une fois pour toutes. Lorsque c'est le cas, la seule question qui reste est quand WhatsApp relit le lien, et c'est précisément la seule chose qu'aucune boutique ne peut contrôler.
La réponse courte
Un prix ne peut apparaître dans un aperçu que si l'image est construite à partir de données produit en direct. Une image à la une statique n'a aucun prix à afficher, jamais ; une carte conçue une fois porte le prix qu'elle avait ce jour-là. WooCommerce ne fournit par défaut aucune image étiquetée avec un prix, donc la plainte « ancien prix dans l'aperçu » recouvre en réalité deux questions :
- La carte connaît-elle le prix actuel ? — une décision de conception, et celle que vous pouvez corriger.
- La plateforme a-t-elle relu la page depuis que le prix a changé ? — c'est l'horloge de WhatsApp, pas la vôtre.
Pourquoi le prix devient obsolète
| Cause | Ce que vous constatez | Pourquoi cela se produit |
|---|---|---|
| La balise pointe vers l'image mise en avant | Aucun prix du tout | Une photo de produit ne contient pas de prix |
| La carte a été créée une seule fois | Le prix du jour de la conception | Rien ne la régénère |
| Une promotion est terminée | Un prix barré pour une remise qui n'est plus valable | L'image porte encore l'ancien badge |
| Le cache de page sert un ancien HTML | L'ancienne carte, encore | Le crawler ne voit jamais la nouvelle URL og:image |
Seuls les trois premiers cas concernent la carte. Le quatrième concerne votre couche de cache, et il est identique vu de l'extérieur — c'est pourquoi l'ordre des vérifications dans Instant WhatsApp Image Update for WooCommerce a son importance.
Ce que lit réellement une carte synchronisée
FastOG signe une URL de couverture à chaque requête, et les props proviennent du produit en direct :
| Élément de la carte | Source | Remarque |
|---|---|---|
| Prix | get_price() |
Sur un produit en promotion, il s'agit bien du prix promotionnel |
| Prix barré (« était ») | le prix normal | Envoyé uniquement lorsque le produit est réellement en promotion — un « était » égal au prix actuel est un prix barré que personne n'a obtenu |
| Badge de promotion | l'état promotionnel du produit | Apparaît et disparaît avec la promotion |
| Stock | état du stock | Reflète le catalogue au moment du rendu |
| Photo | image principale d'abord, puis galerie | Composée à l'intérieur de la carte, non recadrée par la plateforme |
C'est la différence entre « dynamique » et réellement dynamique : les valeurs ne sont pas des espaces réservés remplis par un designer, elles sont lues depuis votre boutique à chaque construction d'une carte.
Fonctionnement de la « synchronisation » dans les deux sens
Catalogue → carte. Chaque valeur ci-dessus est lue au moment du rendu. Modifiez un prix et le rendu suivant affiche le nouveau ; il n'y a ni étape d'export ni fichier à re-téléverser.
Carte → cache. Chaque valeur circule aussi à l'intérieur de l'URL de couverture signée. Une modification de prix change donc l'URL — ce qui signifie que l'ancienne image n'est plus adressable, que le CDN n'a rien de périmé à servir et qu'aucun contournement de cache n'est nécessaire. Aucun autre outil de cette catégorie ne fonctionne ainsi, car un plugin auto-hébergé indexe son image sur un nom de fichier qui ne change jamais.
Carte → Facebook. L'enregistrement d'un produit déclenche le webhook natif product.updated de WooCommerce, et FastOG met en file un nouveau scraping Meta pour le permalien de ce produit, afin que Facebook remplace la carte en cache au lieu d'attendre des semaines. Voir Force a Facebook Open Graph Cache Refresh.
Carte → WhatsApp. Rien ne peut être poussé. La bonne carte attend la prochaine lecture.
Le cas limite de la vente programmée
Une vente qui démarre à minuit sans que personne ne touche au produit ne déclenche aucun webhook — un détail qui met à mal toute conception reposant sur « on rafraîchit à l'enregistrement », y compris notre ping Facebook.
Ce qui sauve la carte, c'est qu'elle n'est pas générée à l'avance : la couverture est construite à la demande à partir des données actuelles du catalogue, si bien que la première récupération après minuit affiche déjà le prix promotionnel et le badge. Le chiffre obsolète ne peut subsister que dans le cache d'aperçu d'une plateforme, où il sera remplacé selon le calendrier propre à cette plateforme. Une carte qui est rendue, plutôt qu'exportée, est la seule qui survive à une vente que personne n'a enregistrée.
Vérifier que le numéro est synchronisé
Le prix est visible dans l'URL de la couverture elle-même, ce qui permet de le vérifier sans débogueur :
# What the page is serving right now
curl -s https://your-store.com/product/example | grep -o 'og:image[^>]*' | head -1
# Open that cover URL in a browser and compare the number against the product page.
Si les paramètres de l'URL et la carte rendue portent tous deux le prix actuel, et que la page produit affiche le même, le côté boutique est synchronisé et toute obsolescence restante provient d'un cache de plateforme. Si l'URL porte encore l'ancien prix, le cache de la page sert du HTML antérieur à la modification — purgez-le.
Pour le voir de bout en bout, collez une URL de produit dans See Your Links The Way Buyers Do : l'outil lit les balises en direct et génère une couverture à partir des mêmes données produit, côte à côte avec ce que les plateformes afficheraient aujourd'hui.
FAQ
Comment afficher un prix dans un aperçu de lien WhatsApp ?
Servez un og:image qui contient le prix — c'est-à-dire une image générée à partir de votre catalogue, et non une photo statique. WhatsApp affiche l'image vers laquelle pointe la balise, au format 1200×630 ; le prix n'apparaît que s'il a été dessiné dans cette image.
Pourquoi l'aperçu affiche-t-il encore l'ancien prix après la fin de la promotion ?
Deux causes probables : l'image servie par la page n'a pas changé (cache de page, ou image statique), ou WhatsApp affiche un aperçu mis en cache avant la modification. Vérifiez d'abord l'URL og:image actuelle — si son prix est aussi obsolète, le problème vient de la boutique ; s'il est à jour, il vient de WhatsApp.
La carte affiche-t-elle le prix promotionnel ou le prix normal ?
Le prix promotionnel — c'est ce que WooCommerce remonte comme prix actuel — accompagné du prix normal en prix barré, et uniquement lorsque le produit est réellement en promotion.
Tous les plans dessinent-ils le prix et le badge de promotion ?
Oui. Les champs de template ne sont pas restreints à un niveau sur FastOG : le prix, le prix barré et les badges de stock sont disponibles sur tous les plans. Les plans diffèrent par les types de pages, le nombre d'éléments autorisés et l'étendue des templates, pas par ce qu'une couverture peut afficher.
Le prix est-il mis à jour pour les liens déjà partagés ?
Pour Facebook, FastOG demande un nouveau scraping après la mise à jour du produit. Pour WhatsApp, LinkedIn et X, la prochaine lecture a lieu selon le calendrier propre à chaque plateforme ; aucune garantie de délai publique ni API de rafraîchissement programmatique n'est revendiquée pour ces plateformes.
Et si je change le prix sans changer le template ?
C'est le cas normal et cela fonctionne : le template définit la mise en page, le catalogue fournit les valeurs. Rien à redessiner et aucune image à réexporter.
Un lien partagé pendant la promotion continuera-t-il d'afficher le prix promotionnel après sa fin ?
Uniquement tant que l'aperçu mis en cache par une plateforme subsiste. L'URL de la couverture change avec le catalogue, donc la première lecture fraîche obtient la carte d'après-promotion.
Existe-t-il un plan gratuit ?
Oui. Le niveau gratuit Community couvre jusqu'à 100 éléments sur les pages produit, catégorie, boutique et article de blog, avec cinq templates de base plus les templates produit Black Friday et Seasonal Offer. Ses couvertures sont propres — aucun plan ne porte de filigrane, Community inclus. Community s'exécute sur le serveur Community partagé et est limité par des quotas de débit par boutique/IP plutôt que par du branding. Les plans payants utilisent un serveur dédié distinct de Community, augmentent le nombre d'éléments autorisés et débloquent des templates et fonctionnalités supplémentaires (badges de notation à partir de Starter, mapping de metafields à partir de Pro, règles scoped et rendu prioritaire à partir de Scale). Les plans payants incluent un essai de 14 jours sans carte bancaire requise.
Voir aussi
Essayez gratuitement — aucune inscription requise
Prévisualisez et testez des images OG dynamiques en quelques secondes.
Ouvrir le testeur d'images OG gratuit