Actualizare instantanee a imaginii WhatsApp pentru WooCommerce

O actualizare instantanee a imaginii WhatsApp pentru WooCommerce înseamnă că cardul corect este gata în momentul în care salvezi un produs — nu că WhatsApp recitește linkul la comandă. Nimeni nu poate obliga WhatsApp să recitească un link: acesta memorează în cache previzualizările în aplicația destinatarului și nu expune niciun API de reîmprospătare. Ceea ce controlezi este tot ce ține de partea magazinului, iar asta este suficient pentru ca următoarea persoană care distribuie linkul să vadă produsul, prețul și fotografia actuale.

Răspunsul scurt

Într-un preview WhatsApp există două ceasuri, și doar unul dintre ele este al tău.

Ceas Cine îl controlează Poate fi instant?
og:image pe care îl servește pagina ta Tu (magazinul) Da — aceasta este partea de reparat
WhatsApp care citește pagina și memorează în cache ce a citit WhatsApp, per destinatar Nu — niciun API, niciun debugger, nicio soluție ocolitoare

Orice afirmație despre „actualizare instant” care ignoră al doilea rând este o minciună, iar orice produs care repară doar primul rând afișează totuși imaginea corectă de îndată ce WhatsApp se uită din nou. Acesta este tot jocul: fă partea magazinului demonstrabil corectă, apoi nu mai spera că WhatsApp va coopera.

De ce nu apare actualizarea ta

Între „am schimbat prețul” și „s-a schimbat previzualizarea” se află patru cache-uri separate. Comercianții dau aproape întotdeauna vina pe cel greșit.

# Cache Legat de Ce îl golește de fapt
1 Cache-ul de pagini al magazinului tău / CDN URL-ul paginii golirea cache-ului de pagini
2 Cache-ul de previzualizare a linkurilor din WhatsApp linkul pe care l-au distribuit oamenii nimic — expiră conform programului WhatsApp
3 Copia WhatsApp a octeților imaginii URL-ul imaginii un URL nou de imagine
4 CDN-ul tău de imagini / cache-ul de randare URL-ul imaginii un URL nou de imagine sau golirea lui

Rândul 1 este cel pe care oamenii îl ratează. O pagină HTML din cache conține încă URL-ul og:image vechi, așa că nici un card reconstruit perfect nu va fi descoperit vreodată. Golește mai întâi cache-ul de pagini, apoi uită-te la restul.

Rândurile 3 și 4 sunt motivul pentru care adăugarea unei versiuni la URL-ul imaginii este singurul cache-buster de încredere — un URL nou de imagine este un cache miss peste tot simultan.

Partea WooCommerce: eticheta ta nu ar trebui să fie niciodată învechită

Pe WooCommerce problema etichetei este de obicei una dintre două lucruri, și niciuna nu este vina WhatsApp:

  • Nu există deloc og:image. WordPress și WooCommerce nu emit niciunul pentru product, product_cat sau pagina magazinului. Pluginul tău SEO furnizează unul — iar pentru un produs acesta recurge la imaginea statică evidențiată.
  • Eticheta există, dar indică un fișier fix. Un URL de imagine statică nu se poate schimba când se schimbă prețul. Fiecare distribuire după editare re-cache-uiește aceeași imagine învechită.

FastOG alege cealaltă cale. Coperta este un URL semnat a cărui interogare conține valorile care au produs-o, citite din catalogul live la fiecare cerere: numele produsului, prețul curent (get_price() — prețul de reducere la un produs cu discount), prețul de comparație „was", insigna de reducere, ratingul, stocul și fotografia produsului.

Asta are o consecință care merită spusă direct: o schimbare de preț este o schimbare de URL. Vechiul URL nu mai descrie produsul, așa că CDN-ul nu are nimic învechit de servit, iar următoarea preluare re-randează. Fără trucuri de cache-busting, fără lista de verificare „am purjat-o?".

Ce se întâmplă când apeși Save pe un produs

Pentru Facebook — singura platformă care permite oricui să întrebe — FastOG întreabă în locul tău:

  1. WooCommerce declanșează webhook-ul său nativ product.updated / product.created (permalink se află în payload).
  2. FastOG își reîmprospătează înregistrarea din catalog pentru magazin, astfel încât următoarea copertă este generată din datele curente.
  3. Un job RefreshMetaPreview este pus în coadă pentru URL-ul paginii acelui produs. Este pus în coadă, nu executat inline — o sincronizare a întregului catalog nu trebuie să adauge un apel blocant către Meta pentru fiecare element — și este deduplicat, astfel încât salvarea repetată a aceluiași produs nu consumă limita de rată a Meta.
  4. Job-ul apelează endpoint-ul de scrape al Meta cu un app access token, iar Meta înlocuiește copia sa din cache a previzualizării pentru acea pagină.

Acest lucru este best-effort prin design. Dacă Meta este lent, refuză sau limitează rata, sincronizarea reușește totuși: tag-ul de pe pagina ta este deja corect, iar singurul cost este că Meta reîmprospătează conform propriului program, în loc să o facă imediat.

Nu reîmprospătează WhatsApp, LinkedIn sau X, pentru că niciuna dintre ele nu oferă un API pentru a reîmprospăta ceva. Aceasta nu este o limitare a FastOG — este absența unui endpoint la celălalt capăt.

Verifică în ordinea corectă

Când o previzualizare nu se actualizează, parcurge această listă în loc să ghicești:

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.

Dacă pasul 1 arată încă URL-ul de dinainte de editare, nimic din aval nu poate ajuta — golește cache-ul paginii. Dacă pasul 1 arată un URL nou, iar pasul 2 returnează 200 OK cu un image/png, partea de store este corectă și te uiți la rândul 2 de cache, care este ceasul WhatsApp.

Vrei să vezi toate cele patru rânduri din exterior? Lipește URL-ul produsului în Vezi-ți linkurile așa cum le văd cumpărătorii — preia pagina așa cum o face un crawler, citește tag-urile live și afișează rezultatul așa cum îl arată WhatsApp, X și Messenger, alături de o copertă FastOG construită din aceleași date de produs. Fără înregistrare.

Ajută un plugin de cache-busting sau ?v=2?

Ajută într-un singur mod îngust, iar compromisul este real.

Un preview este cache-uit în funcție de linkul pe care oamenii l-au distribuit. Un URL pe care nimeni nu l-a distribuit vreodată nu are niciun preview cache-uit — de aceea adăugarea unui query string care se schimbă (?v=2) este un truc atât de comun. Funcționează, dar te costă: linkul distribuit nu mai este URL-ul canonic al produsului tău, motoarele de căutare văd o a doua adresă, iar analytics împarte traficul.

FastOG aplică același mecanism cu un nivel mai jos, unde este gratuit. URL-ul paginii rămâne canonic; doar URL-ul imaginii se schimbă odată cu conținutul. Astfel, coperta veche nu mai poate fi servită din nou, iar linkul pe care îl distribui este în continuare pagina de produs pe care vrei să o indexezi.

Ce nu poate rezolva nimeni și de ce spunem asta

  • WhatsApp memorează în cache previzualizarea în aplicația destinatarului. Nu există niciun API, niciun debugger și niciun instrument — inclusiv al nostru — care să poată ajunge acolo.
  • LinkedIn și X nu expun nici ele un API documentat de invalidare programatică. Crawlerele lor recitesc după propriile programări; nu trata o estimare de timp a unei terțe părți ca pe o garanție a platformei.
  • Facebook este excepția și singura platformă pe care FastOG o notifică pentru tine. Vezi Force a Facebook Open Graph Cache Refresh pentru mecanism.

Un furnizor care îți spune că reîmprospătează WhatsApp descrie comportamentul Facebook și speră că nu verifici. Noi preferăm să îți dăm harta corectă.

Întrebări frecvente

Nu. WhatsApp nu expune niciun endpoint de reîmprospătare sau debugger, iar previzualizarea din cache se află în aplicația destinatarului. Poți doar să te asiguri că imaginea corectă așteaptă următoarea citire.

Nu există o cifră publicată și nicio modalitate de a o interoga — este per destinatar, per dispozitiv. Trateaz-o ca „până când WhatsApp decide altfel" și optimizează în schimb partea de store.

De ce s-a actualizat pentru mine, dar nu pentru clientul meu?

Pentru că ai testat partajând un link care nu fusese niciodată partajat de pe dispozitivul tău sau l-ai trimis într-un chat nou. Clientul tău citește o previzualizare din cache. Previzualizarea lui și a ta sunt independente.

Schimbarea URL-ului produsului forțează o actualizare?

Un URL pe care nimeni nu l-a partajat nu are previzualizare în cache, deci da — cu prețul unei a doua adrese pentru același produs. Schimbarea URL-ului imaginii produce același efect fără să atingi permalink-ul, ceea ce face FastOG.

Am nevoie de un plugin sau pot edita singur tema?

Un og:image static în tema ta este mult mai bun decât nimic și este gratuit. Ce nu poate face este să difere per produs fără a crea manual o imagine pentru fiecare produs — sau să urmărească o schimbare de preț. Acesta este punctul în care o copertă dinamică se amortizează singură.

Site-ul meu nu este pe FastOG. Mai ajută ceva de aici?

Da. Cele patru cache-uri, ordinea verificărilor și limitele platformelor descriu cum se comportă platformele, nu cum se comportă FastOG. Parcurge lista cu curl și cu debuggerele.

Există un plan gratuit?

Da. Nivelul gratuit Community acoperă până la 100 de elemente pentru paginile de produs, categorie, magazin și articole de blog, cu cinci șabloane de bază plus șabloanele de produs Black Friday și Seasonal Offer. Copertele sale sunt curate — niciun plan nu poartă watermark, inclusiv Community. Community rulează pe serverul partajat Community și este limitat de rate limits per store/IP, nu de branding. Planurile plătite folosesc un server dedicat separat de Community, cresc limita de elemente și deblochează șabloane și capabilități suplimentare (badge-uri de rating de la Starter, mapare de metafields de la Pro, reguli cu scop și randare prioritară de la Scale). Planurile plătite includ și un trial de 14 zile fără cerință de card de credit.

Încearcă gratuit — nu este necesară înregistrarea

Previzualizează și testează imagini OG dinamice în câteva secunde.

Deschide Testerul gratuit de imagini OG

From Us

A BeCaSimulations site