Why your og:image won't update, and what actually clears it
· 7 min read
You fixed the design, reshared the link, and the old image is still there. So you cleared your CDN, added a cache-control header, waited a day, and it is still there.
This is frustrating because two different caches are involved, and almost every answer online treats one of them as if it were the only one. They fail in different ways and clear in different ways. Once you can tell which one is holding your old card, you know what to do. For one of them, the answer is that you can't fix it, which is still useful to know.
The two caches
One: the platform's copy of your page
The first time anybody shares your URL, the platform's crawler fetches the page, reads the meta tags, and stores what it found: the title, the description, and usually the image itself, copied onto the platform's own servers. That snapshot is keyed on the page URL.
Every later share of that URL reads the snapshot. Your server is never contacted again. This is the part people miss. Resharing does nothing, because nobody is asking your server anything. You are looking at a copy that was taken once and kept.
Two: the image bytes
Separately, the image living at your og:image URL is cached by your own CDN, and again by the platform when it copies the file. If you regenerate the card at the same address, everything downstream still holds the old bytes. A crawler that does come back for a fresh look can still be handed the old picture.
If the link was shared before you made the change, it is almost always cache one, and there is usually nothing you can do for that already-posted link. If it is a brand-new share and the card is still wrong, it is cache two, and you can fix that one yourself.
What actually clears each platform
Only two of the major platforms give you a button. The rest expire on their own schedule and do not publish it.
| Platform | Can you force a re-read? | How |
|---|---|---|
| Yes | Sharing Debugger, “Scrape Again”. Requires a logged-in Facebook account. | |
| Yes | Post Inspector re-reads the page on demand. | |
| X | No | The Card Validator was retired. There is no public way to make X re-read a URL. |
| Slack | No | Unfurls expire on their own, and you can't flush them. |
| Discord | No | Also cached, with no refresh you can trigger. |
| No | No tool, and previews are generated on the sender's device. | |
| iMessage | No | Cached per device, with no way in. |
Treat that table as a starting point. These products change their behaviour without announcing it, and the two debuggers move around. If a card matters, check it before you publish, not after.
The one lever you have
Both caches are keyed on a URL. You cannot flush them, but you can change the key. That is the whole trick, and it only helps in one of the two places:
- The page URL is not usefully changeable. A different URL is a different post, with none of the shares the old one had.
- The image URL is entirely yours. Put a version in it, and bump the version whenever the artwork changes.
<!-- before -->
<meta property="og:image" content="https://example.com/og/launch.png">
<!-- after: nothing anywhere has ever seen this URL -->
<meta property="og:image" content="https://example.com/og/launch.png?v=3">This has limits. It does not force anyone to re-read your page. What it does mean is that whenever a re-read does happen (a new share, a platform you have not been posted on yet, a scheduled recrawl, someone hitting the Facebook debugger), the crawler follows a URL nothing has ever cached and gets the current art. Without a version, your HTML can be right while the bytes served to that crawler are months old.
What to do about it
- Version the image URL from the very first deploy. Retrofitting it after a page has been shared is the case that cannot be fixed.
- Bump the version whenever the design changes, not only when the title does.
- Use the Facebook and LinkedIn debuggers on anything important. They are the only two re-reads you can actually trigger.
- Accept that links already circulating on X, Slack, Discord and WhatsApp will keep the old card until their caches expire on their own. There is no lever here, so don't spend a day trying.
- Do not rely on
Cache-Controlon the image. It influences well-behaved intermediaries, and it does nothing at all about a copy a platform has already taken onto its own servers.
The cheaper habit
All of this is recoverable if you catch it before the link goes out and close to unrecoverable afterwards, which makes checking the card part of publishing rather than part of debugging. Our link preview checker reads any public page, fetches the image, and shows you what each platform will do with it. It needs no account and takes about four seconds.
OGsmith puts the version in the image URL for you: every card carries a v parameter, and changing your design bumps it across every card on the account at once, so you never have to remember which pages need editing. That is all the feature does. It's simple, but it's the one thing the caches leave you.