Facebook Link Preview Not Updating: Why and How to Force a Refresh
Facebook caches the scrape of every URL it's seen shared. Here's exactly why your link preview still shows the old title or image, and the specific steps to force it to re-fetch.
August 16, 20268 min read
You changed the title, swapped the image, fixed a typo in the description — and Facebook is still showing the old version when the link gets pasted into a post or Messenger. This is almost never a bug in your page. It's Facebook's crawler doing exactly what it's designed to do: caching the result of its scrape so it doesn't re-fetch every URL on every share. Understanding that caching layer is the whole fix.
Why Facebook link preview not updating happens by design
When a URL is first shared on Facebook — in a post, a comment, an ad, or a Messenger conversation — Facebook's crawler (the same one behind the Sharing Debugger tool) fetches the page once, reads its og:title, og:description, og:image, and related tags, and stores that result. Every subsequent share of the same URL reuses the stored scrape rather than re-fetching the page. This is a deliberate performance decision: without it, every share of a popular link would trigger a fresh crawl, which doesn't scale and isn't necessary for a page whose content rarely changes. The tradeoff is that when your page's content does change, Facebook has no way of knowing unless something tells it to look again.
This explains a specific and often confusing symptom: the preview was correct the first time you shared the link, months ago, and it's been wrong ever since a redesign or content update — not because the update broke anything, but because nothing has told Facebook to re-scrape since. The stale scrape can persist indefinitely; there's no automatic expiration on a predictable schedule you can rely on.
The fix: Facebook's Sharing Debugger
Facebook provides a dedicated tool for this exact problem — the Sharing Debugger, accessible from Facebook's developer tools. Paste the URL in question and it shows you the last scraped values for every Open Graph tag it found, along with any warnings about missing or malformed tags. Critically, it also has a button — typically labeled 'Scrape Again' — that forces Facebook to discard its cached result and fetch the page fresh right now. After running that, the debugger's display updates to reflect the new values, and shares going forward should pick up the corrected metadata.
A few things trip people up here. First, running the debugger yourself doesn't automatically fix previews that were already posted — an old post shared before you fixed anything keeps whatever preview it rendered at the time; forcing a re-scrape only affects future shares of that URL from that point forward. Second, if you're testing changes in an iterative loop, remember to re-run 'Scrape Again' after each change, since the debugger itself is subject to the same caching behavior it's meant to bypass on demand.
Confirm your tags actually changed before assuming it's a cache problem
It's worth ruling out that the underlying tags genuinely updated before blaming the cache. Open the Sharing Debugger and check the 'og:title', 'og:description', and 'og:image' fields it currently displays before you click Scrape Again — if those already match what you expect, and only the preview shown when actually sharing looks wrong, that's a stronger signal of a genuine cache issue on Facebook's end (or on the client you're testing in, which can have its own local preview cache separate from Facebook's server-side one). If the debugger itself shows the old values even on a first check, your deployed page might not actually be serving the updated tags yet — check the live page's raw source directly, not just what you believe you deployed.
Other reasons a re-scrape doesn't fix it
If you've forced a re-scrape and the preview is still wrong, a few other causes are worth checking. A CDN or reverse proxy in front of your site might be serving a cached HTML response to Facebook's crawler that predates your change — check the cache headers on the response Facebook is actually fetching, not just what your origin server returns. A CMS with its own metadata caching layer can have the same effect. And if your og:image URL itself is unchanged (same filename, same path) but the file behind it was swapped, some CDNs and even browsers cache the image file separately from the page's metadata — using a URL that changes with each meaningful update (a version parameter or a new filename) avoids this entire category of staleness, because there's nothing to invalidate; the old URL simply isn't requested for the new content.
Steps to force a Facebook link preview refresh
- Confirm the live page's raw HTML source actually reflects your intended og:title, og:description, and og:image
- Open Facebook's Sharing Debugger and paste the exact URL, including any tracking parameters you normally share it with
- Check the currently cached values shown before doing anything else
- Click 'Scrape Again' to force Facebook to re-fetch and re-parse the page
- Confirm the debugger's display now matches your live tags
- Test an actual share in a new post or Messenger conversation to confirm the fix took effect
How long a Facebook re-scrape actually takes, and what 'not working yet' really means
A common source of confusion after clicking Scrape Again is assuming it didn't work because the preview still looks wrong a moment later. The debugger's own display generally updates within a few seconds, but that's a different thing from every place the URL might already be rendered — a scheduled post queued in a third-party tool, a browser tab that fetched a preview before you ran the scrape, or a mobile app with its own local caching layer can all continue showing an old version for a while independent of what Facebook's own servers now have stored. Before concluding a re-scrape failed, check the debugger's own table one more time, in a fresh page load, rather than relying on a preview you generated moments before the fix. If the debugger itself shows correct values and a brand-new share still renders wrong, that's a stronger signal something else is interfering — most often a CDN or reverse proxy serving Facebook's crawler a cached HTML response that predates your fix, which is worth checking directly rather than repeating the same re-scrape expecting a different result.
Avoiding this problem going forward
The most durable fix isn't remembering to manually re-scrape every time content changes — it's using image and metadata URLs that change whenever their content does, so there's never a stale cache to clear because the cache key itself is new. This is exactly how useopengraph's rendered OG images work: each template publish creates a new version with its own immutable URL under /api/render/{templateId}/v{version}/..., so a content update naturally produces a new URL rather than overwriting an old one at the same address. Old versions never change, which means platforms that cache aggressively are caching something that's genuinely still correct, and a new version simply gets a fresh scrape the first time it's shared rather than fighting a stale one. For cases where a re-scrape is still needed on a URL you don't control the versioning of, the Cache Debugger in useopengraph re-fetches a URL live and shows exactly what Facebook, X, LinkedIn, and other platforms would currently parse, and can trigger Facebook's own Sharing Debugger scrape directly, without leaving your dashboard to check each platform separately.
Because the first share is what created the cached entry in the first place, and it was accurate at that moment. Nothing about a later redesign automatically tells Facebook to look again — the stale scrape just sits there indefinitely until something explicitly forces a re-scrape, regardless of how much time passes.
The debugger's own cache and the cache used for actual News Feed or Messenger rendering aren't always perfectly synchronized right after a scrape. Test with an actual new share rather than trusting the debugger view alone, and give it a little time if a fresh share still shows the old card immediately after clicking Scrape Again.
Re-run it after each change. The debugger itself is subject to the same caching behavior it's meant to bypass on demand — its display only reflects whatever the most recent scrape captured, so iterating on tags without re-scraping each time will just show you stale results.
Not reliably. Even with correct tags, some CDNs and browsers cache the image file separately from the page's metadata when the filename or path hasn't changed. Using a URL that changes with each update (a version parameter or new filename) avoids this category of staleness entirely, since there's nothing to invalidate.
Stop paying per seat
for a usage-shaped problem.
Unlimited teammates, one usage pool. Start free with the scanner — no card required.