Directe WhatsApp-afbeeldingsupdate voor WooCommerce

Een directe WhatsApp-afbeeldingsupdate voor WooCommerce betekent dat de juiste kaart klaarstaat op het moment dat je een product opslaat — niet dat WhatsApp de link op commando opnieuw leest. Niemand kan WhatsApp dwingen een link opnieuw te lezen: het slaat previews op in de app van de ontvanger en biedt geen refresh-API. Wat je beheert, is alles aan de winkelkant, en dat is genoeg om ervoor te zorgen dat de volgende persoon die de link deelt, het actuele product, de prijs en de foto ziet.

Het korte antwoord

Er zijn twee klokken in een WhatsApp-voorbeeld, en slechts één ervan is van jou.

Elke bewering over "directe updates" die de tweede rij negeert, is een leugen, en elk product dat alleen de eerste rij oplost, toont nog steeds de juiste afbeelding zodra WhatsApp weer kijkt. Dat is het hele spel: zorg dat de winkelkant aantoonbaar correct is en hoop daarna niet meer dat WhatsApp meewerkt.

Waarom je update niet verschijnt

Er zitten vier afzonderlijke caches tussen "ik heb de prijs gewijzigd" en "de preview is gewijzigd". Merchants geven bijna altijd de verkeerde de schuld.

Rij 1 is degene die mensen missen. Een gecachte HTML-pagina bevat nog steeds de oude og:image-URL, dus zelfs een perfect opnieuw opgebouwde kaart wordt nooit ontdekt. Maak eerst de paginacache leeg en kijk dan naar de rest.

Rijen 3 en 4 zijn de reden dat een versie toevoegen aan de afbeeldings-URL de enige betrouwbare cache-buster is — een nieuwe afbeeldings-URL is overal tegelijk een cachemiss.

Het WooCommerce-deel: je tag mag nooit verouderd zijn

Bij WooCommerce is het tagprobleem meestal een van twee dingen, en geen van beide is de schuld van WhatsApp:

• Er is helemaal geen og:image. WordPress en WooCommerce geven er geen uit voor product, product_cat of de shop-pagina. Je SEO-plugin levert er een — en voor een product grijpt die naar de statische uitgelichte afbeelding.
• De tag bestaat wel, maar wijst naar een vast bestand. Een statische afbeeldings-URL kan niet veranderen wanneer de prijs dat doet. Elke share na de wijziging cachet opnieuw dezelfde verouderde afbeelding.

FastOG neemt de andere route. De cover is een ondertekende URL waarvan de query de waarden bevat die hem hebben geproduceerd, bij elk verzoek gelezen uit de live catalogus: de productnaam, de huidige prijs (get_price() — de sale-prijs bij een afgeprijsd product), de doorgestreepte "was"-prijs, de sale-badge, rating, voorraad en de productfoto.

Dat heeft een gevolg dat je maar beter ronduit kunt benoemen: een prijswijziging is een URL-wijziging. De oude URL beschrijft het product niet meer, dus de CDN heeft niets verouderds om te serveren, en de volgende fetch rendert opnieuw. Geen cache-busting-hack, geen checklist van "heb ik het wel gepurged".

Wat er gebeurt als je op Opslaan klikt bij een product

Voor Facebook — het enige platform dat iedereen laat vragen — doet FastOG het vragen voor je:

1. WooCommerce vuurt zijn eigen product.updated / product.created webhook af (de permalink zit in de payload).
2. FastOG ververst zijn catalogusrecord voor de winkel, zodat de volgende cover uit actuele data wordt getekend.
3. Er wordt een RefreshMetaPreview-taak in de wachtrij gezet voor de pagina-URL van dat product. Die wordt in de wachtrij gezet in plaats van inline — een volledige catalogussynchronisatie mag niet één blokkerende call per item naar Meta toevoegen — en wordt gededupliceerd, zodat het herhaaldelijk opnieuw opslaan van hetzelfde product niet tegen Meta's rate limit aanloopt.
4. De taak roept Meta's scrape-endpoint aan met een app access token, en Meta vervangt zijn gecachte kopie van de preview voor die pagina.

Dit is bewust best-effort. Als Meta traag is, weigert of rate-limitet, slaagt de synchronisatie alsnog: de tag op je pagina is al correct, en de enige kosten zijn dat Meta volgens zijn eigen schema ververst in plaats van direct.

Het ververst WhatsApp, LinkedIn of X niet, omdat geen van hen een API biedt om iets te verversen. Dat is geen beperking van FastOG — het is de afwezigheid van een endpoint aan de andere kant.

Controleer het in de juiste volgorde

Wanneer een voorbeeld niet bijwerkt, werk je deze lijst af in plaats van te gokken:

# 1. Does the page still serve the OLD tag? (page cache — cache row 1)
curl -s https://your-store.com/product/example | grep -i 'og:image'

# 2. Is that image URL reachable without credentials? (cache row 3)
curl -I "https://...the-og-image-url-from-step-1..."

# 3. Did the image URL change after the edit? Compare with the URL from before.

Als stap 1 nog steeds de URL van vóór de bewerking toont, kan niets verderop helpen — leeg de paginacache. Als stap 1 een nieuwe URL toont en stap 2 geeft 200 OK terug met een image/png, dan klopt de kant van de winkel en kijk je naar cacheregel 2, de klok van WhatsApp.

Wil je alle vier de regels van buitenaf zien? Plak de product-URL in Bekijk je links zoals kopers ze zien — het haalt de pagina op zoals een crawler dat doet, leest de live tags en toont het resultaat zoals WhatsApp, X en Messenger het weergeven, naast een FastOG-omslag die is opgebouwd uit dezelfde productgegevens. Geen aanmelding nodig.

Helpt een cache-busting-plugin of ?v=2?

Ze helpen op één smalle manier, en de afweging is reëel.

Een preview wordt gecachet op basis van de link die mensen hebben gedeeld. Een URL die niemand ooit heeft gedeeld, heeft geen gecachete preview — daarom is het toevoegen van een wisselende querystring (?v=2) zo'n gangbare truc. Het werkt, en het kost je iets: de gedeelde link is niet langer je canonieke product-URL, zoekmachines zien een tweede adres, en analytics splitsen het verkeer.

FastOG past hetzelfde mechanisme één niveau lager toe, waar het gratis is. De pagina-URL blijft canoniek; alleen de afbeeldings-URL verandert mee met de content. Zo kan de oude cover niet opnieuw worden geserveerd, en de link die je deelt is nog steeds de productpagina die je geïndexeerd wilt hebben.

Wat niemand kan oplossen, en waarom we dat zeggen

• WhatsApp slaat de preview op in de app van de ontvanger. Er is geen API, geen debugger en geen tool — ook de onze niet — die daar bij kan.
• LinkedIn en X bieden ook geen gedocumenteerde programmatische invaliderings-API. Hun crawlers lezen op hun eigen schema opnieuw; beschouw een schatting van de timing door een derde partij niet als een garantie van het platform.
• Facebook is de uitzondering, en het enige platform dat FastOG voor je pingt. Zie Force a Facebook Open Graph Cache Refresh voor de werking.

Een leverancier die je vertelt dat hij WhatsApp ververst, beschrijft het gedrag van Facebook en hoopt dat je het niet controleert. Wij geven je liever de accurate kaart.

FAQ

Kan ik WhatsApp dwingen om een linkvoorbeeld onmiddellijk bij te werken?

Nee. WhatsApp biedt geen refresh-endpoint of debugger, en het gecachte voorbeeld staat in de app van de ontvanger. Je kunt er alleen voor zorgen dat de juiste afbeelding klaarstaat voor de volgende keer dat de link wordt gelezen.

Hoe lang bewaart WhatsApp een linkvoorbeeld?

Er is geen gepubliceerd cijfer en geen manier om het op te vragen — het is per ontvanger, per apparaat. Behandel het als "totdat WhatsApp anders beslist" en optimaliseer in plaats daarvan de kant van de winkel.

Waarom werd het bij mij wel bijgewerkt, maar bij mijn klant niet?

Omdat je testte door een link te delen die nooit eerder vanaf jouw apparaat was gedeeld, of je stuurde hem naar een verse chat. Je klant leest een gecacht voorbeeld. Hun voorbeeld en het jouwe staan los van elkaar.

Forceert het wijzigen van de product-URL een update?

Een URL die niemand heeft gedeeld heeft geen gecacht voorbeeld, dus ja — ten koste van een tweede adres voor hetzelfde product. Het wijzigen van de afbeeldings-URL geeft hetzelfde effect zonder je permalink aan te raken, en dat is wat FastOG doet.

Heb ik een plugin nodig, of kan ik mijn thema zelf aanpassen?

Een statische og:image in je thema is veel beter dan niets, en het is gratis. Wat het niet kan, is per product verschillen zonder per product handmatig een afbeelding te maken — of een prijswijziging volgen. Dat is het punt waarop een dynamische cover zichzelf terugverdient.

Mijn site staat niet op FastOG. Helpt dit dan toch?

Ja. De vier caches, de controlevolgorde en de platformlimieten beschrijven hoe de platforms zich gedragen, niet hoe FastOG zich gedraagt. Werk de lijst af met curl en de debuggers.

Is er een gratis plan?

Ja. Het gratis Community-niveau dekt tot 100 items over product-, categorie-, winkel- en blogpostpagina's, met vijf basistemplates plus de producttemplates Black Friday en Seasonal Offer. De covers zijn schoon — geen enkel plan bevat een watermerk, Community inbegrepen. Community rendert op de gedeelde Community-server en wordt begrensd door rate limits per winkel/IP in plaats van door branding. Betaalde plannen gebruiken een eigen server, los van Community, verhogen het itemaantal en ontgrendelen extra templates en mogelijkheden (rating badges vanaf Starter, metafield-mapping vanaf Pro, scoped rules en priority rendering vanaf Scale). Betaalde plannen bevatten ook een proefperiode van 14 dagen zonder creditcard.

Gerelateerd

• WhatsApp-linkvoorbeeld wordt niet getoond? Los de og:image op
• Gids voor social-previewcache: Facebook, WhatsApp, LinkedIn, X, Slack en Discord
• Forceer een verversing van de Facebook Open Graph-cache
• WooCommerce-prijsynchronisatie in het WhatsApp-voorbeeld
• OG-afbeeldingen cachen
• OG-afbeeldingsformaat: 1200×630 uitgelegd
• WooCommerce-integratie: FastOG voor WooCommerce