Forcer l’actualisation du cache Open Graph de Facebook

Vous pouvez forcer l’actualisation du cache Open Graph de Facebook, car Facebook — seul parmi les grandes plateformes — expose un moyen programmatique de le demander. Utilisez soit le bouton Scrape Again du Sharing Debugger pour un lien unique, soit appelez le point de terminaison scrape de l’API Graph avec un jeton d’accès d’application. Il n’existe aucun moyen de forcer WhatsApp, LinkedIn ou X : ils ne publient aucune API de ce type, pour personne.

Ce qui piège tout le monde

Meta met en cache un aperçu de lien indexé sur l'URL de la page et stocke sa propre copie de l'image. Il ne relit pas votre page pour constater que og:image pointe désormais ailleurs.

Ce flux de travail échoue donc, et c'est celui que la plupart des gens essaient :

Modifier l'image de couverture → l'URL og:image est nouvelle → supposer que Facebook la détectera → ce n'est pas le cas.

Une nouvelle URL d'image contourne le CDN d'images. Elle ne fait rien pour le cache indexé sur la page de Meta. Pour faire bouger Facebook, vous devez indiquer à Meta que la page a changé.

Cache	Indexé sur	Effacé par
Votre cache de page / CDN	l'URL de la page	sa purge
Le cache d'aperçu de lien de Meta	l'URL de la page	le point de terminaison de récupération (scrape endpoint) ou le Sharing Debugger
La copie de l'image par Meta	l'URL de l'image	une nouvelle URL d'image
Votre CDN d'images	l'URL de l'image	une nouvelle URL d'image

Ouvrez developers.facebook.com/tools/debug, collez l'URL de la page, puis appuyez sur Scrape Again. Meta récupère à nouveau la page et reconstruit son aperçu en cache.

C'est également le meilleur validateur gratuit dont vous disposez, car il rapporte ce que Meta a réellement trouvé plutôt que ce que vous espériez voir : og:image manquants ou dupliqués, images inaccessibles, formats non pris en charge. Deux choses qu'il ne fera pas : il ne peut pas toucher à WhatsApp (cache séparé, dans l'application du destinataire), et ce n'est pas un outil de catalogue — il traite une URL à la fois, avec une limite de débit, et nécessite une intervention humaine.

Option 2 — l’API Graph (c’est ce qu’appelle un plugin)

L’équivalent programmatique utilisé par FastOG est un POST vers l’API Graph avec scrape=true :

bash

curl -X POST \
  "https://graph.facebook.com/v21.0/?id=$(python3 -c 'import urllib.parse,sys;print(urllib.parse.quote(sys.argv[1],safe=""))' 'https://your-store.com/product/example')&scrape=true&access_token=${APP_ID}|${APP_SECRET}"

Quatre détails importants :

id est l’URL de la page, pas l’URL de l’image. Meta indexe son cache sur la page, donc envoyer une requête à l’adresse de l’image ne rafraîchit rien.
Un jeton est requis — Meta en exige un sur cet endpoint depuis octobre 2017. Un jeton d’accès d’application sous la forme {app_id}|{app_secret} suffit, et il ne nécessite aucune connexion utilisateur, ce qui rend justement l’appel possible depuis un travail en arrière-plan.
Les versions de l’API Graph évoluent. FastOG épingle une version testée de l’API Graph ; consultez la documentation et le journal des modifications actuels de Meta avant d’épingler une version dans votre propre code.
Considérez-le comme un effort au mieux. Meta limite le débit des appels de scraping, et un refus signifie seulement que Facebook rafraîchit selon son propre calendrier au lieu de le faire immédiatement — les balises de votre page sont déjà correctes.

Comme l’appel est soumis à une limite de débit, ne l’exécutez pas en ligne à chaque enregistrement d’un grand catalogue. Mettez-le en file d’attente et dédupliquez par URL afin que les enregistrements répétés du même produit inchangé ne consomment pas la limite de débit.

Option 3 — un plugin qui s’en charge pour vous

Les plugins commercialisés comme « actualisation du cache Open Graph » se répartissent en deux groupes, et un seul d’entre eux peut corriger Facebook :

Mécanisme	Ce qu’il vide	Corrige un aperçu Facebook obsolète ?
Ajoute une chaîne de requête changeante à l’URL de l’image (`?v=timestamp`)	votre CDN d’images	Non — le cache de Meta est indexé sur la page
Appelle le point de terminaison de scrape pour l’URL de la page	le cache d’aperçu de Meta	Oui

Avant d’en installer un, vérifiez de quel type il s’agit. Un paramètre d’horodatage est une vraie correction pour une image obsolète et une non-correction pour une carte Facebook obsolète.

FastOG pour WooCommerce fait la deuxième option, et vous n’avez rien à configurer. Le plugin enregistre les webhooks natifs des produits WooCommerce, donc l’enregistrement d’un produit déclenche un re-scrape Meta pour le permalien de ce produit — mis en file d’attente, dédupliqué dans une courte fenêtre, et conçu au mieux pour qu’un refus ne fasse jamais échouer l’enregistrement. Cela s’applique aux pages produits (product.created / product.updated) ; les modifications de catégories et de blog ne sont pas couvertes.

Le côté image est traité séparément, et différemment de tous les concurrents : comme une URL de couverture FastOG contient les valeurs qui l’ont produite, la modification du prix ou de la photo génère une nouvelle URL de couverture. Meta ne peut pas resservir une image dont l’adresse n’existe plus.

Là où Facebook ne suffit pas

Plateforme	Pouvez-vous forcer un rafraîchissement ?	Ce qui se passe réellement
Facebook	Oui — débogueur ou `scrape=true`	Demande un nouveau scraping ; le délai de propagation varie
WhatsApp	Non	L'aperçu est mis en cache dans l'application du destinataire ; aucune API n'existe
LinkedIn	Aucune API programmatique documentée	Relit selon son propre calendrier ; aucune garantie de délai public n'est donnée ici
X / Twitter	Aucune API programmatique documentée	Relit selon son propre calendrier ; aucune garantie de délai public n'est donnée ici
Slack, Discord	Non	Caches de courte durée qui se vident d'eux-mêmes en quelques minutes à quelques heures

Si un aperçu est obsolète sur WhatsApp, la réponse n'est pas un outil Facebook — c'est bien configurer le côté boutique pour que la prochaine lecture soit correcte.

Lorsque l’ancienne image s’affiche encore après un scrape réussi

Parcourez cette liste, dans l’ordre :

La page sert-elle encore l’ancienne balise ? curl -s https://your-store.com/product/example | grep -i 'og:image' — une page HTML en cache avec un og:image obsolète annule entièrement le scrape. Purgez le cache de la page.
La page affiche-t-elle plus d’un og:image ? Si deux plugins en émettent chacun un, le crawler prend le premier qu’il lit. Comptez-les.
L’image est-elle accessible et non bloquée ? curl -I <image-url> doit renvoyer 200 avec un Content-Type d’image. Les crawlers des réseaux sociaux respectent robots.txt, donc une image sur un chemin Disallow: échoue d’une manière qui ressemble à un fichier corrompu — et curl ne le reproduira jamais, car curl ignore robots.txt.
L’URL de l’image a-t-elle réellement changé ? Si ce n’est pas le cas, le contenu n’a pas changé non plus — vérifiez que la modification du prix/de la photo a atteint la source à partir de laquelle la carte est générée.
Vérifiez à nouveau le débogueur. S’il signale désormais la nouvelle image alors que Facebook affiche toujours l’ancienne carte, vous observez la propagation propre à Facebook, et non vos balises.

FAQ

Existe-t-il une API officielle pour vider le cache Open Graph de Facebook ?

FastOG utilise le point de terminaison scrape (POST https://graph.facebook.com/{version}/?id={page-url}&scrape=true&access_token={token}). Meta documente le Sharing Debugger et le flux d'exploration programmatique ; la forme exacte du point de terminaison et la version de l'API Graph peuvent changer. Vérifiez-les donc dans la documentation actuelle de Meta avant de les implémenter vous-même.

Non. C'est un outil public qui fonctionne pour toute URL publique. Ce qu'il ne peut pas faire, c'est s'exécuter selon un planning ou couvrir un catalogue.

Un nouveau scrape me coûtera-t-il un rendu FastOG ?

En général, non. Une URL de couverture est dérivée du contenu : si le contenu n'a pas changé, l'URL n'a pas changé non plus, et la récupération est un succès de cache qui ne coûte aucun rendu. Si le prix a changé, l'URL a changé — c'est un nouveau rendu, et c'est le rendu que vous souhaitiez.

Un nouveau scrape de Facebook corrige-t-il mon aperçu WhatsApp ?

Non. Ce sont des caches distincts. Le débogueur de Facebook reste utile comme validateur — il récupère la page de la même manière que WhatsApp et rapporte ce qu'il a trouvé — mais il ne peut pas actualiser WhatsApp.

Combien de temps Facebook conserve-t-il un aperçu si je n'envoie jamais de ping ?

Meta documente une période de re-scrape standard d'environ 24 heures, mais le temps de propagation exact peut varier. C'est pourquoi le débogueur et le chemin d'exploration programmatique existent.

Dois-je envoyer un ping pour chaque produit après un import de catalogue ?

C'est à cela que sert la file d'attente. Envoyer une requête par produit en ligne atteindra la limite de débit de Meta et ralentira la requête du marchand ; mise en file et dédupliquée, une analyse du catalogue se déroule sans risque.

Et si Meta refuse la requête ?

Rien ne casse. Un ping refusé ou limité signifie que Facebook actualise selon son propre calendrier plutôt qu'immédiatement — les balises sur la page sont déjà correctes, c'est pourquoi l'appel est au mieux (best-effort) plutôt qu'une dépendance stricte.