Omedelbar WhatsApp-bilduppdatering för WooCommerce
En omedelbar WhatsApp-bilduppdatering för WooCommerce innebär att det korrekta kortet är klart i samma stund som du sparar en produkt — inte att WhatsApp läser om länken på kommando. Ingen kan få WhatsApp att läsa om en länk: det cachar förhandsvisningar i mottagarens app och exponerar inget API för uppdatering. Det du kontrollerar är allt på butikssidan, och det räcker för att nästa person som delar länken ska se aktuell produkt, pris och bild.
Det korta svaret
Det finns två klockor i en WhatsApp-förhandsvisning, och bara en av dem är din.
| Klocka | Vem äger den | Kan den vara omedelbar? |
|---|---|---|
og:image som din sida serverar |
Du (butiken) | Ja — det är den här delen du ska åtgärda |
| WhatsApp läser sidan och cachar det den läste | WhatsApp, per mottagare | Nej — inget API, ingen debugger, ingen workaround |
Varje påstående om "omedelbar uppdatering" som ignorerar den andra raden är en lögn, och varje produkt som bara åtgärdar den första raden visar fortfarande rätt bild så snart WhatsApp tittar igen. Det är hela spelet: få butikssidan bevisbart korrekt och sluta sedan hoppas på att WhatsApp samarbetar.
Varför din uppdatering inte syns
Fyra separata cachar ligger mellan "jag ändrade priset" och "förhandsvisningen ändrades". Handlare skyller nästan alltid på fel cache.
| # | Cache | Nycklad på | Vad som faktiskt rensar den |
|---|---|---|---|
| 1 | Din butiks sidcache / CDN | sidans URL | rensa sidcachen |
| 2 | WhatsApps cache för länkförhandsvisning | länken folk delade | ingenting — den löper ut enligt WhatsApps schema |
| 3 | WhatsApps kopia av bildens bytes | bildens URL | en ny bild-URL |
| 4 | Ditt bild-CDN / rendercache | bildens URL | en ny bild-URL, eller rensa den |
Rad 1 är den folk missar. En cachad HTML-sida innehåller fortfarande den gamla og:image-URL:en, så även ett perfekt återuppbyggt kort upptäcks aldrig. Rensa sidcachen först och titta sedan på resten.
Rad 3 och 4 är anledningen till att lägga till en version i bildens URL är det enda pålitliga sättet att kringgå cachen — en ny bild-URL blir en cachemiss överallt på en gång.
WooCommerce-delen: din tagg bör aldrig vara inaktuell
I WooCommerce är taggproblemet vanligtvis en av två saker, och ingendera är WhatsApps fel:
- Det finns ingen
og:imagealls. WordPress och WooCommerce genererar ingen förproduct,product_cateller butikssidan. Ditt SEO-plugin tillhandahåller en — och för en produkt tar den den statiska utvalda bilden. - Taggen finns men pekar på en fast fil. En statisk bild-URL kan inte ändras när priset gör det. Varje delning efter redigeringen cachar om samma inaktuella bild.
FastOG tar den andra vägen. Omslagsbilden är en signerad URL vars query innehåller värdena som producerade den, lästa från den live-katalogen vid varje förfrågan: produktnamnet, det aktuella priset (get_price() — reapriset på en rabatterad produkt), jämförelsepriset "var", rea-badgen, betyg, lager och produktfotot.
Det har en konsekvens som är värd att säga rakt ut: en prisändring är en URL-ändring. Den gamla URL:en beskriver inte längre produkten, så CDN:en har inget inaktuellt att servera, och nästa hämtning renderar om. Ingen cache-busting-hack, ingen checklista för "har jag rensat den".
Vad som händer när du klickar på Spara på en produkt
För Facebook — den enda plattformen som låter vem som helst begära en uppdatering — sköter FastOG begäran åt dig:
- WooCommerce utlöser sin inbyggda webhook
product.updated/product.created(permalinkfinns i payloaden). - FastOG uppdaterar sin katalogpost för butiken, så nästa omslagsbild hämtas från aktuell data.
- Ett
RefreshMetaPreview-jobb köas för produktens sid-URL. Det köas i stället för att köras direkt — en fullständig katalogsynk får inte lägga till ett blockerande anrop till Meta per objekt — och det avdubblas, så att spara om samma produkt upprepade gånger inte förbrukar Metas hastighetsgräns. - Jobbet anropar Metas scrape-endpoint med en app access token, och Meta ersätter sin cachade kopia av förhandsvisningen för den sidan.
Detta är avsiktligt av typen "best effort". Om Meta är långsamt, vägrar eller begränsar hastigheten lyckas synken ändå: taggen på din sida är redan korrekt, och den enda kostnaden är att Meta uppdaterar enligt sitt eget schema i stället för omedelbart.
Det uppdaterar inte WhatsApp, LinkedIn eller X, eftersom ingen av dem erbjuder ett API för att uppdatera något. Det är inte en begränsning i FastOG — det är avsaknaden av en endpoint i andra änden.
Kontrollera i rätt ordning
När en förhandsvisning inte uppdateras, arbeta dig nedåt i den här listan i stället för att gissa:
# 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.
Om steg 1 fortfarande visar URL:en före redigeringen kan inget längre fram hjälpa — rensa sidcachen. Om steg 1 visar en ny URL och steg 2 returnerar 200 OK med en image/png är butikssidan korrekt och du tittar på cacherad 2, vilket är WhatsApps klocka.
Vill du se alla fyra raderna utifrån? Klistra in produktens URL i See Your Links The Way Buyers Do — den hämtar sidan på samma sätt som en crawler, läser de aktiva taggarna och renderar resultatet så som WhatsApp, X och Messenger visar det, bredvid ett FastOG-omslag byggt från samma produktdata. Ingen registrering.
Hjälper ett cache-busting-plugin eller ?v=2?
De hjälper på ett smalt sätt, och avvägningen är verklig.
En förhandsvisning cachas mot länken som folk delade. En URL som ingen någonsin har delat har ingen cachad förhandsvisning — vilket är anledningen till att det är ett så vanligt knep att lägga till en föränderlig query-sträng (?v=2). Det fungerar, och det kostar dig något: den delade länken är inte längre din kanoniska produkt-URL, sökmotorer ser en andra adress, och analysverktyg delar upp trafiken.
FastOG tillämpar samma mekanism en nivå ned, där den är gratis. Sidans URL förblir kanonisk; bara bildens URL ändras med innehållet. Så det gamla omslaget kan inte serveras igen, och länken du delar är fortfarande den produktsida du vill ska indexeras.
Det ingen kan åtgärda, och varför vi säger det
- WhatsApp cachar förhandsvisningen i mottagarens app. Det finns inget API, ingen debugger och inget verktyg — inte ens vårt — som kan nå in i den.
- LinkedIn och X tillhandahåller inte heller något dokumenterat API för programmatisk invalidering. Deras crawlers läser om enligt sina egna scheman; behandla inte en tredjeparts uppskattning av tidsförloppet som en garanti från plattformen.
- Facebook är undantaget, och den enda plattformen som FastOG pingar åt dig. Se Force a Facebook Open Graph Cache Refresh för hur det går till.
En leverantör som säger sig uppdatera WhatsApp beskriver Facebooks beteende och hoppas att du inte kontrollerar. Vi föredrar att ge dig den korrekta kartan.
Vanliga frågor
Kan jag tvinga WhatsApp att uppdatera en länkförhandsvisning omedelbart?
Nej. WhatsApp har ingen uppdateringsendpoint eller debugger, och den cachade förhandsvisningen ligger i mottagarens app. Du kan bara se till att rätt bild väntar på nästa läsning.
Hur länge behåller WhatsApp en länkförhandsvisning?
Det finns ingen publicerad siffra och inget sätt att fråga efter den — den är per mottagare, per enhet. Behandla den som "tills WhatsApp bestämmer något annat" och optimera butikssidan i stället.
Varför uppdaterades den för mig men inte för min kund?
Eftersom du testade genom att dela en länk som aldrig hade delats från din enhet, eller så skickade du den till en ny chatt. Din kund läser en cachad förhandsvisning. Deras förhandsvisning och din är oberoende av varandra.
Tvingar en ändrad produkt-URL fram en uppdatering?
En URL som ingen har delat har ingen cachad förhandsvisning, så ja — till priset av en andra adress för samma produkt. Att ändra bildens URL ger samma effekt utan att röra din permalänk, vilket är vad FastOG gör.
Behöver jag ett plugin, eller kan jag redigera mitt tema själv?
En statisk og:image i ditt tema är mycket bättre än ingenting, och den är gratis. Det den inte kan göra är att skilja sig per produkt utan att du för hand skapar en bild per produkt — eller följa en prisändring. Det är vid den punkten en dynamisk omslagsbild betalar sig själv.
Min sajt ligger inte på FastOG. Hjälper något av detta ändå?
Ja. De fyra cacherna, kontrollordningen och plattformsgränserna beskriver hur plattformarna beter sig, inte hur FastOG beter sig. Arbeta igenom listan med curl och debuggrarna.
Finns det en gratisplan?
Ja. Den kostnadsfria Community-nivån omfattar upp till 100 objekt över produkt-, kategori-, butiks- och blogginläggssidor med fem basmallar plus produktmallarna Black Friday och Seasonal Offer. Dess omslagsbilder är rena — ingen plan har vattenstämpel, Community inräknat. Community renderas på den delade Community-servern och begränsas av hastighetsgränser per butik/IP snarare än av varumärkning. Betalplaner använder en dedikerad server separat från Community, höjer objektgränsen och låser upp ytterligare mallar och funktioner (betygsmärken från Starter, metafield-mappning från Pro, avgränsade regler och prioriterad rendering från Scale). Betalplaner inkluderar även en 14-dagars provperiod utan krav på kreditkort.
Relaterat
- WhatsApp-förhandsgranskning visas inte? Åtgärda og:image
- Guide för cache för sociala förhandsgranskningar: Facebook, WhatsApp, LinkedIn, X, Slack och Discord
- Tvinga fram en uppdatering av Facebooks Open Graph-cache
- WooCommerce-prissynkronisering i WhatsApp-förhandsgranskningen
- Så cachar du OG-bilder
- OG-bildstorlek: 1200×630 förklarat
- WooCommerce-integration: FastOG för WooCommerce
Prova gratis – ingen registrering krävs
Förhandsgranska och testa dynamiska OG-bilder på några sekunder.
Öppna gratis OG-bildtestaren