CardScopeGuide
Clear Open Graph cache (refresh stale link previews)
You fixed the tags. View-source looks right. A checker shows the new title and image. Slack, LinkedIn, X, Discord, or Messages still show yesterday’s card — or no card at all. That is usually a client-side cache, not proof that the live HTML is still wrong.
CardScope fetches the URL and shows the tags it got right now. It does not clear Slack, X, LinkedIn, Discord, Facebook, or Apple caches. Use this page to separate “tags are wrong” from “a crawler already cached the old version,” then use the official rescrape tools where they exist.
Why the live page can be right and the card still wrong
Unfurlers do not re-read your HTML on every paste. They fetch once (or occasionally), store title, description, and image for that URL, and reuse that snapshot. Until the cache expires or you force a rescrape:
- View-source in your browser can show the new tags.
- CardScope can reconstruct a correct preview from a fresh fetch.
- A channel that already unfurled the permalink can keep showing the old card.
Treating “stale unfurl” as “broken tags” wastes time. Fix and verify the tags first; only then fight the cache.
Workflow: fix → verify → rescrape → re-share
- Fix the live tags. Absolute
https://og:image, stableog:url/ canonical, title and description that match the page. Client-specific notes: Slack vs Discord, LinkedIn vs X, iMessage. - Verify with CardScope. Paste the public permalink. Confirm the previews and tag table match what you expect. If CardScope is wrong, the live page is wrong — stop and fix the page before touching any debugger.
- Rescrape with official tools where they exist (below). Paste the same permalink; ask for a scrape / debug / inspect cycle.
- Where there is no public flusher (Slack, Discord, iMessage, and today’s X), re-share after a wait, use a fresh URL variant only when you accept a new cache key, or paste into a draft composer to see what the app will show next.
Official rescrape tools
| Client / surface | Public flusher? | What to do |
|---|---|---|
| Facebook / Meta (feeds that use the Sharing Debugger) | Yes | Open the Meta Sharing Debugger, paste the permalink, scrape, then “Scrape Again” until the debugger shows the new tags. |
| Yes | Open LinkedIn Post Inspector, inspect the URL, and confirm the preview matches CardScope before you post again. | |
| X (Twitter) | No reliable public tool | The old Card Validator at cards-dev.x.com/validator now redirects to login and is not a working public rescrape UI. Check tags with CardScope (or draft a post and read the composer preview). Cache often clears on its own; a new query string creates a new cache key — use that only when you are okay sharing a different URL. |
| Slack | No public clear | No official “clear this URL” page for workspace unfurls. Fix tags, verify in CardScope, wait or share again in a channel that has not unfurled that permalink yet. Admins sometimes see expand/unfurl controls in-product; those are not a global cache API. |
| Discord | No purge of the same URL | Discord documents a cache of about 30 minutes, and a new query string such as ?v=2 to see new tags immediately. The Embed Debugger shows which tags were read. It is not documented as a delete for the original URL. See Discord embed not showing. |
| iMessage / Apple Messages | No public clear | Apple does not publish a rich-link cache debugger. If CardScope’s iMessage preview is current but a phone still shows an old or empty link, treat it as Apple-side cache. Waiting, a new share, or a different device is the practical path — see iMessage link preview. |
| Bluesky | No rescrape of old posts | The ordinary card is stored in the post when it is composed. Fixing tags later does not update that post, and there is no Sharing Debugger for it. Compose a new post, or a draft, with the URL. See Bluesky link preview. |
| Mastodon | No public clear | Each server fetches the page itself and stores one card per URL. That server fetches again only when the URL is posted there and its stored card is two weeks old or has no image. A changed image needs a new URL. See Mastodon link preview. |
| No public clear | Reddit Help does not document a debugger that re-fetches a URL, or a cache lifetime. In the source archived on Nov 9, 2017, a link that already had a thumbnail was not scraped again unless the scrape was forced, and that force path is not a public tool. Confirm the live tags, then look at a new link post. See Reddit link preview. | |
| Threads | Partly | Threads Help does not document a cache tool. Meta documents the Sharing Debugger as the way to force a new crawl of a URL, and caches images by URL, so a new image needs a new URL. Meta does not say whether an existing Threads post updates. Scrape again, then check with a new post. See Threads link preview. |
What CardScope does and does not do
- Does: load the URL, read Open Graph and Twitter tags in memory, show reconstructed previews for X, LinkedIn, Slack, Discord, iMessage, Bluesky, Threads, Mastodon, WhatsApp, Telegram, and Microsoft Teams, and a fix checklist.
- Does not: call Meta, LinkedIn, X, Slack, Discord, or Apple to purge their caches. A green CardScope check means the currently fetched tags look right — not that every client has refreshed.
Link-card previews and the fix checklist are Pro: $19 once via Stripe Checkout. No account. We parse HTML in memory and discard it — we do not store the page.
Practical tips when there is no flusher
- Confirm CardScope first so you are not waiting on a cache for a page that is still broken.
- Prefer a stable permalink in
og:url/ canonical so you are not multiplying cache keys by accident. - If you must bust a stubborn cache, a deliberate
?v=2(or similar) is a new URL to crawlers — then update bookmarks and shares to that variant. - On X, draft the post and look at the in-composer card; that is the closest public preview path left after the validator retirement.
- On Slack/Discord, try a channel or DM that has never expanded that exact URL before testing “did it refresh?”