WooCommerce-prissynkronisering i WhatsApp-forhåndsvisningen
En WooCommerce-prissynkronisering i WhatsApp-forhåndsvisningen betyder, at tallet på kortet hentes fra dit katalog i det øjeblik, kortet genereres — ikke er bagt ind i et billede, som nogen har lavet én gang. Når det er tilfældet, er det eneste tilbageværende spørgsmål hvornår WhatsApp genlæser linket, og det er netop den ene ting, som ingen butik kan styre.
Det korte svar
En pris kan kun optræde i en forhåndsvisning, hvis billedet er bygget ud fra live produktdata. Et statisk fremhævet billede har ingen pris at vise, nogensinde; et kort, der er designet én gang, har den pris, det havde den dag. WooCommerce udleverer ikke noget pris-tagget billede som standard, så klagen over "gammel pris i forhåndsvisningen" er egentlig to spørgsmål:
- Kender kortet den aktuelle pris? — en designbeslutning, og den kan du rette op på.
- Har platformen genlæst siden, siden prisen ændrede sig? — det er WhatsApps ur, ikke dit.
Hvorfor prisen bliver forældet
| Årsag | Det, du ser | Hvorfor det sker |
|---|---|---|
| Tagget peger på det fremhævede billede | Ingen pris overhovedet | Et produktbillede indeholder ingen pris |
| Kortet blev genereret én gang | Prisen fra designdagen | Intet genskaber det |
| Et udsalg er slut | En gennemstregning for en rabat, der er ophørt | Billedet bærer stadig det gamle badge |
| Sidecachen leverer gammel HTML | Det gamle kort, igen | Crawleren ser aldrig den nye og:image-URL |
Kun de første tre handler om kortet. Den fjerde handler om dit cachinglag, og den ser identisk ud udefra — hvilket er grunden til, at rækkefølgen af tjek i Instant WhatsApp Image Update for WooCommerce er vigtig.
Hvad et synkroniseret kort faktisk læser
FastOG signerer en cover-URL pr. forespørgsel, og props kommer fra det live produkt:
| Kort-element | Kilde | Bemærkning |
|---|---|---|
| Pris | get_price() |
På et produkt med rabat er dette salgsprisen |
| Sammenlign-pris ("før"-pris) | den normale pris | Sendes kun, når produktet faktisk er på tilbud — en "før"-pris, der er lig med den aktuelle pris, er en gennemstregning, ingen har fortjent |
| Tilbudsbadge | produktets tilbudsstatus | Vises og forsvinder sammen med tilbuddet |
| Lager | lagerstatus | Afspejler kataloget på renderingstidspunktet |
| Foto | fremhævet billede først, derefter galleri | Komponeres inde i kortet, beskæres ikke af platformen |
Det er forskellen mellem "dynamisk" og faktisk dynamisk: værdierne er ikke pladsholdere, som en designer har udfyldt, de læses fra din butik, hver gang et kort bygges.
Sådan fungerer "sync" i begge retninger
Katalog → kort. Hver værdi ovenfor læses ved render-tidspunktet. Ændr en pris, og næste render viser den nye; der er ingen eksporttrin og ingen fil, der skal uploades igen.
Kort → cache. Hver værdi rejser også inde i den signerede cover-URL. Så en prisændring ændrer URL'en — hvilket betyder, at det gamle billede ikke længere kan adresseres, at CDN'et ikke har noget forældet at servere, og at der ikke er behov for cache-busting. Intet andet i denne kategori fungerer på denne måde, fordi et selvhostet plugin baserer sit billede på et filnavn, der aldrig ændrer sig.
Kort → Facebook. Når et produkt gemmes, udløser det WooCommerce's native product.updated-webhook, og FastOG sætter en Meta-genindlæsning i kø for det pågældende produkts permalink, så Facebook erstatter det cachelagrede kort i stedet for at vente uger. Se Force a Facebook Open Graph Cache Refresh.
Kort → WhatsApp. Intet kan pushes. Det korrekte kort venter på næste læsning.
Edge-casen med planlagte udsalg
Et udsalg, der starter ved midnat, uden at nogen rører produktet, udløser slet ingen webhook — en detalje, der bryder ethvert "vi opdaterer ved gem"-design, inklusive vores Facebook-ping.
Det, der redder kortet, er, at det ikke genereres på forhånd: coveret bygges på anmodning ud fra aktuelle katalogdata, så den første hentning efter midnat viser allerede udsalgsprisen og badgen. Det forældede tal kan kun overleve i en platforms preview-cache, hvor det vil blive erstattet efter den pågældende platforms egen tidsplan. Et kort, der bliver rendered frem for eksporteret, er den eneste slags, der overlever et udsalg, som ingen gemte.
Kontroller, at prisen er synkroniseret
Prisen er synlig i selve cover-URL'en, hvilket gør det muligt at kontrollere uden en 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.
Hvis URL'ens parametre og det renderede kort begge viser den aktuelle pris, og produktsiden viser det samme, er butikssiden synkroniseret, og enhver resterende forældelse skyldes en platformscache. Hvis URL'en stadig indeholder den gamle pris, serverer sidecachen HTML fra før redigeringen — ryd den.
For at se det end-to-end kan du indsætte en produkt-URL i See Your Links The Way Buyers Do: den læser de live tags og renderer et cover ud fra de samme produktdata, side om side med det, platformene ville vise i dag.
FAQ
Hvordan viser jeg en pris i et WhatsApp-linkpreview?
Server en og:image, der indeholder prisen — hvilket betyder et billede genereret ud fra dit katalog, ikke et statisk foto. WhatsApp viser det billede, tagget peger på, i 1200×630; prisen fremgår kun, hvis den er tegnet ind i det billede.
Hvorfor viser previewet stadig den gamle pris, efter jeg har afsluttet udsalget?
To sandsynlige årsager: billedet, som siden serverer, er ikke ændret (sidecache eller et statisk billede), eller WhatsApp viser et cachet preview fra før ændringen. Tjek først den aktuelle og:image-URL — hvis dens pris også er gammel, er det butikken, der er problemet; hvis den er aktuel, er det WhatsApp.
Viser kortet udsalgsprisen eller den normale pris?
Udsalgsprisen — det er den, WooCommerce rapporterer som den aktuelle pris — med den normale pris ved siden af som compare-at, og kun når produktet reelt er på udsalg.
Tegner alle planer prisen og udsalgsbadgen?
Ja. Skabelonfelter er ikke låst til et niveau på FastOG: pris, compare-at-pris og lagerbadges er tilgængelige på alle planer. Planerne adskiller sig på sidetyper, antal tilladte elementer og skabelonbredde, ikke på hvad et cover kan sige.
Opdateres prisen for links, der allerede er delt?
For Facebook anmoder FastOG om en ny scraping efter produktopdateringen. For WhatsApp, LinkedIn og X sker den næste læsning efter hver platforms egen tidsplan; der gives ingen offentlig garanti for timing eller programmatisk refresh-API for disse platforme.
Hvad hvis jeg ændrer prisen, men ikke skabelonen?
Det er det normale tilfælde, og det virker: skabelonen definerer layoutet, kataloget leverer værdierne. Intet skal redesignes, og intet billede skal eksporteres igen.
Vil et link, der blev delt under udsalget, fortsat vise udsalgsprisen, efter det er slut?
Kun så længe en platforms cachede preview overlever. Cover-URL'en ændrer sig med kataloget, så den første friske læsning får kortet fra efter udsalget.
Findes der en gratis plan?
Ja. Det gratis Community-niveau dækker op til 100 elementer på tværs af produkt-, kategori-, shop- og blogindlægssider med fem basisskabeloner plus produktskabelonerne Black Friday og Seasonal Offer. Dets covers er rene — ingen plan har vandmærke, Community inkluderet. Community renderes på den delte Community-server og er begrænset af rate limits for butik/IP frem for af branding. Betalte planer bruger en dedikeret server adskilt fra Community, hæver antallet af tilladte elementer og låser op for yderligere skabeloner og funktioner (rating-badges fra Starter, metafield-mapping fra Pro, scoped rules og prioriteret rendering fra Scale). Betalte planer inkluderer en 14-dages prøveperiode uden krav om kreditkort.
Relateret
Prøv det gratis – ingen tilmelding nødvendig
Forhåndsvis og test dynamiske OG-billeder på få sekunder.
Åbn den gratis OG-billedtester