Tvinga en cacheuppdatering för Facebook Open Graph

Du kan tvinga en cacheuppdatering för Facebook Open Graph, eftersom Facebook – ensamt bland de stora plattformarna – exponerar ett programmerbart sätt att begära det. Antingen använder du Sharing Debugger-knappen Scrape Again för en enskild länk, eller så anropar du Graph API:ns scrape-endpoint med en app-åtkomsttoken (app access token). Det finns inget sätt att tvinga WhatsApp, LinkedIn eller X: de publicerar ingen sådan API, för någon.

Det som alla snubblar på

Meta cachar en länkförhandsvisning nycklad på sidans URL och lagrar en egen kopia av bilden. Meta läser inte om din sida för att upptäcka att og:image nu pekar någon annanstans.

Så detta arbetsflöde misslyckas, och det är det som de flesta försöker med:

Ändra omslagsbilden → og:image-URL:en är ny → anta att Facebook kommer att hämta den → det gör den inte.

En ny bild-URL bryter bild-CD:n. Den gör ingenting åt Metas cache som är nycklad på sidan. För att få Facebook att röra på sig måste du tala om för Meta att sidan har ändrats.

Cache	Nycklad på	Rensas av
Din sidcache / CDN	sidans URL	rensning av den
Metas länkförhandsvisningscache	sidans URL	scrape-endpointen eller Sharing Debugger
Metas kopia av bilden	bild-URL:en	en ny bild-URL
Din bild-CD	bild-URL:en	en ny bild-URL

Öppna developers.facebook.com/tools/debug, klistra in sidans URL och tryck på Scrape Again. Meta hämtar sidan på nytt och bygger om sin cachade förhandsvisning.

Det är också den bästa kostnadsfria valideraren du har, eftersom den rapporterar vad Meta faktiskt hittade snarare än vad du hoppades skulle finnas där: saknade eller duplicerade og:image, onåbara bilder, format som inte stöds. Två saker den inte gör: den kan inte röra WhatsApp (separat cache, i mottagarens app), och den är inte ett katalogverktyg — den hanterar en URL i taget, med hastighetsbegränsning, med en människa framför sig.

Alternativ 2 — Graph API (detta är vad en plugin anropar)

Den programmatiska motsvarigheten som FastOG använder är en POST till Graph API med scrape=true:

bash

curl -X POST \
  "https://graph.facebook.com/v21.0/?id=$(python3 -c 'import urllib.parse,sys;print(urllib.parse.quote(sys.argv[1],safe=""))' 'https://your-store.com/product/example')&scrape=true&access_token=${APP_ID}|${APP_SECRET}"

Fyra detaljer som spelar roll:

id är sidans URL, inte bildens URL. Meta nycklar sin cache på sidan, så att pinga bildadressen uppdaterar ingenting.
En token krävs — Meta har krävt en sådan på denna endpoint sedan oktober 2017. En app access token i formen {app_id}|{app_secret} räcker, och den behöver ingen användarinloggning, vilket är precis det som gör anropet möjligt från ett bakgrundsjobb.
Graph API-versioner rör sig. FastOG låser fast en testad Graph API-version; kontrollera Metas aktuella dokumentation och changelog innan du låser fast en version i din egen kod.
Behandla det som best-effort. Meta rate-limitar scrape-anrop, och ett avslag innebär bara att Facebook uppdaterar enligt sin egen tidtabell istället för omedelbart — taggarna på din sida är redan korrekta.

Eftersom det är rate-limitat, ska du inte avfyra det inline vid varje sparning av en stor katalog. Köa det, och avduplicera per URL så att upprepade sparningar av samma oförändrade produkt inte förbrukar rate limit.

Alternativ 3 — ett plugin som gör det åt dig

Plugins som marknadsförs som en "Open Graph cache refresh" delas in i två grupper, och bara en av dem kan åtgärda Facebook:

Mekanism	Vad den rensar	Åtgärdar en inaktuell Facebook-förhandsvisning?
Lägger till en föränderlig query-sträng till bild-URL:en (`?v=timestamp`)	din bild-CDN	Nej — Metas cache är nycklad på sidan
Anropar scrape-endpointen för sidans URL	Metas förhandsvisningscache	Ja

Innan du installerar ett, ta reda på vilket det är. En tidsstämpelparameter är en riktig fix för en inaktuell bild och en icke-fix för ett inaktuellt Facebook-kort.

FastOG för WooCommerce gör det andra, och du konfigurerar ingenting. Pluginet registrerar WooCommerce:s inbyggda produkt-webhooks, så när du sparar en produkt skickas en Meta-omskrapning för produktens permalänk — köad, de-duplicerad inom ett kort fönster, och best-effort av design så att ett avslag aldrig misslyckas med sparningen. Det gäller produktsidor (product.created / product.updated); kategori- och bloggredigeringar omfattas inte.

Bildsidan hanteras separat, och annorlunda än alla konkurrenter: eftersom en FastOG-omslags-URL innehåller de värden som producerade den, skapar en redigering av priset eller fotot en ny omslags-URL. Meta kan inte servera om en bild vars adress inte längre finns.

Där Facebook inte räcker till

Plattform	Kan du tvinga en uppdatering?	Vad som faktiskt händer
Facebook	Ja — debugger eller `scrape=true`	Begär en ny skrapning; spridningstiden varierar
WhatsApp	Nej	Förhandsvisningen cachas i mottagarens app; det finns inget API
LinkedIn	Inget dokumenterat programmatiskt API	Läser om enligt eget schema; ingen offentlig tidsgaranti ges här
X / Twitter	Inget dokumenterat programmatiskt API	Läser om enligt eget schema; ingen offentlig tidsgaranti ges här
Slack, Discord	Nej	Kortlivade cacher som rensas av sig själva inom minuter till timmar

Om en förhandsvisning är inaktuell på WhatsApp är svaret inte ett Facebook-verktyg — det är att få butikssidan rätt så att nästa läsning blir korrekt.

När det fortfarande visas den gamla bilden efter en lyckad hämtning

Gå igenom den här listan, i ordning:

Serverar sidan fortfarande den gamla taggen? curl -s https://your-store.com/product/example | grep -i 'og:image' — en cachad HTML-sida med en föråldrad og:image omintetgör hela hämtningen. Rensa sidcachen.
Skriver sidan ut mer än en og:image? Om två plugins var och en genererar en, tar crawleren den första den läser. Räkna dem.
Är bilden nåbar och inte blockerad? curl -I <image-url> bör returnera 200 med en bild-Content-Type. Sociala crawlerar respekterar robots.txt, så en bild på en Disallow:-sökväg misslyckas på ett sätt som liknar en korrupt fil — och curl kommer aldrig att återskapa det, eftersom curl ignorerar robots.txt.
Ändrades bild-URL:en faktiskt? Om den inte gjorde det, ändrades inte heller innehållet — kontrollera att pris-/fotoredigeringen nådde källan som kortet hämtas från.
Kontrollera felsökaren igen. Om den nu rapporterar den nya bilden och Facebook fortfarande visar det gamla kortet, tittar du på Facebooks egen spridning, inte på dina taggar.

FAQ

Finns det ett officiellt API för att rensa Facebooks Open Graph-cache?

FastOG använder scrape-endpointen (POST https://graph.facebook.com/{version}/?id={page-url}&scrape=true&access_token={token}). Meta dokumenterar Sharing Debugger och det programmatiska crawl-flödet; den exakta endpoint-formen och Graph API-versionen kan ändras, så verifiera dem mot Metas aktuella dokumentation innan du implementerar det själv.

Nej. Det är ett publikt verktyg och det fungerar för alla publika URL:er. Det det inte kan göra är att köras enligt ett schema eller täcka en hel katalog.

Kommer en ny scrape att kosta mig en FastOG-rendering?

Vanligtvis inte. En cover-URL är innehållsbaserad, så om innehållet inte ändrades ändrades inte heller URL:en, och hämtningen blir en cacheträff som inte kostar någon rendering. Om priset ändrades ändrades URL:en — det är en ny rendering, och det är den rendering du ville ha.

Åtgärdar en ny scrape hos Facebook min WhatsApp-förhandsvisning?

Nej. Det är separata cachar. Facebooks debugger är fortfarande värd att använda som validator — den hämtar sidan på samma sätt som WhatsApp kommer att göra och rapporterar vad den hittade — men den kan inte uppdatera WhatsApp.

Hur länge behåller Facebook en förhandsvisning om jag aldrig pingar den?

Meta dokumenterar en standardperiod för ny scrape på cirka 24 timmar, men den exakta spridningstiden kan variera. Det är därför debugger och den programmatiska crawl-vägen finns.

Måste jag pinga varje produkt efter en katalogimport?

Det är det som kön är till för. Att skicka en begäran per produkt direkt i flödet kommer att nå Metas hastighetsgräns och sakta ner handlarens begäran; med kö och avduplicering töms en katalogsvepning utan problem.

Vad händer om Meta avvisar begäran?

Ingenting går sönder. En avvisad eller hastighetsbegränsad ping innebär att Facebook uppdaterar enligt sitt eget schema snarare än omedelbart — taggarna på sidan är redan korrekta, vilket är anledningen till att anropet är best-effort snarare än ett hårt beroende.