Docs

Getting Started

Core

Tutorials & Guides

Øjeblikkelig WhatsApp-billedopdatering til WooCommerce

En øjeblikkelig WhatsApp-billedopdatering til WooCommerce betyder, at det korrekte kort er klar i det øjeblik, du gemmer et produkt — ikke at WhatsApp genlæser linket på kommando. Ingen kan få WhatsApp til at genlæse et link: det cacher forhåndsvisninger i modtagerens app og stiller ingen opdaterings-API til rådighed. Det, du styrer, er alt på butikkens side, og det er nok til at sikre, at den næste person, der deler linket, ser det aktuelle produkt, den aktuelle pris og det aktuelle billede.

Det korte svar

Der er to ure i en WhatsApp-forhåndsvisning, og kun det ene er dit.

Ur	Hvem ejer det	Kan det være øjeblikkeligt?
Den `og:image`, som din side serverer	Dig (butikken)	Ja — det er den del, du skal rette
WhatsApp læser siden og cacher det, den læste	WhatsApp, pr. modtager	Nej — ingen API, ingen debugger, ingen workaround

Enhver påstand om "øjeblikkelig opdatering", der ignorerer den anden række, er en løgn, og ethvert produkt, der kun retter den første række, viser stadig det rigtige billede, så snart WhatsApp kigger igen. Det er hele spillet: få butikssiden beviseligt korrekt, og hold så op med at håbe på, at WhatsApp spiller med.

Hvorfor din opdatering ikke vises

Der ligger fire separate caches mellem "jeg ændrede prisen" og "previewet ændrede sig". Forhandlere giver næsten altid skylden på den forkerte.

#	Cache	Nøglet på	Hvad der faktisk rydder den
1	Din butiks sidecache / CDN	side-URL'en	tømning af sidecachen
2	WhatsApps cache til link-preview	det link, folk delte	intet — den udløber efter WhatsApps tidsplan
3	WhatsApps kopi af billedets bytes	billede-URL'en	en ny billede-URL
4	Dit billede-CDN / render-cache	billede-URL'en	en ny billede-URL, eller tømning af den

Række 1 er den, folk overser. En cachet HTML-side indeholder stadig den gamle og:image-URL, så selv et perfekt genopbygget kort bliver aldrig opdaget. Tøm sidecachen først, og kig derefter på resten.

Række 3 og 4 er grunden til, at det kun er pålideligt at cache-buste ved at tilføje en version til billede-URL'en — en ny billede-URL er et cache-miss overalt på én gang.

WooCommerce-delen: dit tag bør aldrig være forældet

På WooCommerce er tag-problemet som regel en af to ting, og ingen af dem er WhatsApps skyld:

Der findes slet ikke noget og:image. WordPress og WooCommerce udsender ingen for product, product_cat eller shopsiden. Dit SEO-plugin leverer et — og for et produkt griber det efter det statiske fremhævede billede.
Tagget findes, men peger på en fast fil. En statisk billed-URL kan ikke ændre sig, når prisen gør. Hver deling efter redigeringen gen-cacher det samme forældede billede.

FastOG tager den anden vej. Forsidebilledet er en signeret URL, hvis query indeholder de værdier, der frembragte det, læst fra det live katalog ved hver request: produktnavnet, den aktuelle pris (get_price() — tilbudsprisen på et nedsat produkt), compare-at-"før"-prisen, udsalgsbadget, bedømmelse, lagerstatus og produktfotoet.

Det har en konsekvens, der er værd at sige direkte: en prisændring er en URL-ændring. Den gamle URL beskriver ikke længere produktet, så CDN'et har intet forældet at servere, og den næste fetch re-rendrer. Intet cache-busting-hack, ingen "fik jeg nu purget det"-tjekliste.

Hvad der sker, når du trykker på Gem på et produkt

For Facebook — den ene platform, der lader enhver spørge — gør FastOG det at spørge for dig:

WooCommerce udløser sin native product.updated / product.created-webhook (permalink er i payloaden).
FastOG opdaterer sin katalogpost for butikken, så det næste cover tegnes ud fra aktuelle data.
Et RefreshMetaPreview-job sættes i kø for den pågældende produktsides URL. Det sættes i kø frem for at køre inline — en fuld katalogsynkronisering må ikke tilføje ét blokerende kald til Meta pr. element — og det de-duplikeres, så gentagen gemning af det samme produkt ikke bruger Metas rate limit.
Jobbet kalder Metas scrape-endpoint med et app access token, og Meta erstatter sin cachelagrede kopi af forhåndsvisningen for den pågældende side.

Dette er best-effort af design. Hvis Meta er langsom, afviser eller rate-limiter, lykkes synkroniseringen stadig: tagget på din side er allerede korrekt, og den eneste omkostning er, at Meta opdaterer efter sin egen tidsplan i stedet for med det samme.

Det opdaterer ikke WhatsApp, LinkedIn eller X, fordi ingen af dem tilbyder en API til at opdatere noget. Det er ikke en begrænsning i FastOG — det er fraværet af et endpoint i den anden ende.

Tjek det i den rigtige rækkefølge

Når en forhåndsvisning ikke opdateres, så gå ned ad denne liste i stedet for at gætte:

bash

# 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.

Hvis trin 1 stadig viser URL'en fra før redigeringen, kan intet længere nede hjælpe — ryd sidecachen. Hvis trin 1 viser en ny URL, og trin 2 returnerer 200 OK med en image/png, er butikssiden korrekt, og du kigger på cache-række 2, som er WhatsApps ur.

Vil du se alle fire rækker udefra? Indsæt produktets URL i Se dine links, som køberne ser dem — den henter siden, som en crawler gør, læser de aktive tags og gengiver resultatet, som WhatsApp, X og Messenger viser det, ved siden af et FastOG-forsidebillede bygget ud fra de samme produktdata. Ingen tilmelding.

Hjælper et cache-busting-plugin eller `?v=2`?

De hjælper på én snæver måde, og afvejningen er reel.

En forhåndsvisning caches op mod det link, folk delte. En URL, som ingen nogensinde har delt, har ingen cachet forhåndsvisning — hvilket er grunden til, at det er så almindeligt et trick at tilføje en skiftende query string (?v=2). Det virker, og det koster dig: det delte link er ikke længere din kanoniske produkt-URL, søgemaskiner ser en ekstra adresse, og analyser splitter trafikken.

FastOG anvender den samme mekanisme et niveau længere nede, hvor den er gratis. Sidens URL forbliver kanonisk; kun billedets URL ændres med indholdet. Så det gamle cover kan ikke blive serveret igen, og det link, du deler, er stadig den produktside, du vil have indekseret.

Det, ingen kan rette, og hvorfor vi siger det

WhatsApp cacher forhåndsvisningen i modtagerens app. Der findes ingen API, ingen debugger og intet værktøj — heller ikke vores — der kan nå ind i den.
LinkedIn og X stiller heller ikke nogen dokumenteret API til programmatisk invalidering til rådighed. Deres crawlere læser igen efter deres egne tidsplaner; betragt ikke et tidsestimat fra tredjepart som en garanti fra platformen.
Facebook er undtagelsen og den eneste platform, FastOG pinger for dig. Se Gennemtving en opdatering af Facebook Open Graph-cachen for at se, hvordan det foregår.

En leverandør, der fortæller dig, at den opdaterer WhatsApp, beskriver Facebooks adfærd og håber, at du ikke tjekker efter. Vi vil hellere give dig det korrekte kort.

FAQ

Kan jeg tvinge WhatsApp til at opdatere en linkpreview med det samme?

Nej. WhatsApp har ingen refresh-endpoint eller debugger, og den cachelagrede preview ligger i modtagerens app. Du kan kun sikre dig, at det korrekte billede venter på næste læsning.

Hvor længe beholder WhatsApp en linkpreview?

Der findes ingen offentliggjort grænse, og der er ingen måde at slå det op — det er per modtager, per enhed. Behandl det som "indtil WhatsApp beslutter noget andet", og optimér i stedet butikssiden.

Hvorfor blev den opdateret for mig, men ikke for min kunde?

Fordi du testede ved at dele et link, der aldrig var blevet delt fra din enhed, eller du sendte det til en helt ny chat. Din kunde læser en cachelagret preview. Deres preview og din er uafhængige.

Tvinger et skift af produkt-URL'en en opdatering?

En URL, som ingen har delt, har ingen cachelagret preview, så ja — på bekostning af en ekstra adresse til det samme produkt. Hvis du ændrer billedets URL, får du samme effekt uden at røre din permalink, hvilket er det, FastOG gør.

Har jeg brug for et plugin, eller kan jeg selv redigere mit tema?

En statisk og:image i dit tema er meget bedre end ingenting, og den er gratis. Det, den ikke kan, er at variere per produkt uden at håndskrive et billede per produkt — eller følge en prisændring. Det er på det punkt, en dynamisk cover betaler sig selv.

Mit site er ikke på FastOG. Hjælper noget af dette stadig?

Ja. De fire caches, tjekrækkefølgen og platformgrænserne er, hvordan platformene opfører sig, ikke hvordan FastOG opfører sig. Gå listen igennem med curl og debuggerne.

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 produkt-skabelonerne 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 snarere end af branding. Betalte planer bruger en dedikeret server adskilt fra Community, hæver elementgrænsen 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 også en 14-dages prøveperiode uden krav om kreditkort.

Prøv det gratis – ingen tilmelding nødvendig

Forhåndsvis og test dynamiske OG-billeder på få sekunder.

Åbn den gratis OG-billedtester

Emne