How to Force-Refresh Facebook's Cache for a URL

Facebook does not re-crawl a URL just because the page behind it changed. Its crawler visits a URL once, parses the og: tags it finds, and stores that result indefinitely — there's no polling, no automatic expiry, no background job that notices your og:image changed last week. If you update the metadata on a page and someone shares that exact URL on Facebook, they'll see the old preview until something explicitly tells Facebook to throw away what it cached and crawl again. Knowing how to force-refresh Facebook's cache for a URL is the difference between a fix that works instantly and one that sits invisible for as long as Facebook happens to hold that cached entry, which can be indefinite.

The mechanism: a scrape parameter, not a wait

The actual mechanism behind a forced refresh is a POST request to Facebook's Graph API against the URL you want re-crawled, with a parameter called scrape set to true. That single parameter is what tells Facebook's crawler to ignore whatever it has stored and fetch the page fresh, parse the current og: tags, and overwrite the cached entry with the new result. It is not a request to check whether the page changed — it's an unconditional instruction to re-crawl regardless of whether Facebook thinks anything is different. This is important because it means the fix is deterministic: run the scrape request, get a fresh crawl, done. There's no ambiguity about whether it 'might' pick up the change eventually.

In practice, most people trigger this scrape=true call without writing a raw API request at all — it's exactly what happens under the hood when you paste a URL into Facebook's Sharing Debugger and click the button to fetch new scrape information. The debugger's interface is a wrapper around the same Graph API call. Understanding that it's the same mechanism matters if you're troubleshooting programmatically, or if you're trying to explain to a non-technical teammate why 'just wait for Facebook to notice' isn't a real strategy — there's no passive path that gets you there. Someone, or something, has to make that call.

Why this trips people up

The most common mistake is assuming the fix on the page side is the whole job. You update og:image, verify the change is live by viewing source, and consider it resolved — but the page having correct tags and Facebook's cache reflecting those tags are two separate facts. Facebook's crawler has no idea the page changed until it's told to look again. A page can sit correctly updated for months while Facebook keeps serving a preview from before the change, and nothing about that state looks broken from the page's own source code, which is why it's such a persistent source of confused bug reports: 'I fixed it, why is it still showing the old image.'

A second common trip-up is scope. A force-refresh only affects the exact URL you submit it for. If your site has both a trailing-slash and non-trailing-slash version of a URL, or an http and https version, or a version with and without a tracking parameter, Facebook treats each as a distinct cache entry. Refreshing one doesn't touch the others. If you're not sure which exact URL variant is being shared — a tracked sharing link, a canonicalized version, a raw one — refresh whichever URL is actually the one people are pasting, not the one you assume is canonical.

When you actually need this

Not every metadata change needs a forced refresh. If a URL has never been shared on Facebook before, there's nothing cached, and the first share will crawl fresh automatically. Force-refreshing matters specifically when a URL has already been shared at least once — meaning Facebook already has something cached — and you've since changed the og:title, og:description, og:image, or any other tag Facebook reads. Common triggers:

• You swapped a blog post's featured image and the og:image tag now points somewhere new
• You corrected a title or description that had a typo or was left as placeholder copy
• A rebrand changed logos, colors, or product names referenced in og: tags across many pages at once
• A seasonal or promotional image needs to replace a default one, and later needs to revert
• You migrated platforms and the new site serves different og: values than the old one did at the same URL

Doing it manually vs. building it into a workflow

For a single URL, one-off, the Sharing Debugger's interface is the fastest path — paste the URL, request a fresh scrape, confirm the new preview renders correctly. It gets impractical fast when you're dealing with more than a handful of URLs, though. Rebranding forty pages, migrating a product catalog, or fixing a template bug that affected every post published in a given month all mean refreshing dozens or hundreds of individual URLs, and doing that by hand in a browser one at a time is a genuinely bad use of time. That's the case for wiring the scrape=true call into a script or a workflow that runs it programmatically against a list of URLs, rather than clicking through Facebook's debugger for each one.

What happens if you skip it

Skipping the forced refresh doesn't necessarily mean the stale cache lasts forever, but it does mean you have no control over when it clears. Facebook's cache entries don't have a documented, guaranteed expiry that you can plan around — in practice, an entry can persist for a very long time if the URL isn't shared often enough to trigger whatever internal refresh logic Facebook applies. For a URL that gets shared occasionally, that can mean months of a wrong preview sitting live, silently undermining every share, with no visible error anywhere to prompt someone to investigate. The forced refresh isn't a nice-to-have step for the cautious — it's the only reliable way to guarantee the fix you made actually reaches the next person who shares the link, rather than hoping the timing works out.

It's also worth understanding that a forced refresh is safe to run defensively. Triggering scrape=true on a URL that's already correctly cached doesn't break anything — Facebook just re-crawls, confirms the same result, and re-stores it. That means there's no downside to making a forced refresh part of your standard post-deploy checklist for any page whose metadata could plausibly have changed, rather than trying to remember exactly which URLs need it and skipping the rest. Treating it as routine, rather than a special troubleshooting step reserved for when someone complains, closes the gap between when a fix ships and when it's actually visible to anyone sharing the link.

How useopengraph handles this

The Cache Debugger in useopengraph exposes exactly this mechanism directly — it can force-refresh Facebook's own cache for a URL through their Sharing Debugger API without you needing to leave the tool, construct the raw request yourself, or remember the scrape=true parameter. It also re-fetches the URL live first, so you can confirm the underlying og: tags are actually correct before triggering the refresh — there's no point forcing Facebook to re-crawl a page whose tags are still wrong. Combined with the ability to check what Twitter, LinkedIn, and other platforms currently see for the same URL, it turns the 'why is Facebook still showing the old image' cycle into a single check-then-fix action instead of a scavenger hunt through a debugger built for one platform at a time.