Why Do Social Platforms Ignore My og:image Tag?

An og:image tag is only one step in creating a link preview. The platform must fetch the page, recognize its metadata, retrieve the exact image URL, accept that image under its own rules, and use fresh enough preview data. A tag visible in your source does not prove the crawler received the same response or could fetch the image.

For LinkedIn, the documented checks include four Open Graph tags, image size and dimensions, public image access, and cached preview freshness. Those figures are LinkedIn-specific; other platforms may have different requirements. See LinkedIn’s shareable website guidance and URL sharing troubleshooting.

Diagnose the failure in order

Inspect the HTML response the crawler receives. Confirm that the page response contains og:title, og:image, og:description, and og:url. Inspect the exact URL being shared, including its path and query string. In a framework or CMS, do not assume metadata added only after client-side JavaScript runs will be available to every crawler; check the delivered HTML.
Copy the exact image URL from og:image. Open it directly and confirm it returns the intended image without a login, protected-directory rule, or other access restriction. LinkedIn explicitly identifies blocked retrieval and protected image locations as possible causes.
Compare the image with the affected platform’s current specifications. For LinkedIn, its published guidance says the image must be no more than 5 MB, at least 1200 × 627 pixels, and recommends a 1.91:1 ratio. These are LinkedIn requirements, not universal social preview limits.
Check whether the preview is stale. If the page or image changed recently, use the affected platform’s current official inspector or troubleshooting process if available. LinkedIn advises allowing 48 hours after the last share or tag update for cached content to refresh.
Check access controls if fetching still fails. Review firewall and bot rules, redirects, authentication, and response headers for the page and image. These are useful engineering checks, but the sources here do not establish how every social crawler interprets each control. Verify platform-specific behavior in its own documentation.

Check the metadata actually served

Use a command-line request to inspect the HTML returned for the shared URL. This does not emulate a social crawler, but it helps reveal whether the server response contains the expected tags.

curl -L --max-redirs 5 -sS https://example.com/article \
  -o /tmp/article.html

rg -i 'og:(title|image|description|url)' /tmp/article.html

Replace the example URL with the exact URL people share. Check the final destination after redirects as well as any canonical URL your page declares. Ensure the values are complete absolute URLs, especially for og:image and og:url.

A minimal set of tags looks like this:

<meta property="og:title" content="A useful article title">
<meta property="og:image" content="https://example.com/images/article-share.jpg">
<meta property="og:description" content="A concise description of the page.">
<meta property="og:url" content="https://example.com/article">

Put the tags in the document head and render the correct values for each page. Check the raw response rather than relying only on what your browser’s developer tools show after scripts have run.

Verify the image URL and file

Fetch the exact image destination independently. Review the response status, redirect chain, content type, and file size. Then inspect the actual pixel dimensions. A URL that opens in your authenticated browser may still be unavailable to an unauthenticated crawler.

curl -L --max-redirs 5 -sS -D /tmp/og-image-headers.txt \
  'https://example.com/images/article-share.jpg' \
  -o /tmp/og-image

cat /tmp/og-image-headers.txt
file /tmp/og-image

The file command can identify common image formats and dimensions on many systems. If it does not report dimensions, use an image viewer or image-inspection tool available in your environment. Check that the response is actually an image and not an HTML error page, a login screen, or a redirect to a page that requires a session.

For LinkedIn, the published image guidance specifies a maximum file size of 5 MB, minimum dimensions of 1200 × 627 pixels, and a recommended aspect ratio of 1.91:1. If a different platform is failing, look up that platform’s own current image requirements instead of applying LinkedIn’s numbers.

Distinguish an access problem from a cache problem

If the page HTML is correct and the image is publicly retrievable, the remaining issue may be preview freshness. Platforms can retain previously fetched metadata and images. LinkedIn’s troubleshooting guidance says to allow 48 hours after the last share or tag change for its cached content to refresh. That interval is LinkedIn-specific; do not assume another service uses the same schedule.

When an official platform inspector is available, submit the exact shared URL there and follow the diagnostics it returns. Recheck after correcting tags or access. If only one platform shows the wrong image, concentrate on that platform’s current rules and cache state rather than assuming the metadata is universally invalid.

LinkedIn’s published requirements

Check	LinkedIn guidance
Open Graph tags	`og:title`, `og:image`, `og:description`, and `og:url`
Maximum image file size	5 MB
Minimum image dimensions	1200 × 627 pixels
Recommended image ratio	1.91:1
Cache refresh after an update	Allow 48 hours after the last share or tag change

These values come from LinkedIn’s published help pages. They should not be presented as requirements for Meta, X, or every social platform. Google Search documentation about image previews or robots directives describes Google Search; it does not establish what social sharing crawlers do.

Common causes and fixes

Symptom	Likely cause	What to check or change
The tag appears in a template but not in the response	The wrong page variant was inspected, or metadata is added only after initial HTML delivery.	Fetch the exact shared URL and inspect its returned HTML. Render the page-specific tags in the response.
The preview has no image	The image URL is inaccessible, protected, redirects unexpectedly, or serves an error instead of an image.	Fetch the exact URL without browser credentials; check redirects, status, response type, and access rules.
The preview shows an old image	The platform is using cached preview data.	Use that platform’s official refresh or inspection process if available. For LinkedIn, its guidance says to allow 48 hours after the last share or tag update.
LinkedIn omits an image that loads for you	The image may exceed LinkedIn’s published size limit, be below its minimum dimensions, or be blocked from LinkedIn’s retrieval.	Check the 5 MB maximum, 1200 × 627 pixel minimum, recommended 1.91:1 ratio, and public accessibility.
Only one network gets the wrong result	Platforms may differ in requirements, fetch behavior, and cache state.	Use that network’s current official documentation and validator. Do not infer its rules from Google Search or LinkedIn.
The crawler appears to receive a different page	Redirects, routing, bot controls, or page variants may affect the response.	Inspect the URL and redirect destination, then review site access rules. Confirm behavior against the platform’s crawler documentation.

Or skip the browser setup

If you need to inspect the page’s rendered appearance while debugging, ScreenshotNeo is a website screenshot API and MCP server. One GET request returns an image or PDF; its screenshot can help you compare what a browser renders with the metadata and image URL you inspect separately. A screenshot does not prove that a social crawler can access an asset or explain the platform’s cache.

For a quick page capture, see the ScreenshotNeo API documentation:

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com/article \
  -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com/article"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com/article'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

ScreenshotNeo removes known cookie and consent banners, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers identify the page verdict and billing status. Its MCP server provides screenshot, page-info, and PDF-capture tools for AI agents. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.

Reliability and investigation notes

Keep a record of the exact page URL, final redirect destination, image URL, fetch time, and platform reporting the issue. This makes cache changes easier to distinguish from access changes.
After changing metadata or image access, re-fetch the page and image yourself, then use the platform’s official inspection route when available.
Do not use Google Search indexing controls as proof of social crawler behavior. Google’s robots and preview documentation is scoped to Google Search.
This evidence set verifies LinkedIn’s guidance. It does not verify current Meta or X image limits, crawler rules, or cache intervals, so check their official documentation before relying on platform-specific claims.

FAQ

Does a correct og:image guarantee that a preview will use it?

No. The crawler must receive the relevant page metadata and retrieve an acceptable image, and the platform may be showing cached preview data.

Google Search documentation describes Google’s own indexing and preview controls. It does not prove how LinkedIn, Meta, or X handle the same resource.

How do I know whether the image is public?

Request the exact image URL without relying on a logged-in browser session, then check that it returns the intended image rather than an access-denied page or a protected resource.

How long should I wait for LinkedIn to update a preview?

LinkedIn advises allowing 48 hours after the last share or tag update for cached content to refresh. Other platforms may differ.