You fixed your og:image but Facebook still shows the old picture. Re-scraping did not help because the image URL never changed. Cache busting means altering the URL so platforms treat it as new content.
Short answer
Two reliable methods: add a version query to the image URL (og.jpg?v=2) or rename the file (og-v2.jpg). For page-level cache, share https://example.com/page?ref=launch instead of the bare URL. Always update og:image in your meta tags to match. Then re-scrape in the Facebook Sharing Debugger.
Two layers of caching
Stale previews involve two separate caches:
| Layer | What is cached | Fix |
|---|---|---|
| Platform cache (Facebook, LinkedIn) | Extracted OG tags and downloaded image | Re-scrape or cache-bust URL |
| Your CDN / server cache | HTML and image files | Purge CDN, rename file |
Cache busting addresses the platform layer. If your CDN still serves the old image file at the same URL, platforms will re-cache the old image even after a scrape.
Method 1: Version query string on image URL
Change:
<meta property="og:image" content="https://example.com/og.jpg">To:
<meta property="og:image" content="https://example.com/og.jpg?v=2">The ?v=2 makes platforms download the image again. Your server still serves og.jpg but the URL is technically different.
When query strings work well
- Quick fix after replacing an image file in place
- CMS that makes filename changes difficult
- Testing whether cache is the problem
When query strings cause problems
- Some analytics tools treat
?v=2as a separate page (splits traffic data) - Overly long or changing query strings on every deploy create many cache entries
- A few older crawlers strip query strings (rare today)
Increment the version on each image update: ?v=3, ?v=4.
Method 2: Rename the image file
Change:
https://example.com/images/og.jpg
To:
https://example.com/images/og-v2.jpg
Update og:image and twitter:image to the new path.
Why filenames are the better long-term approach
- Clean canonical URLs without query noise
- CDN cache invalidation is explicit (new file = new object)
- No analytics fragmentation
- Clear version history in your asset folder
Recommended pattern for production sites:
og-home-v1.jpg → og-home-v2.jpg → og-home-v3.jpg
Method 3: Page-level URL cache busting for shares
When the debugger shows correct data but a specific share still looks wrong, share a modified page URL:
https://example.com/blog/post?utm_campaign=linkedin
https://example.com/blog/post?share=2026-06
Platforms cache by full URL string. A new query creates a new cache entry.
Downsides of page-level busting
- Splits social proof across URL variants
og:urlshould still point to the canonical URL without query strings- Not a substitute for fixing
og:imageon the canonical page
Use page-level busting for one-off marketing posts, not as your default OG strategy.
What to update when cache busting
When you change an image URL, update all references:
<meta property="og:image" content="https://example.com/og-v2.jpg"><meta name="twitter:image" content="https://example.com/og-v2.jpg">Optional but helpful:
<meta property="og:image:width" content="1200"><meta property="og:image:height" content="630">Test with OpenGraph Check after updating.
Step-by-step cache bust workflow
- Replace the image file or update the URL with version
- Deploy and confirm new URL loads in browser
- Verify tag in page source
- Scrape in Facebook Sharing Debugger
- Refresh in LinkedIn Post Inspector
- Validate in Twitter Card Validator
- Share in a new post or chat to confirm
When cache busting is NOT needed
- First time a URL is shared (no cache exists yet)
- You only changed
og:titleorog:description(text updates often work with re-scrape alone) - Platform debugger already shows the new image after one scrape
When cache busting is required
- Same image URL, different file content on server
- CDN serves old image bytes despite HTML tag update
- Re-scrape shows correct URL but old thumbnail
- Image was broken on first scrape and you fixed it (fresh URL helps)
Cache busting per platform
| Platform | Image URL bust | Page URL bust | Re-scrape tool |
|---|---|---|---|
| Facebook / WhatsApp | Yes | Yes | Sharing Debugger |
| Yes | Yes | Post Inspector | |
| X (Twitter) | Yes | Yes | Card Validator |
| Slack | Yes | Yes | No tool (new message) |
| Discord | Yes | Yes | No tool |
| iMessage | Yes | Yes | No tool (new chat) |
Meta platforms share one cache. Busting on Facebook covers WhatsApp and Messenger.
Common mistakes
Busting the page URL but not og:image
The page URL changes but og:image still points to the cached old image. Update the image URL in meta tags.
Forgetting twitter:image
X may cache the broken twitter:image separately from og:image. Update both.
Using random query strings per user
?v=random on every request prevents stable caching entirely and is bad for performance. Use intentional version numbers.
Cache busting instead of fixing root cause
If the image returns 403 or tags are missing, no URL trick will help. Fix access and tags first.
FAQ
Does ?v=2 hurt SEO?
Not on the image URL itself. Avoid cache-busting query strings on your canonical page URL in og:url.
Can I use a timestamp as version?
Works technically (?t=1718123456) but makes URLs ugly and hard to track. Incremental integers are cleaner.
Should I cache bust on every deploy?
Only when OG images or titles change. Routine code deploys without social tag changes do not need it.
Does og:image:secure_url help with cache?
No. It does not invalidate cache. A new URL does.
Will clearing my CDN fix platform cache?
No. You need both: purge your CDN and re-scrape on each platform. See Why Social Platforms Cache Link Previews.
Is hash-based naming better than ?v=2?
Yes for production. Example: og-a8f3c2.jpg. Unique filename, no query string, clear cache break.
Bottom line
Cache busting fixes stale previews when the image file changed but the URL did not. Rename the file or add a version query to og:image, update all meta references, re-scrape per platform, and test a fresh share. Use filename versioning for production, query strings for quick fixes.
