FastOG

Force a Facebook Open Graph Cache Refresh

You can force a Facebook Open Graph cache refresh, because Facebook — alone among the major platforms — exposes a programmatic way to ask. Either use the Sharing Debugger's Scrape Again button for a single link, or call the Graph API's scrape endpoint with an app access token. There is no way to force WhatsApp, LinkedIn or X: they publish no such API, for anyone.

The thing that trips everyone up

Meta caches a link preview keyed on the page URL, and stores its own copy of the image. It does not re-read your page to notice that og:image now points somewhere else.

So this workflow fails, and it is the one most people try:

Change the cover → the og:image URL is new → assume Facebook will pick it up → it does not.

A new image URL busts the image CDN. It does nothing to Meta's page-keyed cache. To move Facebook you must tell Meta that the page changed.

Cache Keyed on Cleared by
Your page cache / CDN the page URL purging it
Meta's link-preview cache the page URL the scrape endpoint or the Sharing Debugger
Meta's copy of the image the image URL a new image URL
Your image CDN the image URL a new image URL

Option 1 — the Sharing Debugger (one page, manual)

Open developers.facebook.com/tools/debug, paste the page URL, and press Scrape Again. Meta refetches the page and rebuilds its cached preview.

It is also the best free validator you have, because it reports what Meta actually found rather than what you hoped was there: missing or duplicated og:image, unreachable images, unsupported formats. Two things it will not do: it cannot touch WhatsApp (separate cache, in the recipient's app), and it is not a catalogue tool — it is one URL at a time, rate-limited, with a human in front of it.

Option 2 — the Graph API (this is what a plugin calls)

The programmatic equivalent used by FastOG is a POST to the Graph API with 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}"

Four details that matter:

  • id is the page URL, not the image URL. Meta keys its cache on the page, so pinging the image address refreshes nothing.
  • A token is required — Meta has required one on this endpoint since October 2017. An app access token in the form {app_id}|{app_secret} is enough, and it needs no user login, which is exactly what makes the call possible from a background job.
  • Graph API versions move. FastOG pins a tested Graph API version; check Meta's current documentation and changelog before pinning a version in your own code.
  • Treat it as best-effort. Meta rate-limits scrape calls, and a refusal means only that Facebook refreshes on its own schedule instead of immediately — the tags on your page are already correct.

Because it is rate-limited, do not fire it inline on every save of a large catalogue. Queue it, and de-duplicate by URL so repeated saves of the same unchanged product do not spend rate limit.

Option 3 — a plugin that does it for you

Plugins marketed as an "Open Graph cache refresh" fall into two groups, and only one of them can fix Facebook:

Mechanism What it clears Fixes a stale Facebook preview?
Appends a changing query string to the image URL (?v=timestamp) your image CDN No — Meta's cache is keyed on the page
Calls the scrape endpoint for the page URL Meta's preview cache Yes

Before installing one, find out which it is. A timestamp parameter is a real fix for a stale image and a non-fix for a stale Facebook card.

FastOG for WooCommerce does the second one, and you configure nothing. The plugin registers WooCommerce's native product webhooks, so saving a product dispatches a Meta re-scrape for that product's permalink — queued, de-duplicated within a short window, and best-effort by design so a refusal never fails the save. It applies to product pages (product.created / product.updated); category and blog edits are not covered.

The image side is handled separately, and differently from every competitor: because a FastOG cover URL contains the values that produced it, editing the price or the photo mints a new cover URL. Meta cannot re-serve a picture whose address no longer exists.

Where Facebook is not enough

Platform Can you force a refresh? What actually happens
Facebook Yes — debugger or scrape=true Requests a re-scrape; propagation time varies
WhatsApp No Preview is cached in the recipient's app; no API exists
LinkedIn No documented programmatic API Re-reads on its own schedule; no public timing guarantee is made here
X / Twitter No documented programmatic API Re-reads on its own schedule; no public timing guarantee is made here
Slack, Discord No Short-lived caches that clear themselves in minutes to hours

If a preview is stale on WhatsApp, the answer is not a Facebook tool — it is getting the store side right so the next read is correct.

When it still shows the old image after a successful scrape

Work down this list, in order:

  1. Is the page still serving the old tag? curl -s https://your-store.com/product/example | grep -i 'og:image' — a cached HTML page with a stale og:image defeats the scrape entirely. Purge the page cache.
  2. Does the page print more than one og:image? If two plugins each emit one, the crawler takes the first it reads. Count them.
  3. Is the image reachable, and not blocked? curl -I <image-url> should return 200 with an image Content-Type. Social crawlers honour robots.txt, so an image on a Disallow: path fails in a way that reads like a corrupt file — and curl will never reproduce it, because curl ignores robots.txt.
  4. Did the image URL actually change? If it did not, the content did not change either — check that the price/photo edit reached the source the card is drawn from.
  5. Check the debugger again. If it now reports the new image and Facebook still shows the old card, you are looking at Facebook's own propagation, not your tags.

FAQ

Is there an official API to clear Facebook's Open Graph cache?

FastOG uses the scrape endpoint (POST https://graph.facebook.com/{version}/?id={page-url}&scrape=true&access_token={token}). Meta documents the Sharing Debugger and programmatic crawl flow; the exact endpoint shape and Graph API version can change, so verify them against Meta's current documentation before implementing it yourself.

Does the Sharing Debugger need an app or a token?

No. It is a public tool and it works for any public URL. What it cannot do is run on a schedule or cover a catalogue.

Will re-scraping cost me a FastOG render?

Usually not. A cover URL is content-derived, so if the content did not change the URL did not either, and the fetch is a cache hit that costs no render. If the price changed, the URL changed — that is one new render, and it is the render you wanted.

Does re-scraping Facebook fix my WhatsApp preview?

No. They are separate caches. Facebook's debugger is still worth using as a validator — it fetches the page the same way WhatsApp will and reports what it found — but it cannot refresh WhatsApp.

How long does Facebook keep a preview if I never ping it?

Meta documents a standard re-scrape period of about 24 hours, but the exact propagation time can vary. That is why the debugger and the programmatic crawl path exist.

Do I have to ping every product after a catalogue import?

That is what the queue is for. Sending one request per product inline will hit Meta's rate limit and slow the merchant's request; queued and de-duplicated, a catalogue sweep drains harmlessly.

What if Meta refuses the request?

Nothing breaks. A refused or rate-limited ping means Facebook refreshes on its own schedule rather than immediately — the tags on the page are already correct, which is why the call is best-effort rather than a hard dependency.

Try it free — no signup required

Preview and test dynamic OG images in seconds.

Open the Free OG Image Tester