WooCommerce-prissynkronisering i WhatsApp-forhåndsvisningen
En WooCommerce-prissynkronisering i WhatsApp-forhåndsvisningen betyr at tallet på kortet hentes fra katalogen din i det øyeblikket kortet genereres – ikke bakt inn i et bilde noen lagde én gang. Når det er tilfellet, er det eneste gjenstående spørsmålet når WhatsApp leser lenken på nytt, og det er nettopp det ingen butikk kan kontrollere.
Det korte svaret
En pris kan bare vises i en forhåndsvisning hvis bildet er bygget fra levende produktdata. Et statisk fremhevet bilde har ingen pris å vise, noensinne; et kort som er designet én gang, har den prisen det hadde den dagen. WooCommerce deler ikke ut noe prismerket bilde som standard, så klagen om «gammel pris i forhåndsvisningen» er egentlig to spørsmål:
- Vet kortet hva den gjeldende prisen er? — en designbeslutning, og den du kan fikse.
- Har plattformen lest siden på nytt siden prisen endret seg? — WhatsApps klokke, ikke din.
Hvorfor prisen blir utdatert
| Årsak | Det du ser | Hvorfor det skjer |
|---|---|---|
| Taggen peker på fremhevet bilde | Ingen pris i det hele tatt | Et produktbilde inneholder ingen pris |
| Kortet ble laget én gang | Prisen fra design-dagen | Ingenting genererer det på nytt |
| Et salg tok slutt | En gjennomstreking for en rabatt som er over | Bildet bærer fortsatt den gamle etiketten |
| Sidebufferen serverer gammel HTML | Det gamle kortet, igjen | Crawleren ser aldri den nye og:image-URL-en |
Bare de tre første handler om kortet. Den fjerde handler om bufringslaget ditt, og det ser identisk ut fra utsiden — derfor er rekkefølgen på sjekkene i Instant WhatsApp Image Update for WooCommerce viktig.
Hva et synkronisert kort faktisk leser
FastOG signerer en cover-URL per forespørsel, og propsene kommer fra det levende produktet:
| Kortelement | Kilde | Merknad |
|---|---|---|
| Pris | get_price() |
På et produkt med rabatt er dette salgsprisen |
| Sammenlign-pris («var») | ordinær pris | Sendes bare når produktet faktisk er på salg — en «var»-pris lik gjeldende pris er en gjennomstreking ingen har fortjent |
| Salgsmerke | produktets salgsstatus | Vises og forsvinner sammen med salget |
| Lager | lagerstatus | Gjenspeiler katalogen ved rendering |
| Bilde | fremhevet bilde først, deretter galleri | Komponeres inne i kortet, beskjæres ikke av plattformen |
Det er forskjellen mellom «dynamisk» og faktisk dynamisk: verdiene er ikke plassholdere en designer har fylt inn, de leses fra butikken din hver gang et kort bygges.
Hvordan «sync» fungerer i begge retninger
Katalog → kort. Hver verdi ovenfor leses ved rendring. Endre en pris, og neste rendring viser den nye; det finnes ikke noe eksportsteg og ingen fil å laste opp på nytt.
Kort → cache. Hver verdi reiser også inne i den signerte cover-URL-en. En prisendring endrer altså URL-en — som betyr at det gamle bildet ikke lenger er adresserbart, CDN-et har ingenting utdatert å servere, og ingen cache-busting er nødvendig. Ingenting annet i denne kategorien fungerer slik, fordi en selvhostet plugin nøkler bildet sitt på et filnavn som aldri endres.
Kort → Facebook. Lagring av et produkt utløser WooCommerces innebygde product.updated-webhook, og FastOG setter en Meta re-scrape i kø for produktets permalink, slik at Facebook erstatter det bufrede kortet i stedet for å vente i ukevis. Se Force a Facebook Open Graph Cache Refresh.
Kort → WhatsApp. Ingenting kan pushes. Det riktige kortet venter på neste lesing.
Kanttilfellet med planlagt salg
Et salg som starter ved midnatt uten at noen rører produktet, utløser ingen webhook i det hele tatt – en detalj som bryter enhver «vi oppdaterer ved lagring»-design, inkludert vår Facebook-ping.
Det som redder kortet, er at det ikke genereres på forhånd: bildet bygges på forespørsel fra gjeldende katalogdata, så den første hentingen etter midnatt viser allerede salgsprisen og merket. Det utdaterte tallet kan bare overleve i en plattforms forhåndsvisningscache, der det vil bli erstattet etter den plattformens egen tidsplan. Et kort som rendres i stedet for eksporteres, er den eneste typen som overlever et salg ingen lagret.
Kontroller at tallet er synkronisert
Prisen er synlig i selve cover-URL-en, noe som gjør den kontrollerbar uten 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 parameterne i URL-en og det rendrede kortet begge viser gjeldende pris, og produktsiden viser det samme, er butikksiden synkronisert, og eventuell gjenstående utdatert data er en plattformcache. Hvis URL-en fortsatt har den gamle prisen, serverer sidecachen HTML fra før redigeringen – tøm den.
For å se det ende-til-ende kan du lime inn en produkt-URL i See Your Links The Way Buyers Do: den leser de live taggene og rendrer et cover fra de samme produktdataene, side om side med det plattformene ville vist i dag.
FAQ
Hvordan viser jeg en pris i en WhatsApp-forhåndsvisning av en lenke?
Server en og:image som inneholder prisen — altså et bilde generert fra katalogen din, ikke et statisk foto. WhatsApp viser bildet taggen peker på, i 1200×630; prisen vises bare hvis den er tegnet inn i bildet.
Hvorfor viser forhåndsvisningen fortsatt den gamle prisen etter at jeg avsluttet salget?
To sannsynlige årsaker: bildet siden serverer er ikke endret (sidecache, eller et statisk bilde), eller WhatsApp viser en bufret forhåndsvisning fra før endringen. Sjekk gjeldende og:image-URL først — hvis prisen der også er gammel, er det butikken som er problemet; hvis den er oppdatert, er det WhatsApp.
Viser kortet salgsprisen eller ordinær pris?
Salgsprisen — det er den WooCommerce rapporterer som gjeldende pris — med ordinær pris ved siden av som før-pris, og bare når produktet faktisk er på salg.
Tegner alle abonnementer prisen og salgsmerket?
Ja. Mal-felter er ikke låst til et nivå på FastOG: pris, før-pris og lagerstatus-merker er tilgjengelige på alle abonnementer. Abonnementene skiller seg på sidetyper, antall elementer og malbredde, ikke på hva et forsidebilde kan si.
Oppdateres prisen for lenker som allerede er delt?
For Facebook ber FastOG om en ny skraping etter produktoppdateringen. For WhatsApp, LinkedIn og X skjer neste lesing etter hver plattforms egen tidsplan; det gis ingen offentlig garanti for tidspunkt eller programmatisk oppdaterings-API for disse plattformene.
Hva om jeg endrer prisen, men ikke malen?
Det er det normale tilfellet, og det fungerer: malen definerer oppsettet, katalogen leverer verdiene. Ingenting må designes på nytt, og ingen bilder må eksporteres på nytt.
Vil en lenke som ble delt under salget, fortsatt vise salgsprisen etter at det er over?
Bare så lenge en plattforms bufrede forhåndsvisning overlever. Forsidebilde-URL-en endres med katalogen, så den første ferske lesingen får kortet for etter-salget.
Finnes det et gratis abonnement?
Ja. Det gratis Community-nivået dekker opptil 100 elementer på tvers av produkt-, kategori-, butikk- og blogginnlegg-sider med fem grunnmaler pluss produktmalene Black Friday og Seasonal Offer. Forsidebildene er rene — ingen abonnementer har vannmerke, Community inkludert. Community rendres på den delte Community-serveren og begrenses av hastighetsgrenser per butikk/IP snarere enn av merking. Betalte abonnementer bruker en dedikert server atskilt fra Community, øker antallet elementer og låser opp flere maler og funksjoner (vurderingsmerker fra Starter, metafield-mapping fra Pro, avgrensede regler og prioritert rendering fra Scale). Betalte abonnementer inkluderer en 14-dagers prøveperiode uten krav om kredittkort.
Relatert
Prøv gratis – ingen registrering nødvendig
Forhåndsvis og test dynamiske OG-bilder på sekunder.
Åpne den gratis OG-bildetesteren