You corrected your Open Graph tags, re-shared the link, and the old preview appeared anyway. This is normal and expected. Every platform caches its scrape result — keyed by the exact URL — for hours or days, and re-sharing does not trigger a fresh fetch. The fix is to force a re-scrape through each platform's debugger. But before you do, spend two minutes confirming the tags are actually correct in the served HTML, because a stale cache and a broken tag produce an identical symptom.
Debugging in the wrong order wastes hours. Run this before touching any debugger:
curl -sL -A "facebookexternalhit/1.1" https://example.com/page \
| grep -iE '<meta[^>]+(og:|twitter:)'If your corrected tags are not in that output, the cache is not your problem — the tags are. Start with How to Fix a Link Preview Not Showing.
How Long Each Platform Caches
| Platform | Typical cache | Manual refresh |
|---|---|---|
| Up to 30 days | Sharing Debugger → Scrape Again | |
| ~7 days | Post Inspector | |
| X | ~7 days | No tool — cache expires on its own |
| Slack | ~30 minutes to hours | Usually unnecessary; expires quickly |
| Discord | Hours | No tool; expires on its own |
| Days | No tool; shares Facebook infrastructure | |
| iMessage | Per-device, persistent | No tool; varies by device |
Only Facebook and LinkedIn offer a genuine on-demand refresh. Everywhere else you either wait or use the URL trick further down.
Facebook — Sharing Debugger
The most capable of the tools, and the one you will use most. It also covers WhatsApp, which shares Facebook's scraping infrastructure.
- Open the Facebook Sharing Debugger (
developers.facebook.com/tools/debug/). - Paste the full URL, including
https://, and click Debug. - Click Scrape Again to force a fresh fetch.
- Check the "Time Scraped" timestamp updates and the preview redraws.
Two panels are worth reading rather than skipping. Warnings lists problems that did not stop the scrape but affect rendering — a missing og:image:width, an image below the size floor. Scraped URL shows the final URL after redirects, which is where you discover the scraper landed somewhere other than the page you meant.
example.com/page and www.example.com/page, or with a trailing slash, each variant has its own cache entry. Re-scrape whichever form people actually share, and ideally all of them.LinkedIn — Post Inspector
LinkedIn's cache is roughly a week and its Post Inspector clears it immediately.
- Open the Post Inspector (
linkedin.com/post-inspector/). - Paste the URL and click Inspect.
- The inspection itself forces a re-scrape — there is no separate button.
- Confirm the preview and the listed tags match what you expect.
LinkedIn is stricter than most about image dimensions and will silently fall back to a text-only card for images below its floor, so check the image panel rather than assuming the tag was read.
X — No Manual Refresh
The standalone Card Validator was retired, and there is no replacement that forces a re-scrape. Your options:
- Wait. X's cache is around seven days and expires on its own.
- Share a URL variant with a query parameter, which is a distinct cache key.
- Verify the markup directly, since a correct tag will render correctly once the cache turns over.
In practice X refreshes more readily than Facebook, so a corrected tag often appears on the next post regardless.
Slack and Discord
Both cache for a short enough period that waiting is usually the answer — Slack around thirty minutes, Discord a few hours. Neither exposes a refresh tool.
Slack unfurls per workspace and per channel, so a link already posted keeps its original card forever; the refreshed version appears on the next post. If you need to demonstrate a fix immediately, post the URL with a harmless query parameter.
The Cache-Busting Query Parameter
Because every platform keys its cache on the exact URL, adding a parameter creates a fresh entry that has never been scraped:
https://example.com/page <- cached, shows the old card
https://example.com/page?v=2 <- new cache key, scraped fresh
https://example.com/page?x=1 <- another fresh keyThis is genuinely useful for testing — it proves your tags are correct without waiting for a cache to expire. It is a poor fix for a link you intend to distribute:
- The parameter is visible in the shared URL and looks unpolished.
- Engagement counts attach to the parameterised URL, splitting them from the canonical one.
- The canonical URL stays stale, so anyone sharing the clean link still sees the old card.
og:url to the canonical address helps platforms consolidate engagement, but it does not merge the cache entries. The parameterised URL is still scraped and displayed separately. Use the parameter to test, then re-scrape the canonical URL properly.Image Caching Is Separate
Platforms fetch and cache the og:image file independently of the page. Changing the image at the same URL frequently leaves the old picture in place even after a successful page re-scrape.
The reliable fix is to change the image URL whenever the image changes, so there is nothing cached to serve:
<!-- Instead of overwriting og-card.png in place -->
<meta property="og:image" content="https://example.com/og/article-v2.png">
<!-- Or use a content hash, which changes automatically on rebuild -->
<meta property="og:image" content="https://example.com/og/article.a3f9c1.png">Content-hashed filenames are the durable answer — most build pipelines produce them already, and the problem stops recurring.
When Re-Scraping Will Not Help
If you have re-scraped and the preview is still wrong, the cache was never the issue. Work through these instead:
- Tags rendered client-side. Scrapers do not run JavaScript. If the tags appear in DevTools but not in
curloutput, no amount of re-scraping will help. - A relative
og:image. Scrapers do not resolve relative URLs — see Fix "og:image relative URL". - Duplicate tags. Two
og:titletags means the scraper picks unpredictably. Count them in the served HTML. - The crawler is blocked by
robots.txt, a WAF, Cloudflare bot protection, or an auth wall. - A redirect chain landing the scraper on a different page than you expect.
- A CDN serving a stale page. Purge your own cache before blaming the platform — a re-scrape that fetches a cached old page just re-caches the old values.
# Is your own CDN serving the update?
curl -sI https://example.com/page | grep -iE 'cf-cache-status|age|x-cache'
# Follow the redirect chain the scraper will follow
curl -sIL https://example.com/page | grep -iE '^HTTP|^location'A Workflow That Avoids the Problem
- Change the tags.
- Purge your own CDN or page cache.
- Verify with
curlthat the new values are served. - Re-scrape in the Facebook Sharing Debugger and the LinkedIn Post Inspector.
- Test with a
?v=2URL if you need to see the result on a platform with no refresh tool. - Share the canonical URL once the canonical entry is refreshed.
Doing step 3 before step 4 is the whole trick. Re-scraping a page whose new tags are not yet being served simply caches the old values again, which is why the same fix sometimes appears to fail twice before working.
Frequently Asked Questions
How long does Facebook cache a link preview?
Up to about 30 days, and re-sharing does not reset it. The Sharing Debugger's Scrape Again button is the only reliable way to force a fresh fetch.
Why does the preview still show the old image after re-scraping?
The image file is cached separately from the page. If you replaced the image at the same URL, the platform keeps serving the old file. Change the image URL — a version suffix or content hash — and re-scrape.
Is there still a Twitter Card Validator?
No, it was retired and has no replacement. X's cache expires on its own in roughly a week, and in practice it refreshes more readily than Facebook, so a corrected tag usually appears on the next post.
Does adding ?v=2 to the URL actually fix anything?
It bypasses the cache by creating a new key, which makes it excellent for testing. It does not fix the canonical URL, and engagement on the parameterised link is counted separately — so use it to verify, then re-scrape the real URL.
Can I clear the cache without the debugger tools?
Not on demand. Without a refresh tool your only options are waiting for expiry or changing the URL. This is why Facebook and LinkedIn's debuggers are worth using even when you are confident the tags are right.
Why does the same link preview differently on Slack and Facebook?
Different cache ages and different strictness. Slack re-scrapes within the hour and is forgiving about image size; Facebook caches for weeks and enforces minimum dimensions. A working Slack preview proves your tags exist, not that they satisfy Facebook.