You update your og:image and deploy. Facebook still shows the old thumbnail. Every major platform caches link preview data. They do not re-fetch your page on every share. Understanding why helps you fix stale previews faster.
Short answer
Social platforms cache Open Graph tags and images to keep shares fast and reduce load on your server. Cache duration varies by platform and URL. You cannot delete cache entries directly - you overwrite them by fixing tags and triggering a re-scrape through each platform's debugger tool.
What gets cached
When a URL is shared for the first time, the platform's crawler fetches your HTML and stores:
og:title(or fallback title)og:descriptionog:imageURL and the downloaded image file- Canonical URL and redirect path
- Response metadata (last fetch time)
This snapshot is served to every subsequent share of the same URL until a new crawl replaces it.
Your website does not control this cache. It lives on the platform's servers and CDN.
Why platforms cache previews
Speed
Generating a preview on every share would add 1-5 seconds per message. Cached previews appear instantly.
Server load
Popular URLs shared thousands of times would hammer your server if each share triggered a crawl. Caching protects your infrastructure.
Consistency
Everyone sharing the same link sees the same preview. Without cache, simultaneous shares during a crawl could show different images.
Cost
Running crawlers at scale is expensive. Caching reduces redundant fetches.
The tradeoff: your live site and social previews can be out of sync for hours or days.
How long does cache last?
There is no universal TTL. Platforms do not publish exact expiry times.
| Platform | Typical behavior | Refresh tool |
|---|---|---|
| Facebook / WhatsApp / Messenger | Days to weeks | Sharing Debugger |
| Days to weeks | Post Inspector | |
| X (Twitter) | Days | Card Validator |
| Slack | Hours to days | No official tool (re-share with query string) |
| Discord | Hours to days | No official tool |
| iMessage | Per-device, variable | No official tool |
High-traffic URLs may stay cached longer because platforms avoid re-crawling them frequently.
Per-platform cache isolation
Caches are not shared between platforms. Updating Facebook's cache does not update LinkedIn or X.
Your page update
├── Facebook cache (separate) → Sharing Debugger
├── LinkedIn cache (separate) → Post Inspector
├── X cache (separate) → Card Validator
├── Slack cache (separate) → no tool
└── iMessage cache (separate) → no tool
After an OG image change, run each platform's refresh tool or use OpenGraph Check to verify all platforms see the new tags.
What triggers a cache refresh
Manual re-scrape
The most reliable method. Each platform offers a debugger or inspector that forces a new crawl.
URL change
Platforms treat https://example.com/page and https://example.com/page?v=2 as different cache keys. Adding a query string creates a fresh preview. See Open Graph Cache Busting.
Image URL change
Changing og:image to a new filename or versioned URL forces a new image download even if the page URL stays the same.
Failed first scrape
If the first crawl failed (timeout, 403), a later successful scrape replaces the empty cache entry.
What does NOT trigger refresh
- Editing an existing social media post
- Changing tags without re-scraping
- Setting
og:updated_time(platforms ignore it for cache invalidation) - Waiting passively (no guaranteed auto-refresh)
Already-published posts keep old previews
Cache updates affect future shares only. A Facebook post from last week keeps its original preview even after you scrape today.
To show a new preview in an existing conversation:
- Share a cache-busted URL (
?v=2) - Create a new post with the refreshed URL
- Accept that old messages will not retroactively update
How to work with cache as a publisher
Version image filenames
Instead of overwriting og.jpg, publish og-v2.jpg and update og:image. Platforms fetch the new file immediately on re-scrape.
Test before sharing
Run URLs through platform debuggers and OpenGraph Check before campaigns go live. Fixing cache issues after a viral share is harder.
Document your OG deploy process
A simple checklist after each deploy:
- Verify tags in page source
- Scrape Facebook Sharing Debugger
- Refresh LinkedIn Post Inspector
- Validate X Card Validator
- Test one share per platform
Plan cache lag into launches
If you swap a campaign image at launch time, scrape all platforms 24 hours before go-live.
FAQ
Can I disable social preview caching?
No. Caching is built into how link previews work on every major platform.
Does a sitemap update clear social cache?
No. Sitemaps affect search engine indexing, not social preview caches.
Why does my dev site show correct previews but production does not?
Production URL was cached earlier with old or missing tags. Scrape the production URL specifically.
Do platforms cache 404 pages?
Yes. If a URL was shared while down, the error may be cached. Scrape again after the page is live.
Is cache the only reason previews are wrong?
No. Missing tags, blocked crawlers, and broken images cause wrong previews even without cache. Cache issues only apply when tags are correct on the live page but the preview shows old data.
How does this relate to CDN cache on my site?
Two separate layers: your CDN may cache HTML (fix by purging CDN), and the platform caches the extracted preview (fix by re-scraping). Both can cause stale data independently.
Bottom line
Social preview caching is intentional. Platforms store your OG data to make sharing fast and cheap. You overwrite stale cache by fixing live tags, versioning image URLs, and re-scraping per platform. Plan for cache lag, test before sharing, and do not expect old posts to update automatically.
