Forceer een Facebook Open Graph-cacheverversing

Je kunt een Facebook Open Graph-cacheverversing forceren, omdat Facebook — als enige van de grote platforms — een programmatische manier biedt om dit te vragen. Gebruik ofwel de Scrape Again-knop van de Sharing Debugger voor een enkele link, of roep het scrape-eindpunt van de Graph API aan met een app-toegangstoken. Er is geen manier om WhatsApp, LinkedIn of X te forceren: zij publiceren geen dergelijke API, voor niemand.

Waar iedereen over struikelt

Meta cachet een link preview op basis van de pagina-URL en slaat een eigen kopie van de afbeelding op. Het leest je pagina niet opnieuw om te ontdekken dat og:image nu naar iets anders verwijst.

Dus deze workflow faalt, en het is degene die de meeste mensen proberen:

Verander de cover → de og:image-URL is nieuw → ga ervan uit dat Facebook het oppikt → dat doet het niet.

Een nieuwe afbeeldings-URL doorbreekt de afbeelding-CDN. Het doet niets aan de op pagina-URL gebaseerde cache van Meta. Om Facebook te bewegen, moet je Meta vertellen dat de pagina is veranderd.

Cache	Gebaseerd op	Gewist door
Je pagina-cache / CDN	de pagina-URL	deze te purgen
Meta's link-preview-cache	de pagina-URL	het scrape-endpoint of de Sharing Debugger
Meta's kopie van de afbeelding	de afbeeldings-URL	een nieuwe afbeeldings-URL
Je afbeelding-CDN	de afbeeldings-URL	een nieuwe afbeeldings-URL

Open developers.facebook.com/tools/debug, plak de pagina-URL en druk op Scrape Again. Meta haalt de pagina opnieuw op en herbouwt de gecachte preview.

Het is ook de beste gratis validator die je hebt, omdat het rapporteert wat Meta daadwerkelijk heeft gevonden in plaats van wat je hoopte dat er stond: ontbrekende of gedupliceerde og:image, onbereikbare afbeeldingen, niet-ondersteunde formaten. Twee dingen doet het niet: het kan WhatsApp niet aanraken (aparte cache, in de app van de ontvanger), en het is geen catalogustool — het is één URL tegelijk, met snelheidslimieten, met een mens ervoor.

Optie 2 — de Graph API (dit is wat een plugin aanroept)

Het programmatische equivalent dat FastOG gebruikt, is een POST naar de Graph API met 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}"

Vier details die ertoe doen:

id is de pagina-URL, niet de afbeeldings-URL. Meta slaat zijn cache op basis van de pagina op, dus het pingen van het afbeeldingsadres ververst niets.
Een token is vereist — Meta vereist er sinds oktober 2017 een op dit endpoint. Een app access token in de vorm {app_id}|{app_secret} is voldoende, en het heeft geen gebruikerslogin nodig, wat precies is wat de aanroep mogelijk maakt vanuit een achtergrondtaak.
Graph API-versies veranderen. FastOG pind een geteste Graph API-versie; raadpleeg Meta's huidige documentatie en changelog voordat je een versie pint in je eigen code.
Beschouw het als best-effort. Meta past rate limiting toe op scrape-aanroepen, en een weigering betekent alleen dat Facebook op zijn eigen schema ververst in plaats van onmiddellijk — de tags op je pagina zijn al correct.

Omdat het rate-limited is, moet je het niet inline afvuren bij elke opslag van een grote catalogus. Zet het in een wachtrij en de-dupliceer op URL, zodat herhaalde opslagen van hetzelfde ongewijzigde product geen rate limit verbruiken.

Optie 3 — een plugin die het voor je doet

Plugins die worden aangeprezen als een "Open Graph cache refresh" vallen in twee groepen uiteen, en slechts één daarvan kan Facebook repareren:

Mechanisme	Wat het wist	Lost een verouderde Facebook-preview op?
Voegt een veranderende query string toe aan de image-URL (`?v=timestamp`)	jouw image-CDN	Nee — Meta's cache is gekoppeld aan de pagina
Roept het scrape endpoint aan voor de pagina-URL	Meta's preview-cache	Ja

Voordat je er een installeert, zoek uit welke het is. Een tijdstempelparameter is een echte oplossing voor een verouderde image en geen oplossing voor een verouderde Facebook-kaart.

FastOG voor WooCommerce doet het tweede, en je hoeft niets te configureren. De plugin registreert WooCommerce's native product-webhooks, zodat het opslaan van een product een Meta-herscrape voor de permalink van dat product uitzendt — in een wachtrij, gededupliceerd binnen een kort tijdsvenster, en best-effort door ontwerp, zodat een weigering het opslaan nooit laat mislukken. Het geldt voor productpagina's (product.created / product.updated); categorie- en blogbewerkingen worden niet ondersteund.

De image-kant wordt apart afgehandeld, en anders dan bij elke concurrent: omdat een FastOG-cover-URL de waarden bevat die deze hebben geproduceerd, levert het bewerken van de prijs of de foto een nieuwe cover-URL op. Meta kan geen afbeelding opnieuw serveren waarvan het adres niet langer bestaat.

Waar Facebook niet genoeg is

Platform	Kun je een verversing afdwingen?	Wat er daadwerkelijk gebeurt
Facebook	Ja — debugger of `scrape=true`	Vraagt een nieuwe scrape aan; de verspreidingstijd varieert
WhatsApp	Nee	De preview wordt gecachet in de app van de ontvanger; er bestaat geen API
LinkedIn	Geen gedocumenteerde programmatische API	Leest opnieuw volgens een eigen schema; hier wordt geen publieke tijdsgarantie gegeven
X / Twitter	Geen gedocumenteerde programmatische API	Leest opnieuw volgens een eigen schema; hier wordt geen publieke tijdsgarantie gegeven
Slack, Discord	Nee	Kortlevende caches die zichzelf binnen enkele minuten tot uren wissen

Als een preview verouderd is op WhatsApp, is het antwoord geen Facebook-tool — het is de winkelzijde goed instellen zodat de volgende leesbewerking correct is.

Wanneer er na een succesvolle scrape nog steeds de oude afbeelding wordt getoond

Doorloop deze lijst in deze volgorde:

Serveert de pagina nog steeds de oude tag? curl -s https://your-store.com/product/example | grep -i 'og:image' — een gecachte HTML-pagina met een verouderde og:image maakt de scrape volledig ongedaan. Leeg de paginacache.
Print de pagina meer dan één og:image? Als twee plugins er elk één uitvoeren, neemt de crawler de eerste die hij leest. Tel ze.
Is de afbeelding bereikbaar en niet geblokkeerd? curl -I <image-url> zou 200 moeten retourneren met een afbeelding Content-Type. Sociale crawlers respecteren robots.txt, dus een afbeelding op een Disallow:-pad faalt op een manier die aanvoelt als een corrupt bestand — en curl zal dit nooit reproduceren, omdat curl robots.txt negeert.
Is de afbeeldings-URL daadwerkelijk veranderd? Als dat niet zo is, is de inhoud ook niet veranderd — controleer of de prijs-/fotobewerking de bron heeft bereikt waaruit de kaart wordt opgebouwd.
Controleer de debugger opnieuw. Als deze nu de nieuwe afbeelding rapporteert en Facebook nog steeds de oude kaart toont, kijk je naar Facebook's eigen propagatie, niet naar jouw tags.

FAQ

Bestaat er een officiële API om de Open Graph-cache van Facebook te wissen?

FastOG gebruikt het scrape-eindpunt (POST https://graph.facebook.com/{version}/?id={page-url}&scrape=true&access_token={token}). Meta documenteert de Sharing Debugger en de programmatische crawl-flow; de exacte vorm van het eindpunt en de Graph API-versie kunnen wijzigen. Controleer ze daarom tegen de huidige documentatie van Meta voordat je het zelf implementeert.

Nee. Het is een openbaar hulpmiddel en het werkt voor elke openbare URL. Wat het niet kan, is op een schema draaien of een catalogus bestrijken.

Kost een nieuwe scrape mij een FastOG-render?

Meestal niet. Een cover-URL is afgeleid van de inhoud. Als de inhoud niet is gewijzigd, is de URL dat ook niet, en is de fetch een cache-hit die geen render kost. Als de prijs is gewijzigd, is de URL gewijzigd — dat is één nieuwe render, en dat is de render die je wilde.

Lost een nieuwe scrape van Facebook mijn WhatsApp-preview op?

Nee. Het zijn afzonderlijke caches. De debugger van Facebook is nog steeds nuttig als validator — hij haalt de pagina op zoals WhatsApp dat doet en rapporteert wat hij heeft gevonden — maar hij kan WhatsApp niet verversen.

Hoe lang bewaart Facebook een preview als ik er nooit een ping naartoe stuur?

Meta documenteert een standaard her-scrape-periode van ongeveer 24 uur, maar de exacte propagatietijd kan variëren. Daarom bestaan de debugger en het programmatische crawl-pad.

Moet ik na een catalogusimport elk product pingen?

Daar is de wachtrij voor. Eén verzoek per product inline versturen raakt de rate limit van Meta en vertraagt het verzoek van de merchant; in de wachtrij en gededupliceerd loopt een catalogus-sweep zonder schade leeg.

Wat als Meta het verzoek weigert?

Er gaat niets kapot. Een geweigerde of rate-limited ping betekent dat Facebook op zijn eigen schema ververst in plaats van onmiddellijk — de tags op de pagina zijn al correct, daarom is de aanroep best-effort en geen harde afhankelijkheid.