WooCommerce-prijsynchronisatie in de WhatsApp-preview
Een WooCommerce-prijsynchronisatie in de WhatsApp-preview betekent dat het getal op de kaart op het moment dat de kaart wordt gegenereerd uit je catalogus komt — niet is ingebakken in een afbeelding die iemand ooit heeft gemaakt. Als dat klopt, is de enige overgebleven vraag wanneer WhatsApp de link opnieuw leest, en dat is precies het enige dat geen enkele winkel kan beheren.
Het korte antwoord
Een prijs kan alleen in een preview verschijnen als de afbeelding is opgebouwd uit live productgegevens. Een statische uitgelichte afbeelding heeft nooit een prijs om te tonen; een kaart die één keer is ontworpen, heeft de prijs die hij die dag had. WooCommerce levert standaard geen afbeelding met prijsinformatie, dus de klacht "oude prijs in de preview" is eigenlijk twee vragen:
- Weet de kaart de huidige prijs? — een ontwerpbeslissing, en degene die je kunt oplossen.
- Heeft het platform de pagina opnieuw gelezen sinds de prijs is gewijzigd? — de klok van WhatsApp, niet die van jou.
Waarom de prijs verouderd raakt
| Oorzaak | Wat je ziet | Waarom het gebeurt |
|---|---|---|
| De tag wijst naar de uitgelichte afbeelding | Helemaal geen prijs | Een productfoto bevat geen prijs |
| De kaart is één keer gemaakt | De prijs van de dag van het ontwerp | Niets genereert hem opnieuw |
| Een actie is afgelopen | Een doorgestreepte prijs voor een korting die voorbij is | De afbeelding draagt nog steeds de oude badge |
| De paginacache serveert oude HTML | Opnieuw de oude kaart | De crawler ziet nooit de nieuwe og:image-URL |
Alleen de eerste drie gaan over de kaart. De vierde gaat over je cachinglaag, en van buitenaf ziet die er identiek uit — daarom is de volgorde van de controle in Instant WhatsApp Image Update for WooCommerce belangrijk.
Wat een gesynchroniseerde kaart daadwerkelijk leest
FastOG ondertekent per verzoek een cover-URL, en de props komen uit het live product:
| Kaartelement | Bron | Opmerking |
|---|---|---|
| Prijs | get_price() |
Bij een afgeprijsd product is dit de actieprijs |
| Doorgestreepte ("was") prijs | de reguliere prijs | Wordt alleen meegestuurd wanneer het product daadwerkelijk in de aanbieding is — een "was"-prijs gelijk aan de huidige prijs is een doorgestreepte prijs die niemand heeft verdiend |
| Aanbiedingsbadge | de aanbiedingsstatus van het product | Verschijnt en verdwijnt met de aanbieding |
| Voorraad | voorraadstatus | Weerspiegelt de catalogus op het moment van renderen |
| Foto | eerst de uitgelichte afbeelding, dan de galerij | Samengesteld binnen de kaart, niet bijgesneden door het platform |
Dat is het verschil tussen "dynamisch" en daadwerkelijk dynamisch: de waarden zijn geen placeholders die een ontwerper heeft ingevuld, ze worden bij elke kaart die wordt gebouwd uit je winkel gelezen.
Hoe "sync" in beide richtingen werkt
Catalogus → kaart. Elke waarde hierboven wordt bij het renderen gelezen. Wijzig een prijs en de volgende render toont de nieuwe; er is geen exportstap en geen bestand om opnieuw te uploaden.
Kaart → cache. Elke waarde reist ook mee in de ondertekende cover-URL. Een prijswijziging verandert dus de URL — wat betekent dat de oude afbeelding niet meer adresseerbaar is, de CDN niets verouderds te serveren heeft en er geen cache-busting nodig is. Niets anders in deze categorie werkt zo, omdat een self-hosted plugin zijn afbeelding baseert op een bestandsnaam die nooit verandert.
Kaart → Facebook. Bij het opslaan van een product wordt WooCommerce's native product.updated-webhook afgevuurd, en FastOG zet een Meta re-scrape voor de permalink van dat product in de wachtrij, zodat Facebook de gecachte kaart vervangt in plaats van weken te wachten. Zie Force a Facebook Open Graph Cache Refresh.
Kaart → WhatsApp. Er kan niets worden gepusht. De juiste kaart staat klaar voor de volgende keer dat hij wordt gelezen.
Het randgeval van de geplande sale
Een sale die om middernacht begint terwijl niemand het product aanraakt, vuurt helemaal geen webhook af — een detail dat elk ontwerp van het type "we verversen bij opslaan" breekt, inclusief onze Facebook-ping.
Wat de kaart redt, is dat die niet vooraf wordt gegenereerd: de cover wordt op aanvraag opgebouwd uit de actuele catalogusgegevens, dus de eerste fetch na middernacht toont al de saleprijs en de badge. Het verouderde getal kan alleen overleven in de preview-cache van een platform, waar het volgens het eigen schema van dat platform wordt vervangen. Een kaart die gerenderd wordt in plaats van geëxporteerd, is de enige soort die een sale overleeft die niemand heeft opgeslagen.
Controleer of het nummer synchroon loopt
De prijs is zichtbaar in de cover-URL zelf, waardoor je dit kunt controleren zonder debugger:
# 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.
Als de parameters van de URL en de gerenderde kaart beide de huidige prijs bevatten, en de productpagina hetzelfde toont, dan is de winkelzijde gesynchroniseerd en is eventuele resterende veroudering een platformcache. Als de URL nog steeds de oude prijs bevat, dan serveert de paginacache HTML van vóór de bewerking — leeg die cache.
Om het end-to-end te zien, plak je een product-URL in Bekijk je links zoals kopers ze zien: die leest de live tags en rendert een cover op basis van dezelfde productgegevens, naast wat de platforms vandaag zouden tonen.
FAQ
Hoe toon ik een prijs in een WhatsApp-linkvoorbeeld?
Serveer een og:image die de prijs bevat — dat betekent een afbeelding die uit je catalogus is gegenereerd, niet een statische foto. WhatsApp toont de afbeelding waar de tag naar verwijst, op 1200×630; de prijs verschijnt alleen als die in die afbeelding is getekend.
Waarom toont het voorbeeld nog de oude prijs nadat ik de sale heb beëindigd?
Twee waarschijnlijke oorzaken: de afbeelding die de pagina serveert is niet veranderd (pagina-cache, of een statische afbeelding), of WhatsApp toont een gecacht voorbeeld van vóór de wijziging. Controleer eerst de huidige og:image-URL — als de prijs daar ook oud is, ligt het probleem bij de winkel; als die actueel is, bij WhatsApp.
Toont de kaart de sale-prijs of de reguliere prijs?
De sale-prijs — dat is wat WooCommerce als huidige prijs rapporteert — met de reguliere prijs ernaast als doorgestreepte prijs, en alleen wanneer het product daadwerkelijk in de sale is.
Tekenen alle plannen de prijs en de sale-badge?
Ja. Templatevelden zijn bij FastOG niet aan een tier gebonden: prijs, doorgestreepte prijs en voorraadbadges zijn beschikbaar in elk plan. Plannen verschillen in paginatypes, itemlimiet en templatebreedte, niet in wat een cover kan zeggen.
Wordt de prijs bijgewerkt voor links die al zijn gedeeld?
Voor Facebook vraagt FastOG na de productupdate om een nieuwe scrape. Voor WhatsApp, LinkedIn en X gebeurt de volgende uitlezing volgens het eigen schema van elk platform; voor die platforms wordt geen publieke timinggarantie of programmatische refresh-API geclaimd.
Wat als ik de prijs wijzig maar niet het template?
Dat is het normale geval en het werkt: het template bepaalt de layout, de catalogus levert de waarden. Er hoeft niets opnieuw ontworpen en geen afbeelding opnieuw geëxporteerd te worden.
Blijft een link die tijdens de sale is gedeeld de sale-prijs tonen nadat de sale is afgelopen?
Alleen zolang het gecachte voorbeeld van een platform blijft bestaan. De cover-URL verandert mee met de catalogus, dus de eerste verse uitlezing krijgt de kaart van na de sale.
Is er een gratis plan?
Ja. De gratis Community-tier dekt tot 100 items over product-, categorie-, shop- 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 aparte server, los van Community, verhogen de itemlimiet en ontgrendelen extra templates en mogelijkheden (rating-badges vanaf Starter, metafield-mapping vanaf Pro, scoped rules en priority rendering vanaf Scale). Betaalde plannen bevatten een proefperiode van 14 dagen zonder creditcard.
Gerelateerd
Probeer het gratis — geen aanmelding vereist
Bekijk en test dynamische OG-afbeeldingen in seconden.
Open de gratis OG-afbeeldingstester