OGKit

Why your Open Graph preview still shows the old image

· 7 min read

  • open-graph
  • cache
  • rescrape
  • social-preview

You updated the launch page at 11 p.m. New hero, new og:image URL, deploy green. At 9 a.m. ops pastes the same link into Slack and the card still shows last week's flash sale. Someone opens LinkedIn and the old crop is still there. Marketing asks the only question that matters: why is it still the old image?

The tags are fine. The image responds 200. Your browser is not the problem. Each platform keeps its own cache of what it scraped the last time it saw that URL — and almost none of them watch your deploy pipeline.

The cache model (three facts that explain most incidents)

  1. Scrape moment, not deploy moment. A platform stores title, description, image URL (and often a fetched copy of the image) when its crawler last hit the page. Your CDN invalidation does not notify Facebook.
  2. URL is usually the cache key. Same public URL → same cache entry. Changing only the bytes behind /og.png while leaving the path alone is the classic "I overwrote the file and nothing changed" trap.
  3. TTL is per platform, often undocumented. Some communities quote "~7 days" for LinkedIn or X; Meta's TTL is not a public SLA. Treat every number without a primary source as unverified and plan for forced refresh when humans will share today.

There is no official "clear the world's Open Graph cache" button. That is not a missing feature on your site — it is how closed unfurl systems work. Third-party multi-preview tools re-fetch for their own demo; they do not invalidate Meta, LinkedIn, or Telegram on your behalf.

Confusion Reality
"I fixed the meta, so previews should update" Only after each platform rescrapes (or its TTL expires)
"opengraph.xyz / metatags.io shows the new card" That is their fetch, not Facebook's cache
"CDN purged the image" Platforms may still hold the old scrape result keyed by page URL
"One debugger clears all apps" WhatsApp may ride Meta's path; Slack and Discord do not

Official tools — do this after a share-sensitive change

Run these with your login where required. Deep links that pre-fill a URL are convenience only; the scrape still happens inside the platform's tool.

Meta — Sharing Debugger

  1. Open the debugger (Facebook developer account).
  2. Paste the canonical public HTTPS URL of the page (match og:url / canonical).
  3. Inspect the scraped result; click Scrape Again so the cache drops the previous card.
  4. For many URLs at once, use the Batch Invalidator (one URL per line). WhatsApp often shares Meta's cache path, so this is the practical refresh for both when Meta is the owner.

LinkedIn — Post Inspector

  1. Open Post Inspector while logged into LinkedIn.
  2. Paste the public URL and run Inspect.
  3. Confirm the live scrape shows the new image and title.
  4. If a feed post still shows the old card, share again after the inspect — some clients keep the previous unfurl on an existing post.

Community sources often cite roughly a week of cache; mark that unverified for SLA purposes. When the campaign is live today, do not wait.

X — Card Validator

  1. Open the Card Validator (availability has varied over the years; the official entry may change — check X's current docs if the page is down).
  2. Paste the URL and preview the card.
  3. If the tool cannot force a clean refresh, change the public URL (or a cache-busting query the crawler treats as a new key) and post again.

TTL is often cited around seven days (community, not a fixed official number). Prefer re-validation after every creative change you care about in-timeline.

Telegram — @WebpageBot

  1. Open @WebpageBot in Telegram.
  2. Send the full public URL you updated.
  3. Wait until the bot shows the new preview, then share the link again in chats.

Slack, Discord, WhatsApp (no public one-shot debugger)

  • Slack / Discord: re-share the link in a test channel. Discord embeds sometimes stick until you change a query string or re-post. There is no official public "clear embed cache" console.
  • WhatsApp: no public debugger. Prefer Meta Batch Invalidator when Meta owns the scrape; otherwise wait or change the URL. Silent image drops are often image budget / fetch issues, not only cache — see the image-engineering post in this series when the debugger shows a good scrape but chat still fails.

Google (search snippet, not chat card)

If the pain is Search, not social: Rich Results Test and Search Console URL Inspection / request indexing. That path is orthogonal to Facebook's Sharing Debugger.

For a single public URL, OGKit's rescrape helper builds the primary debugger links and lists TTL guidance from the same platform profiles the product uses — it does not call those tools as you. One-click multi-platform rescrape inside a logged-in browser is the browser extension path.

Change the URL vs overwrite the same URL

Strategy When it helps Cost
Overwrite same og:image path Tiny text fixes; you will rescrape every major platform Easy to forget a platform; CDN + platform double-cache
New image URL (…/og-v2.png or content-hash) Campaign swaps, "must be new everywhere" Update meta + keep old object until rescrape finishes
New page URL Hard stuck caches, A/B landing renames Breaks old shares; use redirects carefully with consistent og:url
Query on the page URL Discord / stubborn clients that key on full URL Ugly; some crawlers normalize query strings — unverified per platform

Practical rule: for a launch asset change, new image URL + official rescrape on Meta and LinkedIn beats "overwrite and hope." Keep the HTML og:image absolute HTTPS and stable once the campaign is frozen.

Dynamic OG routes (opengraph-image, Satori templates) still produce a URL. If that URL is stable and only the rendered bytes change, you are back in the overwrite case — rescrape or version the image path.

Maintenance checklist (ops-friendly)

After any change to tags or share images on a URL people will paste today:

  • Confirm raw HTML has the new og:* (curl, not only DevTools after hydration)
  • Confirm the image URL returns 200 without auth, infinite redirects, or a tiny error GIF
  • Meta Sharing Debugger → Scrape Again (batch tool if many URLs)
  • LinkedIn Post Inspector → Inspect; re-share if a post is sticky
  • X Card Validator (or URL change + new post) if X traffic matters
  • Telegram @WebpageBot if Telegram previews matter
  • Spot-check Slack / Discord / WhatsApp with a fresh share, not an old message
  • Do not treat a third-party preview site as proof that Meta cleared its cache

Longer TTLs and field priority live in the platform profiles. Machine-readable tag correctness is separate: rules. Cache refresh does not fix missing meta, relative image URLs, or crawler blocks — start with why the card is blank if the debugger cannot scrape at all.

What OGKit will (and will not) claim

OGKit's website rescrape page orders official paths and explains TTL so you do not hunt seven bookmarks after a deploy. The browser extension can drive multi-platform rescrape with your session, still through visible official steps — not a hidden API that pretends to bypass platform login.

We will not claim a universal purge. Compliance copy stays the same as the product: user-triggered, visible steps, per-platform tools.

What to read next

  1. What Open Graph actually solves — full workflow map (tags → preview → rescrape → CI)
  2. Why your Open Graph card is blank — five failure modes before you blame cache
  3. Image engineering (later in the series) — bytes, redirects, and platform budgets when rescrape succeeds but the image still drops
  4. SPA / crawler and CI posts — when the first scrape was wrong and you need to prevent the next one

Try the official path on one URL

Paste the live page into the rescrape helper, open Meta and LinkedIn from the generated links, and scrape again. Then paste the same URL into the homepage scanner if you still need rule-level diagnosis. Old cards after a correct scrape are almost always "another platform's cache," not your meta being wrong twice.