Tving en opdatering af Facebook Open Graph-cachen

Du kan tvinge en opdatering af Facebook Open Graph-cachen, fordi Facebook — alene blandt de store platforme — tilbyder en programmatisk måde at anmode om det på. Brug enten Sharing Debugger's Scrape Again-knap til et enkelt link, eller kald Graph API'ens scrape-endpoint med et app-adgangstoken (app access token). Der er ingen måde at tvinge WhatsApp, LinkedIn eller X: de udgiver ingen sådan API, for nogen.

Det, der snubler alle

Meta cacher en link-preview nøglet på side-URL'en og gemmer sin egen kopi af billedet. Meta læser ikke din side igen for at opdage, at og:image nu peger et andet sted hen.

Så denne arbejdsgang fejler, og det er den, de fleste prøver:

Skift coveret → og:image-URL'en er ny → antag, at Facebook vil hente den → det gør den ikke.

En ny billed-URL bryder billed-CDN'en. Den gør intet ved Metas side-nøglede cache. For at flytte Facebook skal du fortælle Meta, at siden er ændret.

Mulighed 1 — Sharing Debugger (én side, manuelt)

Åbn developers.facebook.com/tools/debug, indsæt sidens URL, og tryk på Scrape Again. Meta henter siden igen og opbygger sin cachelagrede forhåndsvisning på ny.

Det er også den bedste gratis validator, du har, fordi den rapporterer, hvad Meta faktisk fandt, i stedet for hvad du håbede var der: manglende eller duplikerede og:image, utilgængelige billeder, ikke-understøttede formater. To ting, den ikke kan: den kan ikke røre WhatsApp (separat cache i modtagerens app), og den er ikke et katalogværktøj — den håndterer én URL ad gangen, med ratebegrænsning og et menneske foran den.

Mulighed 2 — Graph API'en (dette er det, et plugin kalder)

Den programmatiske ækvivalent, som FastOG bruger, er en POST til Graph API'en med scrape=true:

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}"

Fire detaljer, der betyder noget:

• id er side-URL'en, ikke billed-URL'en. Meta nøgler sin cache på siden, så at pinge billedadressen opdaterer intet.
• En token er påkrævet — Meta har krævet en på dette endpoint siden oktober 2017. En app-access-token i formen {app_id}|{app_secret} er nok, og den kræver intet brugerlogin, hvilket er præcis det, der gør kaldet muligt fra et baggrundsjob.
• Graph API-versioner flytter sig. FastOG fastlåser en testet Graph API-version; tjek Metas aktuelle dokumentation og changelog, før du fastlåser en version i din egen kode.
• Behandl det som best-effort. Meta rate-limiter scrape-kald, og et afslag betyder kun, at Facebook opdaterer på sin egen tidsplan i stedet for øjeblikkeligt — tagsene på din side er allerede korrekte.

Fordi det er rate-limited, skal du ikke affyre det inline ved hver gemning af et stort katalog. Kø det i stedet, og de-duplikér efter URL, så gentagne gemninger af det samme uændrede produkt ikke bruger rate limit.

Mulighed 3 — et plugin, der gør det for dig

Plugins markedsført som en "Open Graph cache refresh" falder i to grupper, og kun én af dem kan løse Facebook:

Før du installerer et, så find ud af hvilken type det er. En tidsstempelparameter er en reel løsning på et forældet billede og en ikke-løsning på et forældet Facebook-kort.

FastOG for WooCommerce gør det andet, og du konfigurerer intet. Pluginnet registrerer WooCommerces native produkt-webhooks, så når du gemmer et produkt, udløses en Meta-genindhentning (re-scrape) for produktets permalink — i kø, de-duplikeret inden for et kort tidsvindue, og best-effort af design, så et afslag aldrig får gemningen til at fejle. Det gælder produktsider (product.created / product.updated); kategori- og blogredigeringer er ikke dækket.

Billedsiden håndteres separat og anderledes end hos alle konkurrenter: fordi en FastOG-cover-URL indeholder de værdier, der producerede den, opretter redigering af prisen eller billedet en ny cover-URL. Meta kan ikke genudlevere et billede, hvis adresse ikke længere findes.

Hvor Facebook ikke er nok

Hvis en preview er forældet på WhatsApp, er svaret ikke et Facebook-værktøj — det er at få butikssiden rigtigt, så den næste aflæsning er korrekt.

Når det stadig viser det gamle billede efter en vellykket scraping

Gå gennem denne liste i rækkefølge:

1. Server siden stadig det gamle tag? curl -s https://your-store.com/product/example | grep -i 'og:image' — en cachet HTML-side med et forældet og:image gør hele scrapingen meningsløs. Ryd sidecachen.
2. Udskriver siden mere end ét og:image? Hvis to plugins hver udsender ét, tager crawleren det første, den læser. Tæl dem.
3. Er billedet tilgængeligt og ikke blokeret? curl -I <image-url> bør returnere 200 med en billed-Content-Type. Sociale crawlerer respekterer robots.txt, så et billede på en Disallow:-sti fejler på en måde, der ligner en korrupt fil — og curl vil aldrig kunne gengive det, fordi curl ignorerer robots.txt.
4. Ændrede billed-URL'en sig faktisk? Hvis den ikke gjorde det, ændrede indholdet sig heller ikke — kontrollér, at pris-/fotoredigeringen nåede den kilde, kortet trækkes fra.
5. Tjek debuggeren igen. Hvis den nu rapporterer det nye billede, og Facebook stadig viser det gamle kort, kigger du på Facebooks egen udbredelse, ikke dine tags.

FAQ

Findes der et officielt API til at rydde Facebooks Open Graph-cache?

FastOG bruger scrape-endepunktet (POST https://graph.facebook.com/{version}/?id={page-url}&scrape=true&access_token={token}). Meta dokumenterer Sharing Debugger og det programmatiske crawl-flow; den præcise endepunktsform og Graph API-version kan ændre sig, så verificér dem mod Metas aktuelle dokumentation, før du implementerer det selv.

Kræver Sharing Debugger en app eller en token?

Nej. Det er et offentligt værktøj, og det virker for enhver offentlig URL. Det, det ikke kan, er at køre efter en tidsplan eller dække et katalog.

Vil en ny scrape koste mig et FastOG-render?

Som regel ikke. En cover-URL er indholdsafledt, så hvis indholdet ikke ændrede sig, ændrede URL'en sig heller ikke, og forespørgslen er et cache-hit, der ikke koster et render. Hvis prisen ændrede sig, ændrede URL'en sig — det er ét nyt render, og det er det render, du ønskede.

Retter en ny scrape hos Facebook min WhatsApp-preview?

Nej. Det er separate caches. Facebooks debugger er stadig værd at bruge som validator — den henter siden på samme måde, som WhatsApp vil, og rapporterer, hvad den fandt — men den kan ikke opdatere WhatsApp.

Hvor længe beholder Facebook en preview, hvis jeg aldrig pinger den?

Meta dokumenterer en standard gen-scrape-periode på omkring 24 timer, men den præcise spredningstid kan variere. Det er derfor, debuggeren og den programmatiske crawl-sti findes.

Skal jeg pinge hvert produkt efter en katalogimport?

Det er det, køen er til. At sende én anmodning pr. produkt inline vil ramme Metas rate-limit og gøre merchantens anmodning langsommere; køet og de-duplikeret dræner en kataloggennemgang ufarligt.

Hvad hvis Meta afviser anmodningen?

Intet går i stykker. En afvist eller rate-limited ping betyder, at Facebook opdaterer efter sin egen tidsplan i stedet for øjeblikkeligt — tagsene på siden er allerede korrekte, hvilket er grunden til, at kaldet er best-effort snarere end en hård afhængighed.

Relateret

• Øjeblikkelig WhatsApp-billedopdatering til WooCommerce
• Guide til cache af sociale forhåndsvisninger: Facebook, WhatsApp, LinkedIn, X, Slack og Discord
• og:image vises ikke? Sådan løser du det
• WhatsApp-linkforhåndsvisning vises ikke? Ret og:image
• Sådan cacher du OG-billeder
• WooCommerce-prissynkronisering i WhatsApp-forhåndsvisningen
• WooCommerce-integration: FastOG til WooCommerce