How to Clear Facebook's Cache for a Link Preview (Step by Step)

"Clear Facebook's cache" is the phrase most people search for when their link preview is stuck on old content, but Facebook doesn't expose a literal cache-clearing button labeled that way — what actually clears it is forcing a re-scrape through the Sharing Debugger, which discards the old stored result as a side effect of fetching a new one. Here's the exact procedure, along with the parts people commonly get wrong.

Step 1: find the exact URL you need to clear

Facebook's cache is keyed on the precise URL string, including query parameters. If you share a link with UTM parameters attached, that's technically a different cache entry than the bare URL. This matters because clearing the cache for https://example.com/page does nothing for https://example.com/page?utm_source=newsletter — they're treated as separate entries even though they load the same content. Before you start, decide exactly which URL variant you need cleared, and if you routinely share the link with tracking parameters attached, plan to clear that exact variant too, not just the canonical version.

Step 2: open the Sharing Debugger and paste the URL

Facebook's Sharing Debugger is a developer tool accessible through Facebook's developer portal. Paste the full URL exactly as it will be shared — same protocol, same path, same query string. The tool immediately shows you what it currently has cached for that URL: the og:title, og:description, og:image, and other Open Graph properties from the last time it scraped the page, along with a rendered preview of the card.

Step 3: click 'Scrape Again'

This is the actual cache-clearing action. Clicking it tells Facebook to discard the stored scrape and fetch the page fresh right now, reading whatever the live page currently serves. The table and preview on the page update to reflect the new scrape once it completes, which is usually within a few seconds. If the new values still look wrong at this point, the problem isn't the cache anymore — it's that your live page isn't serving what you think it is, which is worth confirming by checking the page's raw HTML source directly.

Step 4: verify with a real share, not just the debugger view

The debugger's own display updating correctly is a strong signal, but the definitive test is trying an actual share — post the link (or use the 'Share' preview if available in your workflow) and confirm the card that renders matches what the debugger showed. This catches edge cases where the debugger's cache and the cache used for actual News Feed or Messenger rendering aren't perfectly synchronized, which can happen briefly right after a scrape.

What clearing the cache does not do

It's worth being clear about the limits here, because they cause a lot of confusion. Clearing Facebook's cache does not retroactively fix the preview on posts that were already published before you ran the scrape — those posts keep whatever preview card was generated when they were originally shared. It also has no effect on any other platform; clearing Facebook's cache does nothing for a stale preview on LinkedIn, X, or Slack, each of which maintains its own separate cache with its own separate refresh mechanism. And it doesn't fix an underlying problem with your page — if your og:image tag is broken, missing, or pointing to an unreachable file, a forced re-scrape will simply confirm that broken state faster; it won't repair it.

Common reasons the scrape still shows stale data

If you've run 'Scrape Again' and the values genuinely haven't changed, check a few things before assuming the tool is broken. A CDN or reverse proxy in front of your origin server might be serving Facebook's crawler a cached HTML response from before your update — check response headers for cache-control or age values on the exact response being served to that request, not just what your application code generates. A CMS-level page cache can have the same effect if it wasn't invalidated when you published the change. And double-check you're testing the exact URL variant you edited — a common mistake is fixing the canonical URL's tags while continuing to test a URL with different query parameters still pointing at the old cached entry.

Clearing the cache for a whole site, not just one URL

There's no bulk operation in the Sharing Debugger for clearing every cached URL on a domain at once — each URL has to be submitted and re-scraped individually. This becomes a real problem after a site-wide change, like a rebrand that swaps a default og:image across every page, or a migration that changes the URL structure of an entire section of a site. In practice, most teams handle this by prioritizing the highest-traffic or most frequently shared URLs first — a homepage, top blog posts, pricing page — rather than attempting to clear every page, since older or rarely shared pages will naturally get a fresh scrape the next time anyone actually shares them, even without a manual trigger. If you're maintaining a list of URLs to clear after a change like this, treat it as an ongoing task tied to your deploy process rather than a one-time cleanup, since new stale entries will keep accumulating as more pages get shared for the first time since the change.

What to do if 'Scrape Again' itself returns an error

Occasionally clicking Scrape Again doesn't return an updated tag table at all — it returns an error saying the URL couldn't be fetched. This is a different problem than a stale cache and worth not mistaking for one. It usually means Facebook's crawler request itself is failing to reach your server: a bot-blocking rule, a rate limiter, or a firewall configuration that's rejecting requests from Facebook's crawler user agent specifically, even though the page loads fine for a normal browser. Check your server or CDN's access logs for requests from Facebook's crawler around the time you clicked the button — if you see the request arriving and getting a non-200 response, or don't see it arriving at all, that's your actual problem, and no amount of re-clicking Scrape Again will resolve it until the underlying block is lifted.

A repeatable checklist

1. Identify the exact URL string, including any query parameters, that needs clearing
2. Confirm the live page's raw HTML actually serves the metadata you expect
3. Open the Sharing Debugger and paste that exact URL
4. Review the currently cached values shown before doing anything
5. Click Scrape Again to force a fresh fetch
6. Confirm the updated table and preview match what you expect
7. Test with an actual new share to confirm the fix is live, not just cached in the debugger view

Reducing how often you need to do this

Manually clearing Facebook's cache is a fine occasional fix, but it's a workflow tax if you're doing it every time you update content. The more durable approach is designing your metadata so there's rarely a stale cache to clear in the first place — specifically, using image URLs that change automatically whenever the underlying image changes, rather than overwriting a file at a fixed URL. useopengraph's rendered OG images follow this pattern by default: publishing a template creates a new version with its own immutable URL, so a content change naturally produces a new URL that Facebook has never scraped, rather than requiring you to manually invalidate an old one. For the cases where a manual clear is still the right move, useopengraph's Cache Debugger can trigger Facebook's official Sharing Debugger scrape directly, alongside checking what other platforms currently see for the same URL, without switching between five different tools.