If your social share image isn't updating, the platform is almost always showing a cached copy, and you fix it by forcing a re-scrape (Facebook Sharing Debugger, LinkedIn Post Inspector) or by changing the og:image URL so it looks new. If a fresh scrape still shows the old image or none at all, the crawler probably can't reach your page or image.
Why is my old og:image still showing?
When someone shares a link, the platform's crawler fetches your page once, reads the Open Graph tags, grabs the image, and stores the result. Later shares reuse that stored copy. Facebook says it plainly: images are cached based on the URL and won't be updated unless the URL changes.
So if you replaced share.jpg with a new design but kept the same filename, the platform has no reason to fetch it again. Your page tags might be fresh while the image is weeks old.
There's a second catch. Refreshing the cache only affects new posts. LinkedIn's help docs say changes apply to new posts that include the URL. Posts already published keep the preview they had. That's true in practice on most platforms.
How do you fix a social share image that won't update?
Work through these steps in order. Most people are done by step 4.
- Check your tags in the raw HTML. Run
curl -s https://example.com/page | grep og:image. If the new URL isn't there, the problem is your site, not the platform. Tags added by client-side JavaScript usually aren't seen by crawlers. - Open the image URL directly. It should return a 200 status, not a redirect, a 403, or an HTML error page. Check the
Content-Typeis an image type. - Change the image URL. Rename the file (
share-v2.jpg) or add a version query string (share.jpg?v=2) and updateog:imageto match. This is the single most reliable fix. - Force a re-scrape on Facebook and LinkedIn with their tools (details below).
- Test X, Slack, and Discord by posting the link fresh, ideally with a query string on the page URL too.
- If there's still no image, check for crawler blocking, redirects, and file size. Those are covered further down.
How do you refresh the preview on each platform?
Facebook: Sharing Debugger
Paste your URL into the Facebook Sharing Debugger and click Scrape Again. It triggers a fresh crawl and shows you exactly what the crawler found, including warnings about missing tags or an image that's too small. If the image still looks stale after one scrape, click it once more. The first scrape of a new image URL sometimes comes back without the image while it's processed.
Setting og:image:width and og:image:height helps here. Facebook says those tags help the image load properly the first time it's shared.
LinkedIn: Post Inspector
Go to LinkedIn Post Inspector, enter the URL, and click Inspect. That fetches the page again and updates what new posts will show. LinkedIn doesn't publish an exact cache length in its help docs. You'll often see "about 7 days" quoted, but treat that as commonly reported, not official. Either way, Post Inspector skips the wait.
X: no validator preview anymore
X's Card Validator used to show a live preview and refresh the cache. X removed the preview feature around 2022, saying the previews didn't match how cards really displayed across apps. What's left is this: paste your link into the post composer and look at the card it builds. You don't have to publish the post.
If the composer still shows an old card, add a query string to the page URL (https://example.com/page?v=2). X treats that as a new URL and fetches it fresh. Make sure you've set twitter:card to summary_large_image if you want the big image.
Slack: caching and unfurls
Slack is the one that usually surprises people. Its link expanding bot (Slackbot-LinkExpanding) caches what it finds for about 30 minutes, according to Slack's own robots page. There's no button to clear it. Your options:
- Wait 30 minutes and post the link again.
- Post the link with a query string, like
?v=2. - Delete the old message. Its preview won't change on its own.
Slack also serves images through its own image proxy (Slack-ImgProxy), which caches separately. That's why a new image URL fixes things faster than a new page URL alone.
Discord
Discord doesn't publish a cache length or offer a refresh tool. It's commonly reported that Discord caches by exact URL, so the working fix is the same: add a query string to the page URL when you post it, and change the og:image URL when the image itself changed.
Does a cache-busting query string really work?
Yes, for the image. A cache-busting query string is a harmless parameter like ?v=2 that makes a URL look new to a cache while your server returns the same file. Because platforms key their caches on the full URL, share.jpg?v=2 is a different image to them than share.jpg.
<meta property="og:image" content="https://example.com/og/launch.jpg?v=3">A clean approach is to build the version from the file's hash or its last-modified date, so it changes only when the image does. Most build tools can do this for you. It's the same trick you'd use for clearing a stuck favicon, and it pairs well with long cache headers (more on that in our post on image caching and CDN headers).
For the page URL, a query string works to get a fresh preview, but don't put it in og:url. Facebook wants og:url to be the plain URL without extra parameters, so likes and shares count toward one page.
Could a firewall or robots.txt be blocking the crawler?
If a fresh scrape shows no image at all, this is the first thing to check. Each platform uses its own user agent:
| Platform | Crawler user agent contains | Refresh tool |
|---|---|---|
facebookexternalhit | Sharing Debugger | |
LinkedInBot | Post Inspector | |
| X | Twitterbot | None (composer preview) |
| Slack | Slackbot-LinkExpanding, Slack-ImgProxy | None (wait or new URL) |
| Discord | Discordbot | None (new URL) |
Common blockers:
- WAF and bot protection. Cloudflare bot fight modes, rate limits, and "block unknown bots" rules can serve a challenge page. A crawler can't solve a CAPTCHA, so it gets nothing. Allow these user agents or use your provider's verified-bot setting.
- robots.txt. A
Disallowon your image folder can stop some crawlers. Slack says it doesn't honor robots.txt at all, and Meta says its preview crawler may bypass it in some cases, so robots.txt alone won't explain every platform. Still, don't block/images/or/og/. - Hotlink protection. Rules that block image requests without your site as the referrer will block crawlers too.
- Login walls and geo-blocks. Staging sites behind basic auth never unfurl. Neither do pages blocked in the country the crawler runs from.
Your server logs are the fastest way to confirm. Search for the user agent and look at the status codes you sent back.
Can redirects break link previews?
They can. Crawlers follow some redirects, but chains of several hops, redirects to a login page, or loops will stop them. Keep both the page URL and the image URL to one redirect at most, ideally zero. Also watch for HTTP to HTTPS plus www to non-www stacking into two hops. If Facebook's debugger shows a different final URL than you expected, that's your clue.
Is my image too large?
Size limits are real. Facebook caps images at 8 MB and LinkedIn at 5 MB, and X has long listed 5 MB for card images. Slow servers matter too. Meta says its crawler expects content to load within seconds and that Open Graph tags must appear in the first 1 MB of the page. A 4 MB PNG from a slow origin can time out even though it's under every limit.
Aim for 1200×630 and well under 1 MB. Our Open Graph image size guide covers dimensions and formats, and the compression settings post shows how to shrink files without visible loss.
Common mistakes
- Overwriting the image at the same URL and expecting platforms to notice.
- Expecting old posts to update. Refreshing only helps new shares.
- Testing only in your browser. Your browser isn't blocked by your WAF. The crawler might be.
- Putting the cache-buster in og:url instead of the image URL.
- Relying on the old X Card Validator to show a preview. It doesn't anymore.
- Serving an SVG as
og:image. Most crawlers skip it.
For quick header and status checks on a live URL, our webmaster tools page has a few helpers.
If the preview image updates but the little site icon next to your link still looks wrong, that's your favicon, and it has its own caches. The favicon checker shows which icon files your page actually serves right now.
TL;DR
An old share image is a cache issue. Change the og:image URL (rename it or add ?v=2), then re-scrape with Facebook's Sharing Debugger and LinkedIn's Post Inspector, and repost with a fresh URL on X, Slack, and Discord. If there's no image even after a fresh scrape, look for a firewall blocking the crawler, redirect chains, or an image that's too big or too slow.