Why your link preview looks wrong on LinkedIn, Slack, X and WhatsApp

You changed the title, swapped the hero image, and the page looks right in your browser. Then you paste the URL into LinkedIn or Slack and the card still shows last week's headline, a cropped logo, or a blank box.

The page you see and the page the crawler sees are often not the same document. And even when they are, the platform may still be showing a card it fetched earlier.

What the crawler actually reads

When you open a page, your browser downloads the HTML, runs JavaScript, follows client-side routes, and paints the finished layout. LinkedIn, Slack, X, and WhatsApp do not do that. They request the URL, read the HTML they got back, look for a small set of meta tags, and leave.

That is why "View page source" matters more than the Elements panel in your developer tools. Source is the raw response. Elements includes tags your scripts added after load. If the tags are missing from the source, the crawler never saw them.

The tags each platform actually uses

Open Graph is the common language. LinkedIn's help for shareable websites says a page needs og:title, og:image, og:description, and og:url. WhatsApp's link preview docs look for the same four, and they want those tags in the <head>, not empty, with that head appearing in the first 300KB of the HTML.

X still reads its own Twitter Card tags. The one you should set yourself is twitter:card. Use summary_large_image when you want a wide image above the title. If twitter:title, twitter:description, or twitter:image are missing, X typically falls back to the matching Open Graph tags. Slack looks for Open Graph and Twitter Card tags, and for oEmbed when a page offers it.

A working set looks like this:

<meta property="og:title" content="The title you want on the card">
<meta property="og:description" content="One or two sentences that still make sense when cropped.">
<meta property="og:image" content="https://www.example.com/images/share-1200x630.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="A short description of the image">
<meta property="og:url" content="https://www.example.com/your-page">
<meta property="og:type" content="article">
<meta name="twitter:card" content="summary_large_image">

Two details that trip people up. og:url should be the canonical address of the page, with https, and without tracking or session query strings. WhatsApp is explicit that this URL should be undecorated. And og:image must be an absolute URL. A path such as /images/share.jpg is a classic reason the card has a title and no picture. Declare og:image:width and og:image:height to match the actual file. Changing only the tags does not resize the image.

The image is usually the part that breaks

There is no single canvas required by the Open Graph protocol. A 1200 × 630 landscape image is a practical starting point, which is the same recommendation in the Open Graph image sizes guide. Keep faces, product details, and short text away from the edges, because each destination crops and scales the file in its own way.

The official limits that matter most:

• LinkedIn wants a minimum of 1200 × 627 pixels, a recommended ratio of 1.91:1, and a file no larger than 5 MB. Images less than 401 pixels wide display as a thumbnail rather than a full-width card.
• WhatsApp wants an absolute image URL, a file under 600 KB, a width of at least 300 pixels, and an aspect ratio of 4:1 or less. A 1200 × 630 file is the right shape, but a heavy PNG can miss the 600 KB cap even when LinkedIn would accept it. Compress the file, then publish that smaller copy.
• A wide 1200 × 630 image also works as a large card on X. Do not assume every platform will show the entire frame.

If you replace the pixels at an existing image URL, caches will often keep serving the old file. Give the new image a new address, then update og:image to match.

Missing tags on a client-rendered page

If your site is a single-page app that writes meta tags in the browser, crawlers usually miss them. The tags need to be in the first HTML response, from the server or from a prerender step. This is one of the most common reasons a React or Vue site looks perfect to you and empty to LinkedIn.

Redirects that send the crawler somewhere else

A short hop from http to https, or from the bare domain to www, is usually fine if it settles quickly. Trouble starts when og:url points at a different address than the one people share, or when og:image itself redirects to a login page, an HTML page, or a cookie-signed URL.

Open the image URL in a private window. You should get a 200 response and an image content type, with no sign-in prompt. If you only see the image while you are logged into your CMS or CDN, the crawler will not see it either.

When crawlers are blocked

If the tags are right in view-source and the image loads for you, the crawler may still be blocked. Firewalls, hotlink protection, and bot products such as a Cloudflare WAF rule or Bot Fight Mode can allow browsers and still stop LinkedInBot, Twitterbot, facebookexternalhit, or WhatsApp. LinkedIn's help says this directly: if the image meets the requirements but still does not appear, the site may be blocking them, or the file may sit in a protected directory.

One Slack-specific nuance. Slack's robots page says Slackbot-LinkExpanding does not honor robots.txt. Allowing the bot there will not fix a Slack miss if a firewall or WAF is the real gate. Check your logs for the crawler user agent. For Slack, also watch for Slack-ImgProxy, which fetches the image separately from the page.

Why the card stays stale, and how to refresh it

You can fix the page and still see the old card. Each platform keeps its own cache.

LinkedIn. Paste the exact public URL into Post Inspector, inspect it, and confirm the new preview. LinkedIn's help is clear that this only affects new posts, messages, and articles. Existing posts that already used the URL keep the old preview.

Slack. Responses to Slackbot-LinkExpanding are cached globally for around 30 minutes for the same URL, which Slack documents on its robots page. During that window, posting the link again, even in another channel, can still show the old card. Waiting is the official behavior. For a faster check, append a harmless query string such as ?v=2 so Slack treats it as a new URL, or try Slack's Unfurl Debugger while signed in. Use the query-string trick for testing, not as the address you want people to share.

WhatsApp. There is no official cache-clear tool and no documented cache lifetime. The official way to verify a preview is to start composing a message with the link and wait, without sending it. WhatsApp says the preview should appear above the composer within about 10 seconds if the requirements are met. If an old card is stuck, the reliable workaround is a new URL variant. Previews in messages you already sent do not change.

X. The old Card Validator is gone. The practical check is to paste the link into a new post or reply and wait for the preview, without publishing it. If that preview is still stale after the live HTML has changed, test with a new URL variant. I have not seen a public, official "scrape again" button for X the way LinkedIn offers Post Inspector.

A practical order to debug

1. Open the public URL, view source, and confirm the tags are in the first HTML response.
2. Open the og:image address in a private window and confirm it is a public image.
3. Compare the declared width and height with the real file, and check the file size. For WhatsApp, stay under 600 KB.
4. Follow any redirects and confirm og:url matches the canonical page.
5. Look in server or CDN logs for the crawler user agent, not only for your own browser.
6. Then refresh the platform cache, or test with a unique URL if that platform has no inspector.

If you want a second look at the raw tags and an approximate card before you post, paste the public URL into Link Preview. For a list of pages, Metadata Packer can pull the tags and images into a spreadsheet. Neither tool can clear LinkedIn's or Slack's cache for you. After you publish, still inspect the link on the destination platform.

The usual fix is unglamorous: put the right tags in the first HTML response, point og:image at a public, absolute, correctly sized file, let the crawler through, and then ask the platform to fetch the page again.