Why Your og:image Is Not Showing in Slack, LinkedIn or X

When a page opens in your browser but its shared link has no image, check two separate requests: the page HTML and the image URL inside its metadata. A successful page response does not mean the image is public, and a successful image response does not mean it is the image you intended to share.

Start with the exact URL that failed. Scan the affected page to inspect its current metadata, then follow the matching branch below. A scanner shows what it can fetch now; the sharing platform may have an older copy or fetch the URL differently.

Choose the failing layer

1. Read the HTML response

Inspect the response from your server, not only the Elements panel after JavaScript has changed the page. This command follows redirects and saves both the headers and body:

1PAGE_URL='https://www.example.com/article'2curl -sS -L --max-redirs 5 -D page-headers.txt -o page.html "$PAGE_URL"3rg -n -i 'og:|twitter:|canonical' page.html

Replace the example URL with the failing public URL. Check the final status and destination in page-headers.txt. A login or challenge page can return HTML successfully while omitting the article's metadata.

A basic page might include:

1<meta property="og:type" content="article">2<meta property="og:title" content="A practical link preview example">3<meta property="og:description" content="A clear description of this article.">4<meta property="og:url" content="https://www.example.com/article">5<meta property="og:image" content="https://www.example.com/og/article.jpg">

The Open Graph specification defines the tag names and image properties. Titles and descriptions are text; og:url and og:image contain URLs. Use an absolute public HTTPS image URL to avoid ambiguity about its location.

If the tag appears only after JavaScript runs, correct the metadata rendering for the affected route. Framework behavior varies: test the actual response for the relevant client instead of assuming every bot receives the same HTML. See metadata and client-side rendering.

2. Fetch the image as a separate resource

Copy the exact image URL from the response, including its path. Fetch it without your browser's cookies:

1IMAGE_URL='https://www.example.com/og/article.jpg'2curl -sS -L --max-redirs 5 -D image-headers.txt -o image-response "$IMAGE_URL"3file image-response

Look for a successful final response, an image content type and actual image bytes. A 200 response containing an HTML login page is still the wrong result. HEAD can be useful for a quick header check, but GET also checks what the server sends as the body; servers can handle the methods differently.

Common causes include an asset behind authentication, an expired signed URL, a redirect to a missing file, or a security rule that treats the crawler differently. Check the specific rule and response before changing access controls.

A controlled example: page 200, image 403

We ran these cases through ShareScan's page validator using local HTML and controlled image responses. No social platform rendering was part of this test.

For the blocked-image case, the correction had two parts: make the intended asset public and point the tags to its public URL.

1<meta property="og:image" content="https://www.example.com/og/article.jpg">2<meta name="twitter:image" content="https://www.example.com/og/article.jpg">

Changing the tag alone would not help if the new URL still returned 403. After publishing the real fix, run the same check again against the same page. Then inspect a new share in the destination platform.

3. Check which image the source actually names

The last test case matters: a valid image can still be your homepage logo when you intended a product photo. A metadata validator cannot infer the editorial choice you meant to make.

Compare the resolved asset with the CMS field for that page. Check whether a global fallback replaces a missing page-level image, whether the URL identifies the right product or variant, and whether a theme and plugin both generate metadata.

Multiple og:image tags are not automatically an error. The protocol permits arrays, with ordering and structured image properties that must be interpreted together. Do not delete alternatives just to reduce the tag count. Inspect the full response and confirm the actual platform result.

For composition problems, use the image dimensions guide. For slow or heavy assets, use the file size and delivery guide. Those are different checks.

4. Separate current source from platform cache

If the current HTML names the intended, accessible image, stop changing tags at random. Confirm that you are comparing the same URL: a trailing slash, redirect, campaign parameter or alternate hostname can send a fetch to a different destination.

• LinkedIn: inspect the exact shared URL with Post Inspector. Use the LinkedIn walkthrough to compare source, inspector output and a new draft share.
• Slack: check message behavior and workspace settings as well as source metadata. Slack documents Range requests and caching around 30 minutes; it does not honor robots.txt. See Slack's crawler documentation and the Slack unfurl guide.
• X: compare the current card fields and image with the displayed card. Follow the X Card Validator guide for the field-by-field workflow.

A scanner refresh does not clear another platform's cache. A new image filename can identify a genuinely changed asset, but adding arbitrary parameters repeatedly makes the evidence harder to compare. Keep a record of the page URL, image URL, time and observed result. The stale-image guide covers that workflow in more detail.

When it works in a browser but fails for a crawler

A logged-in browser can hide an authentication requirement. Cached assets can hide a failed request. Client-side code can add tags that were absent from the response. Start by repeating the page and image requests without cookies, then compare relevant user agents and headers.

For a Slack-oriented diagnostic, you can request the first part of the HTML:

1curl -sS -L --max-redirs 5 \2  -A 'Slackbot-LinkExpanding 1.0 (+https://api.slack.com/robots)' \3  -H 'Range: bytes=0-32767' \4  -D bot-headers.txt -o bot-page.html "$PAGE_URL"

This compares one controlled request with the normal response. It does not reproduce Slack's network, prove that Slack made the request, or establish that 32 KB is Slack's exact fetch limit. Check your own access logs for the actual platform request when available.

Keep the fix from disappearing after the next release

Once the affected URL is corrected, check a small set of pages using the same template. A product page, article and campaign landing page can expose different metadata paths; ten copies of one template may miss the problem.

Run a free check of up to 10 pages. From the report, you can choose email follow-ups and confirm the subscription, or activate Slack monitoring. The first follow-up runs after about 24 hours, then weekly. Setup is voluntary.

For broader coverage or checks triggered by publishing, compare workspace monitoring. A verified workspace supports schedules, CMS webhooks and GitHub Actions; the Free plan covers up to 100 URLs within its monthly check quota. Choose larger coverage when your site's needs justify it.

For Next.js routes, check whether a child metadata object replaced the parent image. The runnable Next.js missing-image example reproduces that failure, corrects it and compares complete responses for three user agents.