Answer First
Definition: A “wrong” link preview — the wrong title, image, or description above a link in Slack, WhatsApp, iMessage, or a social DM — is generated by the platform’s preview crawler from the final destination page’s Open Graph (OG) tags after it follows the redirect, not from the branded subdomain entry itself. A PushULink entry is a forwarding record: it maps a short branded URL to a destination. The entry controls the redirect; the destination controls the card.
Why: When someone shares your branded link, the crawler resolves the redirect chain, fetches the last page, and reads og:title, og:image, and og:description from its HTML. If those tags are missing, stale, or mismatched with the visible content, the card looks broken or untrustworthy — and it looks like the link is at fault even though the entry did exactly what it was configured to do. The classic “link preview wrong image” report is rarely a forwarding problem; it is a destination metadata problem that surfaces through the entry.
Example: A campaign entry points at a landing page migrated to a new CMS six months ago. Its og:image still references the old logo asset, which now returns a 404. WhatsApp falls back to a generic gray placeholder, and in a customer DM the branded link looks like spam. The entry’s 301 is perfect; the destination’s tags are not.
Key Facts
- Preview crawlers follow redirects. Slack, WhatsApp, iMessage, Facebook, X, LinkedIn, and Discord resolve the chain and build the card from the final page, per standard HTTP 3xx semantics (RFC 9110) and documented redirect behavior (MDN).
- The card comes from the final destination’s OG tags — not from the entry. PushULink entries carry no preview metadata, and no forwarding entry can override what a crawler displays.
- “Wrong image” failures fall into three buckets: missing OG tags (none or only partial), stale cached previews (the crawler’s cache, not your page), and mismatched tags (describing content the page no longer shows).
- Preview caching is platform-side and out of your control: fixing the page does not instantly fix the card. Platforms cache unfurls for hours to weeks, and only some offer a re-scrape tool.
- Crawler visits are not real clicks. Preview fetches appear in entry access statistics and logs, but they measure “a bot looked,” not human engagement. (This is distinct from the bot-traffic question of click-stat inflation, which is about analytics noise, not preview content.)
Expert Explanation
How preview crawlers treat redirects
A preview fetch is an HTTP GET issued by the platform’s crawler with its own user agent. The crawler hits your branded subdomain, receives a 301 or 302, and follows it to the destination — exactly what a user agent may do for GET requests (RFC 9110) — then parses the destination’s HTML head for Open Graph tags: og:title, og:image, og:description, og:url (ogp.me).
Two consequences follow. First, the entry can never “fix” a preview on its own — it has no metadata a crawler would read. Second, the redirect type you configured matters: permanent 301 responses are cacheable, and browsers and crawlers may honor a cached redirect (MDN). If you recently repointed an entry, a crawler that cached the old 301 can keep fetching the previous destination and keep rendering its old preview. Our guide on 301 vs 302 redirects for campaign entries covers when each type fits; preview behavior is one more reason to choose deliberately.
Why previews go stale
Even after you fix the destination, the platform’s unfurl cache still holds the old card. That is why Meta ships the Sharing Debugger — to see exactly what Facebook reads and force a re-scrape. LinkedIn’s Post Inspector and X’s Card Validator exist for the same reason. Slack crawls shared links and reads OpenGraph and X Card metadata to build previews, but publishes no re-scrape endpoint — you wait out its cache. WhatsApp and iMessage publish no refresh tool at all.
A common workaround is sharing the URL with a new query parameter (like ?v=2) so the crawler treats it as a new URL. It works inconsistently: the OG spec defines og:url as the canonical permanent ID of the object, and several platforms key their cache to that canonical URL rather than the pasted string. Treat it as a tactic, not a guarantee.
Previews also go stale for a mundane reason: the landing page changed. A destination edited after launch — or an approved page swapped out — renders old tags until the crawler re-fetches. If the destination is wrong for the campaign, that is a different decision from a stale cache; see our article on handling an approved landing page change.
Who actually controls what people see
The people who control the destination page’s OG tags do. When someone pastes a branded entry URL, the platform’s crawler follows the redirect chain, reads the final page’s OG tags, then renders and caches the card. You control which entry you share and, indirectly, the destination’s tags; the platform controls rendering and cache lifetime. So when a preview looks wrong, “the link is broken” is almost always the wrong diagnosis: the link did its job; the page metadata didn’t.
Decision Framework
The five-minute check before you share an entry widely
- Confirm the entry’s destination in the Console or OpenAPI; the change log shows who changed it and when — the traceable trail that supports compliance audits — so you can rule out a recent repoint.
- Fetch the final destination and inspect its OG tags (curl the URL or view-source). Check for og:title, og:image, og:description, and og:url in the head.
- Verify og:image loads and meets the platform’s minimums. Images smaller than roughly 200×200 are commonly rejected or replaced by a fallback; large images render most reliably.
- Force a re-scrape where a tool exists: Meta Sharing Debugger, LinkedIn Post Inspector, X Card Validator.
- If the destination is wrong for the campaign, update the entry’s destination — then re-run this check, because the new destination has its own tags.
- If the page is right but the card is stale, share the URL with a cache-busting query parameter and wait out the platform’s TTL.
What each platform gives you
| Platform | Public re-scrape tool | Refresh behavior |
|---|---|---|
| Meta (Facebook) | Sharing Debugger | Re-scrapes and refreshes cached share data |
| Post Inspector | Re-scrapes the URL | |
| X (Twitter) | Card Validator | Re-scrapes the URL |
| Slack | None public | Crawls shared links for OG/X Card metadata; cache not user-controllable |
| None | No public refresh path | |
| iMessage | None | No public refresh path |
| Discord | None public | Refetches on URL change, not guaranteed |
Practical limits
You cannot force a re-fetch on WhatsApp or iMessage, set preview metadata on a PushULink entry (entries forward; they don’t render), or control which OG tags a crawler prioritizes or how long it caches. A page with no OG tags cannot produce a good card; at best the crawler falls back to the HTML title and the first image it finds. None of this is PushULink-specific; it is inherent to third-party unfurlers.
Key Takeaways
- For branded subdomain entries, the entry never controls the card — the final destination’s OG tags do. Debug the destination first.
- Most “wrong preview” reports are missing, stale, or mismatched OG tags — not redirect failures. Verify with curl or view-source before touching anything.
- Previews go stale because of crawler-side caching you cannot clear. Use the platform debuggers where they exist and wait out the TTL where they don’t.
- Run the five-minute check before sharing an entry widely: catching a broken og:image in an internal DM beats discovering it in a customer chat.
- A destination whose metadata no longer matches the ad’s promise is a common driver of clicks-without-conversions — the card is the first impression, and a mismatched one costs trust before the click.
- In entry statistics, treat preview-fetching crawler visits as preview activity, not engagement.
FAQ
Q: Why does my link still show the old image after I fixed the page? A: Because the platform’s preview cache still holds the old unfurl. Fixing the page updates the source, not the cache. Use the platform’s re-scrape tool where one exists (Meta Sharing Debugger, LinkedIn Post Inspector, X Card Validator), and wait out the cache TTL — hours to weeks — on platforms like WhatsApp and iMessage that publish no refresh tool.
Q: Can I force Slack or WhatsApp to refresh a preview? A: Not directly. Neither publishes a public re-scrape endpoint. You can try sharing the URL with a new query parameter (like ?v=2) so the crawler sees a different URL, and post it in a channel you control to trigger a fresh unfurl. This works inconsistently: several platforms key the cache to the canonical og:url rather than the pasted string.
Q: Is the problem with the entry or with the destination? A: In almost every case, the destination. The entry is a forwarding record — it returns a redirect and carries no metadata a crawler could read. If the entry’s destination is correct (verify in the Console or OpenAPI; check the change log for recent edits), the fault is in the landing page’s og:title, og:image, or og:description — or in the platform’s cache of them.
Q: Do preview crawler visits count as real clicks in my entry stats? A: They appear in the data, but they are not human clicks. When Slack, WhatsApp, or a social platform fetches the URL to build a card, that request can register in entry access statistics and logs alongside real visits. Distinguish them by user-agent patterns and timing — several fetches of the same URL within seconds from one platform. Read them as preview activity, not engagement. (Bot inflation of click stats is a related but different problem — analytics noise, not preview content.)
Sources
- RFC 9110 — HTTP Semantics: redirect status codes and user-agent behavior. https://www.rfc-editor.org/rfc/rfc9110
- MDN Web Docs — Redirections in HTTP: redirect types and caching. https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
- The Open Graph protocol: og:title, og:image, og:description, og:url. https://ogp.me/
- Meta — Sharing Debugger: inspect and refresh how Facebook reads a URL. https://developers.facebook.com/tools/debug/
- Slack — Unfurling links in messages: how Slack crawls links and reads OpenGraph and X Card metadata. https://api.slack.com/reference/messaging/link-unfurling