skip to content

You deploy corrected Open Graph tags for an article, but pasting its link into Slack and Facebook still shows the old title and image. What explains that, and how do you get the platforms to pick up the new card?

level: seniorimportance: should knowfreq 42%

answer

  1. their record, not your page
  2. two caches: metadata and image bytes
  3. prove the deploy before blaming the platform
  4. new bytes deserve a new URL
  5. not every surface has a public tool

basics

~20 s

Platforms cache scraped metadata per URL, so a corrected tag does not take effect until they re-scrape. Force it with the platform's own tool where one exists, such as Facebook's Sharing Debugger, and change the og:image URL when the image itself changed.

solid answer

~50 s

Every platform stores what it scraped, keyed by URL, so your deploy does not invalidate anything on their side — the card you see is a cached record, not a fresh read of your page. Three moves fix it. First, use the platform's own re-scrape tool where one is offered: Facebook's Sharing Debugger has a "Scrape Again" action and shows exactly what it parsed, and LinkedIn's Post Inspector does the same. Second, when the image content changed but its URL did not, publish it under a new URL — a fingerprinted filename or a version query string — because the old URL is cached by both the platform and its CDN. Third, accept that some surfaces have no public re-scrape tool; X retired its Card Validator, so you verify there by composing a post with the link. Before blaming caching at all, curl the URL and confirm the corrected tags really are in the response.

go deeper

for a junior

Know that platforms store the metadata they scraped per URL, so a new deploy does not automatically change an existing link preview.

for a middle

Explain the two independent caches — the parsed metadata and the copied image bytes — and why a new image needs a new URL rather than an in-place overwrite.

for a senior

An interviewer expects an ordered diagnosis: verify the served HTML first, then use the platform's re-scrape tool, then treat a URL variant as a diagnostic rather than a fix.

for a principal

Own the prevention: fingerprinted card assets, canonical stable URLs, and a pre-publish card check so the expensive first scrape is never the wrong one.

## Why the old card persists A link-preview platform does not re-fetch your page every time someone shares it — that would be a denial-of-service on the web. It scrapes once, stores the result keyed by the URL, and serves that stored record to every subsequent share until its own expiry rules say otherwise. So after you deploy new tags there are two versions of the truth: your HTML, which is now correct, and the platform's record, which is not. Nothing you do on your server invalidates theirs. There is a second cache underneath, for the image itself. Platforms typically copy the card image onto their own CDN when they first scrape it. If you overwrite `card.png` in place, the platform may keep serving the old bytes even after it re-reads your metadata, because as far as it is concerned the image URL has not changed. ## Confirm the page first Before reaching for any platform tool, prove the fix actually shipped: ```bash curl -sL https://example.com/blog/post-42 | grep -i -E 'og:(title|image)' ``` It is common to spend an hour fighting a "cache problem" that is really a build that never deployed, a CDN still serving the previous HTML, or a second `og:title` earlier in the head that wins over the corrected one. Rule the page out before you blame the platform. ## Forcing a re-scrape - **Facebook's Sharing Debugger** takes a URL, shows the properties it parsed, lists warnings, and offers a "Scrape Again" action that replaces the cached record immediately. It is also the best diagnostic on the list because it prints what it saw rather than only what it rendered. - **LinkedIn's Post Inspector** works the same way for LinkedIn previews. - **X** removed its public Card Validator, so there is no self-service re-scrape; you check by putting the link in the composer and looking at the preview it generates. - **Slack** caches unfurls per URL for a period and offers no public invalidation tool. In practice you wait it out, or test with a URL variant. The universal fallback, when no tool exists, is to change the URL: appending a throwaway query parameter produces a URL the platform has never seen and therefore must scrape fresh. That is a **diagnostic**, not a fix — it proves the new tags are being read, but the canonical URL still carries the stale record, and you should not ship links with cache-busting junk on them. ## Changing the image When the card art itself changed, treat it like any other immutable asset: publish it at a new URL. `card-v2.png`, or a content-fingerprinted filename, or `card.png?v=2026-08` — any of these give the platform a URL it has not stored, so the re-scrape pulls the new bytes. Overwriting the file in place and hoping is the single most common reason an image stays stale after a successful metadata re-scrape. ## Design so this hurts less - **Fingerprint card images at build time**, the same way you fingerprint any static asset. Then a changed image is always a changed URL and the whole problem disappears. - **Keep `og:url` stable and canonical.** If your URLs drift — trailing slash one week, tracking parameters the next — the platform sees new objects rather than an updated one, and share counts and cached cards fragment across variants. - **Get the tags right before the link is first shared.** The expensive case is a launch announcement shared thousands of times off a broken card; the cheap case is a page nobody has shared yet, where there is no cache to fight. - **Check the card as part of shipping a page**, not after complaints. A pre-launch pass through the Sharing Debugger costs a minute. ## What not to do Do not set cache headers on the HTML and expect them to control platform metadata caches — the platforms apply their own retention policy and are not obliged to honour yours. Do not sniff scraper user agents to serve them something special; it is fragile and it makes the served card diverge from the page. And do not re-point the article at a brand-new URL purely to escape a stale preview: you lose the accumulated identity of the old address for a cosmetic gain that a re-scrape would have delivered.

  • Appending ?x=1 to the URL shows the correct new card. What have you actually learned?
    That your page now serves the corrected tags and the platform can read them — the query string simply produced a URL with no cached record. It is a diagnostic that isolates the problem to the platform's cache rather than your markup. The canonical URL still holds the stale record, so you still need a re-scrape, and you should not distribute the cache-busted link.
  • You re-scraped successfully and the title updated, but the image is still the old one. Why?
    Because the metadata cache and the image cache are separate. The platform re-read your head and found the same `og:image` URL it already had, so it kept serving the copy on its own CDN. Publish the new art at a new URL — a fingerprinted filename or a version parameter — and re-scrape again.
  • How would you stop stale-card incidents from recurring across a large site?
    Make card images content-fingerprinted build artifacts so a changed image is always a changed URL, keep og:url canonical and stable so platforms track one object per page, and add a pre-publish check that renders the card metadata for a new page before its first share. The cache is only painful when the first scrape was wrong.

saying these in an interview costs you the question

  • Assumes deploying new HTML invalidates the platform's cache
  • Overwrites the image file in place and expects an update
  • Blames caching before checking what the URL actually serves
  • Ships permanent cache-busting query strings on public links
  • Changes the page URL to escape a stale preview

context

resolving links…