You found the problem. The og:image was pointing at a file that no longer existed, or the title was left over from a draft, or the whole card was blank because someone shipped the page without meta tags. You fixed it, confirmed the page looks right, and reshared the link.
The old preview came back. Same wrong image, same stale headline, as if the fix never happened.
It did happen. You're just not looking at your page anymore. You're looking at a copy of your page that a social platform saved the first time it crawled the link, and every platform holds that copy under different rules, for a different length of time, with a different amount of control handed back to you. Some give you a real purge button. One quietly took its button away three years ago and left a generation of blog posts pointing at a dead URL.
First, Confirm the Fix Actually Shipped
Before fighting a cache, rule out the possibility that there's nothing to fight. A large share of "the platform cached my old preview" reports are really the page still serving the old preview, and no amount of re-scraping fixes that. Check what a crawler sees right now, not what your CMS preview pane shows you. Prelinq's Open Graph checker fetches the page live on every request and holds no cache of its own, so what it shows you is genuinely current.
Three things account for most false alarms:
- A relative og:image path (/images/card.png instead of the full https:// URL). Browsers resolve it, crawlers usually don't.
- An og:image URL that requires auth or sits behind a firewall. The crawler gets a 403 and renders nothing.
- The tags sitting outside the <head>, or after a script that pushes them past the first chunk the crawler reads.
If the checker shows the correct tags, then it's a cache, and which platform you're on decides what you can do about it.
Facebook: The One Real Purge Button
Facebook has the most capable tool of any platform, which makes sense given it wrote the Open Graph protocol in the first place. Paste your URL into the Sharing Debugger, click "Scrape Again," and Facebook discards the stored copy and re-fetches immediately. It also lists every tag it found and flags what's missing, which is the fastest way to catch a typo before it goes out to an audience.
One detail governs everything here: Facebook keys its cache on the og:url tag, not the address you typed. If two pages declare the same og:url, Facebook treats them as one object and serves one preview for both. If og:url is missing, behavior gets unpredictable. The debugger requires a Facebook account, which matters more than it sounds like it should, and we get into why further down. There's more on Facebook's specific quirks in our guide to fixing Facebook previews.
LinkedIn: Post Inspector, No Login Required
LinkedIn caches preview metadata for up to seven days, which is long enough that waiting it out is rarely an option when you have a post scheduled. The Post Inspector solves it: paste the URL, click Inspect, and LinkedIn invalidates its stored copy and pulls the page fresh. The rendered preview it shows you afterward is what your connections will see.
Unlike Facebook's debugger, Post Inspector doesn't ask you to sign in, which makes it the single most useful tool in this article. You can point it at any URL on the public web. That won't let you change what a page serves, but it does tell you exactly what LinkedIn will show before you commit to a post. Our LinkedIn preview guide covers the rest of the platform's oddities.
X: There Is No Button Anymore
Search for how to refresh a Twitter card and you'll be told to use the Card Validator at cards-dev.twitter.com/validator. That tool is gone. X removed the preview functionality in 2023 and confirmed it in its own developer forums, and the tutorials still recommending it have simply never been updated. If you have followed instructions that ended with a 404, this is why.
What replaced it is nothing. There is no public way to purge X's card cache, and cards are held for up to seven days. Your options are to wait, or to change the URL so X has no stored copy to serve. Third-party checkers can show you what the card will look like, since they fetch the page directly, but none of them can reach into X's cache. When a card is wrong on X, plan around a new URL rather than a fix, and read how X decides which card format to render before you build the replacement.
Discord: Two Caches, Not One
Discord explains a symptom that confuses people on every platform but shows up here most often: the title updates and the image doesn't. That's because Discord stores embed metadata and proxied images in separate caches that expire independently. You can end up with new text sitting next to a picture you replaced last week, and neither cache has a public invalidation tool.
In practice, Discord's metadata cache is short, commonly around half an hour, though it's undocumented and varies. Deleting the message and posting the link again after a wait is the usual workaround, and changing the URL is the reliable one. Since Discord keys on the exact URL it was given, even a trailing query parameter is enough to get a clean fetch. Our Discord guide goes deeper on how embeds get assembled.
Slack: Thirty Minutes, Workspace-Wide
Slack caches an unfurl for roughly thirty minutes, and that cached copy is shared globally rather than per-channel. Post a link in one channel with a broken preview and it will look broken in every other channel and workspace it's shared into during that window. Slack's own team has long advised that deleting the message clears the stored unfurl, and its unfurling documentation covers how the crawler behaves. Slack also proxies images through its own cache, so as with Discord, text and image can refresh at different times.
iMessage and WhatsApp: Nothing to Press
There's no debugger for either, because there's no central cache to clear. Previews are generated and stored on the device, which means a link can look correct on a colleague's phone and wrong on yours indefinitely. Testing on your own handset tells you very little. If a preview needs to be right in a message thread, the only dependable approach is to get the tags correct before the link is ever sent, because after that it's out of anyone's hands.
The Query Parameter Trick, and When It Fails
The universal workaround is to append something meaningless to the URL: ?v=2, ?refresh=1, anything. The platform sees a string it has never crawled, finds no stored copy, and fetches the page fresh. It works on X, Discord, and Slack, which is most of the cases where no purge button exists.
It's worth being precise about what this does, though, because it isn't clearing anything. You're creating a second cache entry beside the stale one, which still sits there serving the old preview to anyone who shares the original URL. And on the platforms that key their cache on og:url rather than the address they were handed, Facebook most notably, a well-built page defeats the trick entirely: your page declares its canonical og:url, Facebook looks up that value, finds the copy it already has, and serves you the same stale card you were trying to escape. The better the page's tags, the less reliably the hack works.
None of This Works on a Link You Don't Own
Every fix above assumes you can either edit the page or log into a tool that will re-crawl it. That assumption breaks on most of the links people actually share. Affiliate offers, partner landing pages, news articles, a client's site you have no credentials for. You can run LinkedIn's inspector against someone else's URL and learn exactly how bad the preview is, then discover there's nothing you can do with that information. If the destination ships a broken og:image, it's broken for you, and clicking "Scrape Again" just re-fetches the same broken tags. We wrote about controlling the preview of a link you don't own separately, because it's a different problem wearing the same clothes.
This is the case Prelinq is built for. Instead of asking a platform to forget what it stored about someone else's page, you share a Prelinq link: a page you control that carries the title, description, and image you chose, then forwards the visitor to the original destination. Because every Prelinq link gets its own slug and its own og:url, it arrives at each platform as a URL nothing has crawled before. There's no stale copy to purge, and no waiting seven days on a cache you can't reach.
The next time a preview is wrong an hour before a post goes out, that's the difference that matters. Fixing the page means editing tags, finding the right debugger, hoping the platform honors it, and having no recourse at all on X. Prelinq gives you two active links free, so you can build the card, see it rendered across X, LinkedIn, Discord, and Facebook side by side, and share it knowing what your audience will see.