A page can have a flawless og:image, og:title, and og:description — and still show an old preview when shared today, because the platform cached that page's Open Graph data the first time anyone shared it, possibly months or years ago, and has no automatic reason to check again
The previous articles on this site covered Open Graph basics, designing effective OG images, social-algorithm link suppression, and the Open Graph vs Twitter Card discrepancy. This article addresses Open Graph caching — why a page's current, correct Open Graph tags don't guarantee the preview shown when the page is shared reflects those current tags, and what to do about it.
Why platforms cache Open Graph data at all
Generating a link preview requires fetching the target page — retrieving its HTML, parsing out the Open Graph tags, and (for the image) fetching the image itself. Doing this every time anyone shares/views a link would mean: every share of a popular page triggers the platform to re-fetch that page — at scale (a popular page shared thousands of times), this represents significant, repeated load on both the platform's infrastructure and the target site's server.
Caching the result of the first fetch — storing "here's what og:title/og:description/og:image were, for this URL, as of when we last checked" — means subsequent shares of the same URL can use the cached data, without re-fetching — efficient for both the platform and the target site, but creates the "stale cache" issue: the cached data reflects a point in time, not the current state.
When this becomes a problem: updating content after it's been shared
If a page is shared before its Open Graph tags are finalized (e.g., a page goes live with a placeholder og:image, gets shared immediately by an early visitor, and later the og:image is updated to the intended, final image) — the early share's cached preview shows the placeholder image — and continues showing it, even after the page's actual og:image has been corrected — because the platform's cache, for that specific URL, was populated based on the placeholder, and hasn't been told "this has changed."
Anyone re-sharing the same URL (not a new URL, the same one) may still see the cached (placeholder) preview — new viewers of the already-shared link also see the cached version — the correct, current og:image is, effectively, invisible for that specific URL, via that platform, until the cache is invalidated.
"Debugger" / "scrape again" tools: manually forcing a cache refresh
Major platforms generally provide a tool — often called a "sharing debugger," "post inspector," or similar — that allows manually triggering a re-fetch of a specific URL's Open Graph data.
The general workflow:
- Enter the URL into the platform's debugger tool
- The tool displays the currently cached preview (title, description, image) — showing you what's currently being shown for that URL, on that platform
- Trigger a "scrape again" / "fetch new information" action — the platform re-fetches the page, re-parses its Open Graph tags, and updates its cache
- The tool then displays the newly-fetched preview — confirming the update took effect
This needs to be done per platform — each platform (Facebook, LinkedIn, and others that maintain their own link-preview caches) maintains an independent cache — updating Facebook's cached preview doesn't affect LinkedIn's separate cache for the same URL — each platform's respective debugger tool would need to be used, separately, to refresh that platform's cache.
Cache duration: how long does "stale" last?
Different platforms cache Open Graph data for different, generally undisclosed (or imprecisely-documented) durations — some caches may refresh automatically after some period (days to weeks, commonly discussed informally in various developer communities, though exact figures aren't consistently documented by platforms and may change over time) — but relying on "it'll eventually refresh on its own" means accepting an indeterminate period of stale previews — for content where the accuracy of the preview matters (a time-sensitive announcement, a corrected error) — manually triggering a refresh, via the debugger tool, is the reliable approach, rather than waiting for an uncertain automatic refresh.
URL-based "cache busting": a workaround for templated pages
For pages where Open Graph data is generated dynamically (e.g., a product page where og:image is the product's image, and the product's image gets updated) — a commonly-used workaround: append a query parameter to the image URL that changes whenever the underlying image changes — e.g., og:image value of https://example.com/images/product123.jpg?v=2 (incrementing v= each time the image is updated).
Why this helps: from the platform's caching perspective, product123.jpg?v=1 and product123.jpg?v=2 are different URLs — even though they might point to (versions of) "the same" underlying image, conceptually — the platform's cache, keyed by the page's URL and its referenced og:image URL, would treat a changed ?v= value as "a different image URL," and fetch it fresh — without requiring the page's own URL to change, and without requiring manual debugger-tool intervention for every update (though the page's og:image tag itself still needs to be updated to reference the new ?v= value — and, depending on the platform, the page's own cached entry might still need a refresh to pick up the new og:image tag value in the first place — this technique primarily helps with the image-fetch step once the platform does re-check the page, rather than eliminating the need for the page-level cache to be refreshed at all).
How to use the Open Graph Generator on sadiqbd.com
- Generate/update your Open Graph tags using this tool — ensuring
og:title,og:description,og:image, andog:urlreflect the current, intended preview content - If the page has been previously shared (or might have been — e.g., it's an existing page being updated, not a brand-new page): use each relevant platform's debugger/sharing-inspector tool to manually trigger a re-fetch, after publishing the updated tags — don't assume existing shared links will automatically reflect the update
- For dynamically-generated
og:imagevalues (product images, etc. that change over time): consider a versioning/cache-busting query parameter, updated whenever the underlying image changes — reducing (though not entirely eliminating) stale-image issues for future re-fetches
Frequently Asked Questions
If I'm about to share a brand-new page for the first time, do I need to worry about caching at all? Generally, no — caching becomes relevant specifically when a URL has been previously fetched by a platform, and is later shared again (or the same shared link is viewed again) after the page's Open Graph data has changed. For a genuinely new page, being shared for the first time — the platform's first fetch will reflect whatever the page's Open Graph tags currently are at that moment — there's no "stale cache" yet, for a URL that's never been fetched before. The caching consideration matters for subsequent updates to that same page, after it's already been shared at least once.
Is the Open Graph Generator free? Yes — completely free, no sign-up required.
Try the Open Graph Generator free at sadiqbd.com — generate Open Graph tags for accurate, attractive social media previews.
