Fixing Open Graph Images That Don't Update on Facebook, LinkedIn, and Twitter After a Deploy
The og:image meta tag is updated, the new image loads fine in a browser, and view-source confirms the correct URL — but a link shared on Facebook or LinkedIn still shows last month's preview image. The page isn't wrong; the social platform is showing you its own cached snapshot, not what's actually on the page right now.
The Problem
A page's og:image meta tag is updated to point at a new image, the change is confirmed live in the page's HTML source, and loading the image URL directly in a browser shows the correct picture. Yet sharing that same URL on Facebook, LinkedIn, or Twitter/X still renders the old preview image, sometimes for days, regardless of how many times the link is re-shared or how many browser caches are cleared on the testing device.
Why It Happens
Social platforms scrape and cache Open Graph metadata per URL, not per page load
The first time a URL is shared on a platform, that platform's crawler visits the page once, reads the Open Graph tags, and stores a snapshot — title, description, and image — keyed to that exact URL. Every subsequent share of the same URL, by any user, reuses that cached snapshot instead of re-fetching the page, because re-scraping on every single share would be wasteful at platform scale. The live page having changed is irrelevant to a cache that was never told to invalidate.
The image URL itself didn't change, only its content did
If a new image was uploaded to overwrite the exact same file path (/images/og-cover.jpg replaced in place, rather than /images/og-cover-v2.jpg), even a platform that does re-scrape the page's HTML may still serve a browser- or CDN-cached copy of the image bytes at that unchanged URL, because standard HTTP caching has no way to know the file at that URL is now different content.
The platform's scraper never gets a genuine reason to revisit
Unlike a search engine, which recrawls pages on its own schedule, most social platforms only refresh Open Graph metadata when explicitly told to — either through a user manually forcing a re-scrape via the platform's own debugging tool, or occasionally after a long enough time interval. Without one of those triggers, a stale cached snapshot can persist indefinitely.
The Fix
1. Version the image URL itself whenever its content changes, not just the page's metadata
<!-- Instead of reusing the same path: -->
<meta property="og:image" content="https://corejsc.com/images/og-cover.jpg" />
<!-- Add a version or content hash to the filename or query string: -->
<meta property="og:image" content="https://corejsc.com/images/og-cover-v2.jpg" />
<!-- or -->
<meta property="og:image" content="https://corejsc.com/images/og-cover.jpg?v=2026-08-07" />
A genuinely new URL guarantees no cache — social platform, CDN, or browser — has a stale copy associated with it, since caching is keyed to the URL itself. This is the single most reliable fix, and it prevents the problem from recurring on future updates too.
2. Use each platform's official debugging tool to force an immediate re-scrape
Facebook's Sharing Debugger, LinkedIn's Post Inspector, and Twitter/X's Card Validator all exist specifically to let a URL owner trigger an on-demand re-fetch of a page's Open Graph tags, bypassing the platform's normal cache lifetime. This is the fastest way to fix an already-shared, already-stale link without waiting for the cache to expire naturally.
3. Confirm the image URL is absolute, publicly accessible, and correctly typed
<meta property="og:image" content="https://corejsc.com/images/og-cover.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:type" content="image/jpeg" />
A relative URL, an image behind authentication, or a URL that returns the wrong Content-Type can cause a platform's scraper to silently fail and fall back to a previously cached image or no image at all — a failure mode that looks identical to a stale cache from the outside, but requires fixing the URL itself rather than forcing a re-scrape.
4. Avoid re-triggering a debugger tool repeatedly without changing anything
Forcing a re-scrape against an unchanged image URL just re-confirms the same cached result — the fix has to actually change what the scraper sees (a new URL, corrected tags) before a forced re-scrape has anything new to pick up.
Why This Works
Every fix here targets the same root cause: a social platform's Open Graph cache is keyed to a URL and only invalidated on an explicit trigger, never automatically synced to what the live page currently shows. Versioning the image URL guarantees a fresh cache entry by construction; a platform's debugging tool provides the explicit trigger a stale cache is otherwise missing; and correcting the tag's technical details (absolute URL, correct MIME type, public accessibility) ensures the scraper actually succeeds when it does run, rather than silently falling back to nothing.
Conclusion
A stale Open Graph image on social platforms is a caching problem, not a bug in the page itself — the platform is faithfully serving a snapshot it took once and was never told to refresh. Version the image URL whenever its content changes so a fresh cache entry is guaranteed, use each platform's official debugging tool to force an immediate re-scrape of an already-shared link, and confirm the image URL is absolute, publicly accessible, and correctly typed so the scraper doesn't silently fail.
