Skip to content

SocialPart of: Link previews

Clear Facebook cache for a link: fix an old or missing preview

To clear the Facebook cache for a link, purge your own page cache, open the Sharing Debugger, paste the URL and click Scrape Again. How to refresh LinkedIn, X, Slack and WhatsApp, and fix a preview that is missing.

getReport teamUpdated 27 Sept 202613 min read

To clear Facebook's cache for a link, first purge your own page cache and CDN, then open Facebook's Sharing Debugger, paste the URL and click Scrape Again: Facebook fetches the page fresh and new shares use the new title and image. If the old image comes back, the problem is on your side: the page still serves the old tags, or Facebook cannot download the new image. This guide covers both, plus the refresh steps for LinkedIn, X, Slack and the messaging apps, which each cache differently. For how link previews work in general, start with our guide to Open Graph tags and link previews.

Quick answer

Where the link is sharedHow long it cachesHow to refresh
Facebook, MessengerUntil re-scraped (roughly every 30 days)Sharing Debugger → Scrape Again, or the Graph API for many URLs
LinkedInAbout 7 daysPost Inspector: inspecting the URL fetches it again
X (Twitter)About a weekNo purge tool since 2022; wait, or share a different URL
SlackIts own unfurl cacheNo purge tool; wait, or share a different URL
WhatsApp, iMessage, SignalBuilt on the sender's phone, stored in the messageSent messages never change; new messages fetch again
TelegramIts own cacheSend the URL to @WebpageBot
DiscordIts own cacheWait, or share a different URL

Before refreshing any of them: purge your own page cache and CDN, then confirm with the link preview checker that the page now serves the new tags and that the image can be fetched.

Why the old preview keeps showing

A popular link is shared thousands of times, and no platform wants to fetch your page for every share, so the first fetch wins. If Facebook read your page while it had a broken image, a staging title or no tags at all, that is what everyone sees until the cache expires or someone forces a refresh. When the image is out of date, the link advertises last season's sale; when it is missing, the card collapses to a line of text and gets far fewer taps.

How to clear the Facebook cache, step by step

  1. Purge your page cache and CDN for the URL (step 1 below).
  2. Open the Sharing Debugger in Meta for Developers and log in with any Facebook account.
  3. Paste the full URL, exactly as people share it, and click Debug.
  4. Click Scrape Again. The "Link preview" at the bottom shows what new shares will use; "When shared" and "Last scraped" confirm the fetch time.
  5. Read the warnings above the preview. "Could not download image", "Bad response code" or "The provided og:image properties are not yet available" mean the image is the problem, not the cache; go to steps 3 and 4 below.

When the card has no image or no preview at all, clearing the cache is not the fix. The Sharing Debugger's warnings name the cause; the common ones:

Debugger warning (wording varies)CauseFix
"Inferred property: og:image" or no imageThe page has no og:image, so Facebook guesses from the pageAdd og:image with an absolute https:// URL
"Could not download image"The image answers 403, 404 or a bot challengeAllow facebookexternalhit in the firewall; fix the URL
"Bad response code"The page itself is blocked, behind a login, or returns an error to the crawlerServe the page to facebookexternalhit with a 200
Image too smallImage under 200×200 px, Facebook's minimumUse 1200×630 px
"The provided og:image properties are not yet available"A new image still being processedAdd og:image:width and og:image:height

The same checklist explains an og image not showing on LinkedIn or X, since their crawlers fail for the same reasons.

How getReport checks it

The link preview checker fetches your page fresh and reads its Open Graph tags and Twitter card tags. It then downloads the og:image itself, follows any redirects, and reads the file's real type and pixel size instead of trusting the tag. That makes it the reference point: if the checker shows the new image and a platform shows the old one, the platform is caching. If the checker shows the old one too, the problem is on your side.

Social panel for a page with a small share image: warnings that the Open Graph image measures 600×315, below 1200×630, that og:url does not match the canonical URL and that the Twitter card type is missing, with six passed checks folded away
The image size and og:url findings are the two that most often explain a preview that will not update.

Two limits are worth knowing. getReport keeps a result for 12 hours per address, so after a change use Re-run rather than opening the old link. And the checker identifies itself as GetReportBot, not as facebookexternalhit, so a firewall rule that blocks only the social crawlers will not show up here; step 3 tests with their user agents.

Step by step

1. Purge your own caches first

A platform can only fetch what your site serves. If a page cache (a WordPress caching plugin, the host's cache, Varnish) still holds the old HTML, every refresh in the steps below re-reads the old og:image. Purge in this order: the page cache for that URL, then the CDN. Then check from outside:

Shell
curl -s https://example.com/winter-boots/ | grep -i -E 'og:image|og:url|og:title'

The output must show the new image address. If it does not, stop here: no platform refresh can help yet.

2. Give the new image a new filename

If you replaced share.jpg with a new file at the same address, the old bytes may still sit in the CDN and the platform's image cache, both keyed by that address. Upload the new image as share-2026-10.jpg (or let your build add a content hash) and point og:image at the new name. A new address has no cache anywhere.

3. Make sure the crawler can fetch the image

Most "cache" problems that survive a refresh are really fetch problems. The platform tried to download the new image, failed, and kept the old card or showed none. The usual causes:

  • The image is too large or the wrong type. Facebook accepts images up to 8 MB; keep share images at 1200×630 px and under 1 MB anyway. JPEG and PNG are the safe formats; if a platform shows no image for a WebP, try a JPEG.
  • A firewall or bot challenge. A WAF rule, a "bot fight" mode or a JavaScript challenge that does not exempt facebookexternalhit, LinkedInBot, Twitterbot and Slackbot blocks the crawler, which cannot solve a challenge page.
  • robots.txt. A Disallow: /wp-content/uploads/ or Disallow: /images/ line stops crawlers that respect robots.txt from fetching the file.
  • Hotlink protection. Rules that refuse images requested without your site as the referrer also refuse crawlers, which send no referrer.
  • Redirects. An og:image that answers with a redirect (http to https, a CDN rewrite) adds a step that can fail. Point the tag at the final address.

Test the image with each crawler's user agent. Anything other than 200 and an image/ content type needs fixing before you refresh:

Shell
for ua in facebookexternalhit/1.1 LinkedInBot/1.0 Twitterbot/1.0 Slackbot-LinkExpanding; do
  printf '%-28s ' "$ua"
  curl -s -o /dev/null -A "$ua" -w '%{http_code} %{content_type} %{size_download} bytes\n' \
    https://example.com/share/winter-boots-2026-10.jpg
done

4. Add the image dimensions

When Facebook meets an image it has not seen before, it processes it in the background, and the first share can render without it. Declaring the size lets it build the card immediately:

HTML
<meta property="og:image" content="https://example.com/share/winter-boots-2026-10.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Three pairs of winter boots on packed snow">

The sizes, crops and safe area for each platform are in Open Graph images: size and safe area.

5. Refresh each platform

Facebook and Messenger. Sharing Debugger → Scrape Again, as above. For many URLs (after a site-wide image change) the Graph API does the same in a loop. It needs an access token from a Facebook app you own; an app token is APP_ID|APP_SECRET:

Shell
# urls.txt: one URL per line. Run from a trusted machine; the token is a secret.
while read -r url; do
  curl -s -X POST "https://graph.facebook.com/" \
    --data-urlencode "id=$url" \
    --data "scrape=true" \
    --data-urlencode "access_token=$FB_APP_ID|$FB_APP_SECRET"
  echo
  sleep 1
done < urls.txt

LinkedIn. Paste the URL into the Post Inspector. Inspecting fetches the page again and updates the cache for future posts.

X. There is no refresh. The card validator lost its preview in 2022 and nothing replaced it. Wait about a week, or share a different URL (step 6).

Slack. No purge tool; removing an unfurl only hides it. Wait, or share a different URL.

WhatsApp, iMessage and Signal. The preview is built on the sender's phone when the message is written and travels inside the message. It never changes afterwards. The next message with the link fetches again, although the app may reuse a copy it fetched recently. How each app builds its card is in link previews in WhatsApp, Slack, LinkedIn and iMessage.

Telegram. Send the link to @WebpageBot; it fetches the page again and updates the preview Telegram shows.

Discord. No refresh command. Share a different URL or wait.

6. The URL-change trick, and where it fails

Adding a harmless parameter (?v=2) makes a URL the platform has never seen, so it fetches fresh. It works on X, Slack, Discord and the messaging apps. Keep two rules:

  • The page's og:url and canonical should still name the clean address. The parameter is for the share, not for your site.
  • On Facebook it does not work, by design. Facebook reads og:url, treats that address as the real object, and shows the card it has cached for the clean URL. Use Scrape Again on the clean URL instead. This is also why the og:url finding matters: when og:url and the canonical disagree, Facebook's card, like counts and cache all attach to whichever address og:url names. Keeping og:url and the canonical in sync covers the fix.

Platform notes

WordPress

Yoast SEO and Rank Math both set a per-post image on the post's Social tab, which overrides the featured image and the site-wide default. If the old image persists, check that tab first: a forgotten per-post image beats every new default. Then purge the caching plugin (WP Rocket, LiteSpeed Cache or the host's cache) before any platform refresh; they store the whole page, <head> included. Uploading a replacement with a media-replace plugin keeps the old filename, which is exactly what step 2 avoids.

Shopify

The share image comes from the product's or page's image, or the store-wide social sharing image. Shopify's CDN adds a version parameter to image URLs when a file changes, so only the platform caches need refreshing.

Static sites / custom

Generate share images with a content hash in the filename and set long cache headers on them; each new image gets a new address and the old one can stay cached forever. Generating OG images automatically covers the build step.

Verify

  • curl from outside shows the new og:image address, and the image answers 200 with an image/ type for all four crawler user agents.
  • The link preview checker, after Re-run, shows the image findings as passed with the new size, and og:url matching the canonical.
  • The Sharing Debugger preview and the LinkedIn Post Inspector show the new image; a new message in WhatsApp shows it too.

Common mistakes

  • Refreshing the platform before the site. Symptom: Scrape Again keeps fetching the old image. The page cache still serves the old <head>; purge it, then scrape.
  • Replacing the image at the same URL. Symptom: the tag is right, some platforms still show the old picture. Upload under a new filename.
  • Blocking the social crawlers in a WAF rule. Symptom: the preview is blank everywhere and the debugger reports a 403 or a challenge page. Allow facebookexternalhit, LinkedInBot, Twitterbot and Slackbot.
  • Using ?v=2 for Facebook. Symptom: the parameter changes nothing there. Facebook follows og:url to the cached clean URL; scrape that instead.
  • A per-post social image nobody remembers. Symptom: the site-wide default changed and one page kept the old image. Clear the post's Social tab image.

Questions people ask

Until something makes it fetch the page again. Facebook scrapes a URL the first time it is shared and, according to its sharing documentation, refreshes it roughly every 30 days after that. Scrape Again in the Sharing Debugger forces an immediate refresh, so after changing the title or image you do not have to wait for the cache to expire.

Can I change the preview of a Facebook post that is already published?

Usually not for shares that already happened. Scrape Again updates the cached card that new shares use, and some surfaces pick up the new card for existing posts, but many older shares keep the image they were published with. For an important campaign link, scrape the URL before anyone shares it, so the first card is the right one.

Why does adding ?v=2 not refresh the Facebook preview?

Because Facebook reads the page's og:url and treats that address as the real object. If og:url names the clean URL without the parameter, Facebook shows the card it has cached for the clean URL. Use Scrape Again on the clean URL instead. The parameter trick does work on X, Slack, Discord and the messaging apps.

You cannot force it. X removed the preview from its card validator in 2022 and offers no purge tool, so its cached card expires on its own after about a week. To show the new card sooner, share a URL X has not seen, for example with a harmless parameter, while og:url and the canonical keep naming the clean address.

Do I need a Facebook account to use the Sharing Debugger?

Yes. The Sharing Debugger is part of Meta for Developers and asks you to log in with a Facebook account, although it does not need an app or a Page. If you cannot log in, the free link preview checker shows the tags and measures the image, but only Facebook's own tool can clear Facebook's cache.

Check your site before and after Check