How to refresh a cached link preview

Force a re-fetch with the platform’s own debug tool, and if the picture is what changed, publish it under a new filename. Doing only the first frequently leaves the old image in place, because platforms cache the card and the image separately.

That two-part answer is the whole technique. The rest is knowing what to expect from each platform and what to do when neither works.

The card cache and the image cache are different

Understanding this saves a lot of confusion.

When a URL is first shared, a platform stores the card: title, description, and a reference to an image it downloaded. It also stores its own copy of the image, keyed by the image URL.

So there are two things to invalidate. A successful re-scrape updates the card — but if your og:image still points at preview.png and the platform already has a copy of preview.png, it may reuse it. You changed the file; the URL didn’t change; their cache key didn’t change.

Which is why the reliable move for images is a new URL rather than a new file at the same URL.

Re-fetching per platform

The mechanics differ but the shape is the same everywhere: each major platform provides a developer tool where you paste a URL, see what its crawler found, and trigger a fresh fetch.

Facebook has a sharing debugger that shows the scraped tags, warnings about missing ones, and a button to scrape again. It’s the most informative of them — worth using even for problems on other platforms, because it tells you what a crawler actually saw.

X/Twitter historically had a card validator; access has changed over time. Sharing to a low-visibility post and deleting it is a common practical fallback.

LinkedIn has a post inspector that re-fetches. LinkedIn caches aggressively, and its inspector is the only reliable way through.

Slack re-fetches on its own schedule and honours ordinary HTTP caching headers on the page, which makes it the platform most responsive to a plain cache-control fix.

Because these tools move around, the durable skill isn’t remembering URLs — it’s knowing that each platform has one, and that it both diagnoses and invalidates.

When you can’t get a re-fetch

Change the URL. A URL the platform has never seen has no cache entry. Adding a query parameter is enough. Costs: you now have two URLs for one page, and if you share the parameterised one it’s what gets shared onward. Fine for a quick fix, poor as a habit.

Wait. Caches expire. Durations are long and not reliably documented, so this is only an option when nothing about the link is urgent.

Set sensible cache headers on the page. Some crawlers honour them. Won’t retroactively clear anything already stored, and helps future re-fetches happen sooner.

Making images cheap to change

Treat preview images as immutable files. To change one, publish a new one:

<!-- was -->
<meta property="og:image" content="https://example.com/og/article-v1.png">
<!-- now -->
<meta property="og:image" content="https://example.com/og/article-v2.png">

Or include a content hash in the filename, the way build tools already do for CSS and JavaScript. Then “the image changed” and “the URL changed” are automatically the same event, and image caching stops being something you think about.

This is the single habit that makes preview updates painless, and it’s worth adopting before you need it.

Every one of these workarounds exists because a wrong card got cached. The cheapest approach is not creating one:

Check tags before publishing. curl the page, confirm the four tags are present in the raw HTML, confirm the image URL is absolute and returns 200.

Run the debug tool on the new URL before announcing it. The first fetch populates the cache with a correct card, and there’s nothing to fix.

Verify on a staging URL where the tags are identical in structure. Catches template errors — a missing property attribute, an unresolved variable — without burning the real URL’s first impression.

Thirty seconds before publishing versus a per-platform cleanup afterwards. And on a platform where you can’t get a re-fetch, the cleanup may simply not be available.

What to expect after a successful re-scrape

Some patience is warranted. A re-scrape updates what the platform holds; it doesn’t necessarily update every rendered copy immediately. Posts already published may keep their old card, because the card was attached to the post at creation. New shares get the new one.

So: fixing your tags fixes future shares. It doesn’t retroactively fix a post from last week. If that post matters, the answer is usually to repost it rather than to keep re-scraping.