Link Preview Not Updating on Any Platform? Start Here

If your link preview isn't updating and you're not sure it's Facebook specifically — maybe it's stale in Slack, or Discord, or an iMessage thread, or a LinkedIn post — the underlying cause is the same everywhere: every platform that generates a rich preview from a URL caches the result of that scrape so it isn't re-fetching your page on every single paste. What differs is how long each platform holds onto that cache and what, if anything, you can do to force it to look again. This is the platform-agnostic version of that problem — a rundown of where each major platform's cache lives and how to break it.

Why link preview not updating is universal, not a bug

Every unfurl works roughly the same way: a bot fetches your page once, parses its Open Graph and Twitter Card tags, renders a card from what it finds, and stores that result somewhere so the next person who shares the same URL doesn't trigger a fresh crawl. That storage is what breaks when your content changes. The page is genuinely different now, but the platform is still showing what it found the first time anyone shared it — sometimes days ago, sometimes years ago. This is standard behavior across every major platform; none of them re-check a URL's metadata on some fixed schedule you can predict, so a stale preview can persist indefinitely until something forces a refresh.

Facebook and Messenger

Facebook's cache is the most persistent and the most documented. Use the Sharing Debugger tool, paste your URL, and click the button to force a re-scrape. This clears Facebook's server-side cache for that exact URL going forward, though it doesn't retroactively fix previews on posts already published before you ran it.

X (Twitter)

X doesn't offer an official public debugger with a manual refresh button the way Facebook does. The reliable workaround is a cache-busting change to the URL itself — appending a harmless query parameter, or changing an existing one, so the platform treats it as a URL it hasn't seen and fetches fresh. This means the visible link in your post won't be byte-identical to the old one, which is a real tradeoff if you care about a clean-looking URL, but it's the most consistent way to guarantee a fresh card on X specifically.

LinkedIn

LinkedIn has its own Post Inspector tool, functionally similar to Facebook's debugger — paste a URL, see what LinkedIn currently has cached, and trigger a re-fetch. LinkedIn's crawler also tends to be stricter about what it accepts than other platforms (particularly around image size and load time), so if a re-fetch through Post Inspector still doesn't produce an image or shows an unexpected one, the issue may be a rejection rather than a stale cache — worth checking the underlying image against LinkedIn's requirements directly rather than assuming another re-scrape will fix it.

Slack and Discord

Both Slack and Discord cache unfurled link previews, and neither offers a public manual-refresh tool the way Facebook and LinkedIn do. In practice, previews in these tools tend to refresh on a shorter cycle than Facebook's — often effectively within a day or so — but there's no guaranteed timeline, and no button to force it immediately. If you need an updated preview to show up right away in a Slack or Discord message, the cache-busting URL parameter approach (the same one that works on X) is the most reliable option, since it sidesteps the cache entirely rather than trying to invalidate it.

iMessage

iMessage's rich link previews are generated and cached in a way that's largely opaque and device-local rather than centrally controlled the way Facebook's server-side cache is. There's no debugger tool to force a refresh. A cache-busting URL change is again the most dependable fix, along with simply trying the link fresh on a device or account that hasn't previously loaded a preview for that exact URL string.

The cache-busting technique, explained

For any platform without an official re-scrape tool, adding or changing a query parameter on the URL — something like ?v=2 or ?updated=true — makes the platform treat it as a URL string it hasn't crawled before, since most caches key on the exact URL rather than the underlying page content. This works everywhere, at the cost of the shared link no longer being character-for-character identical to the original. If you're using branded, trackable sharing links rather than raw destination URLs, this becomes much less of a concern: you can point a short link at a fresh destination URL (or a fresh version of your rendered content) without changing the short link a person actually sees and clicks, sidestepping the visible-URL tradeoff entirely.

Why 'it worked when I tested it' can still be wrong for everyone else

A subtle trap in debugging a cross-platform stale preview is that each platform's cache is scoped globally, not per-viewer, but the way you personally test a fix can create a false sense of resolution. If you're a member of a Facebook developer account or have previously run the Sharing Debugger on a URL, you may see updated results sooner than someone encountering the link for the first time through a regular share, because you've effectively triggered the refresh yourself. Conversely, a colleague pasting the same link in a separate Slack workspace, or a customer opening it fresh in Messenger, may still be served a cached version from before your fix if that particular cache entry hasn't been individually cleared. When verifying a fix across platforms, it's worth testing from a context that hasn't already interacted with the debugging tools — a different account, a private window, or simply asking someone else to check — rather than relying solely on your own repeated tests, which can inadvertently be the thing forcing the refresh you're trying to confirm happened on its own.

Why the same cache-busting trick doesn't always feel worth it

The obvious objection to appending a query parameter every time you need a fresh preview is that it clutters the URL, and if you're sharing links in a context where a clean, memorable URL matters — a printed piece, a short verbal mention, a QR code already generated — it's a real cost, not just a cosmetic one. This is one of the strongest practical arguments for putting a redirect or branded short link in front of your actual destination rather than sharing raw URLs directly: the short link itself never has to change to bust a cache, because what it points to underneath can change independently. A person sees go.yourbrand.com/launch either way; what determines whether the platform treats it as fresh content is entirely under your control on the backend, invisible to whoever is looking at the link.

A quick reference

• Facebook / Messenger: use the Sharing Debugger's re-scrape button
• LinkedIn: use the Post Inspector's re-fetch, and check image requirements if it still fails
• X: no official tool — use a cache-busting query parameter
• Slack / Discord: no official tool — cache-busting parameter is the reliable option
• iMessage: no official tool — cache-busting parameter or a genuinely fresh device/account

How useopengraph handles this across platforms

Chasing down each platform's own debugger and cache behavior individually is the annoying part, not any single fix. useopengraph's Cache Debugger re-fetches a URL live and shows what Facebook, X, LinkedIn, and other platforms would actually parse right now, bypassing each platform's own cache in one check rather than opening five separate tools — and it can trigger Facebook's official Sharing Debugger scrape directly through their API. Because useopengraph's own rendered OG images use versioned, immutable URLs that change automatically with every template publish, the images themselves never need a cache-bust in the first place: a new version simply has a new URL, so there's nothing stale for any platform to be caching.