You paste a URL into LinkedIn / X / Slack / Telegram / WhatsApp and the preview card either renders with no image or shows an old image you replaced weeks ago.
Fastest fix (covers ~70% of cases): open the page in LinkedIn’s Post Inspector or Facebook’s Sharing Debugger, read the og:image value it shows, and check two things. (1) Does it start with https:// (an absolute URL) rather than /? (2) Did the crawler actually fetch the image (no error, real preview)? If the value is a relative path, make it absolute and re-scrape. If the value is correct but the preview is stale, click Scrape Again to bust the cache.
OG failures cluster into three groups: meta tags written incorrectly (almost always a relative path), the image itself not meeting a platform’s requirements (size, format, file size), or the platform serving a cached crawl that can be days old. This article ranks 5 causes by hit rate and walks the fix from debugger inspection to a forced re-scrape. All limits below are current as of June 2026.
Common causes
Ordered by hit rate, highest first.
1. og:image uses a relative path
Social-media crawlers don’t resolve relative paths — they take whatever string is in content and try to fetch it as-is. <meta property="og:image" content="/og.png"> renders fine in the browser but the crawler gets a string it can’t fetch.
<!-- Wrong: relative path, crawlers fail -->
<meta property="og:image" content="/og/article-slug.png" />
<!-- Right: must be an absolute URL with protocol -->
<meta property="og:image" content="https://yourdomain.com/og/article-slug.png" />
How to spot it: LinkedIn Post Inspector / Facebook Sharing Debugger / opengraph.dev shows the og:image field starting with / instead of https://.
2. Image dimensions / ratio don’t meet platform requirements
Each platform has a hard minimum size and an aspect-ratio target. Below the absolute floor the image is dropped; between the floor and the recommended size you usually get a small thumbnail or a heavily cropped card instead of a large one. Sizes below are current as of June 2026:
| Platform | Recommended | Absolute minimum | Aspect ratio |
|---|---|---|---|
| Facebook / LinkedIn | 1200×630 | 200×200 (Facebook); LinkedIn drops anything below ~1200 wide to a small thumbnail | 1.91:1 |
Twitter / X (summary_large_image) | 1200×628 | 300×157 | ~1.91:1 |
| Slack | 1200×630 | 600×600 | loose |
| 1200×630 | 100×100 (below this, no preview image at all) | 1.91:1 | |
| any, prefers 5:4 | 300×300 | — |
The single dimension that works everywhere is 1200×630 at 1.91:1. Facebook will technically render down to 200×200, but to get the large-format card (not a tiny left-aligned thumbnail) you need at least 600×315, and 1200×630 to look sharp on high-DPI screens.
How to spot it: Debugger error Image size is too small, a preview that shows only title + description with no image, or a small square thumbnail instead of a wide banner.
3. Social platform cached an old crawl
Platforms cache crawl results so they don’t re-fetch on every share. As of June 2026: LinkedIn caches roughly 7 days, Facebook keeps the last scrape until you force a refresh, and X re-reads when a URL is re-submitted to the validator. You updated og:image but shares still show the old one because the cache hasn’t expired.
One LinkedIn gotcha to know up front: re-scraping in Post Inspector only updates the preview for new posts. Posts that already contain the link keep their old card. So fix the tag, re-scrape, then share fresh — editing the old post won’t help.
How to spot it: Debugger shows “Last scraped: 5 days ago” or a similar timestamp; a brand-new URL previews correctly on first share but an updated URL still shows the old image.
4. Image URL requires auth or has CORS restrictions
og:image points at a CDN that needs a cookie / token / referrer (e.g. signed Cloudinary URLs), or the origin sets Access-Control-Allow-Origin rules that exclude the social crawler’s UA.
How to spot it:
curl -A "facebookexternalhit/1.1" -I "https://yourdomain.com/og/article.png"
# Expect 200 + image/png; a 403 / 401 / redirect to login means it's gated
5. File format / size out of bounds
Stick to PNG or JPEG. GIF, SVG, and WebP aren’t universally supported across crawlers (SVG in particular is rejected by most, and animated GIFs get a single, often ugly, frame). On file size, Facebook’s documented hard cap is 8MB and LinkedIn / X sit around 5MB, but the practical ceiling is much lower: the crawlers time out on slow origins long before 8MB, so target under 300KB and treat 1MB as the upper bound.
ls -lh og.png # target < 300KB; over ~1MB risks crawler timeout
file og.png # expect: PNG image data, or JPEG image data
How to spot it: Debugger reports Unsupported image format or Image too large, or the fetch in step 3 succeeds in a browser but the crawler shows no image.
Shortest path to fix
Use each platform’s debugger to see exactly what the crawler is receiving, then fix targetedly.
Step 1: Run the page through each platform’s debugger
| Platform | URL |
|---|---|
https://developers.facebook.com/tools/debug/ | |
https://www.linkedin.com/post-inspector/ | |
| Twitter / X | The old cards-dev.twitter.com/validator no longer shows a preview (deprecated since 2022); it still logs whether X can read the card. For an actual preview, paste the URL into the X Tweet Composer, or use a third-party reader like opengraph.dev |
| Telegram | DM @WebpageBot and send the URL |
Paste your URL, then check:
- Is
og:imagean absolute URL (starts withhttps://)? - Is the previewed image correct?
- Are there any error messages? (Facebook prints them under “Warnings That Should Be Fixed”; LinkedIn prints them inline.)
Step 2: Verify the meta tags are complete and absolute
Minimum viable set:
<meta property="og:title" content="Article title" />
<meta property="og:description" content="One-sentence summary" />
<meta property="og:image" content="https://yourdomain.com/og/article.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="Describe the image in a few words" />
<meta property="og:url" content="https://yourdomain.com/articles/article-slug/" />
<meta property="og:type" content="article" />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:image" content="https://yourdomain.com/og/article.png" />
Two details that quietly fix “no image on the very first share”: og:image:width and og:image:height are not optional. When a brand-new URL is shared, the crawler hasn’t fetched the image yet, so it relies on those declared dimensions to decide whether to render a large card. Get them right (1200 and 630) and the first share shows the banner; omit them and the first share often falls back to no image until a later re-crawl.
In Astro / Next.js, force absolute URLs with a helper:
// src/lib/og.ts
const SITE = import.meta.env.PUBLIC_SITE_URL ?? "https://yourdomain.com";
export const absoluteOg = (path: string) =>
path.startsWith("http") ? path : `${SITE}${path.startsWith("/") ? "" : "/"}${path}`;
Step 3: Confirm the crawler can actually fetch the image
# Pull as the Facebook crawler
curl -A "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" \
-I "https://yourdomain.com/og/article.png"
# Expect:
# HTTP/2 200
# content-type: image/png
# content-length: under ~1000000 (1MB) ideally
A 403 / 401 / 302 means auth or routing is blocking the crawler. Make the path public: allowlist the crawler UA at the CDN, or move the image into the static public/ directory so no auth layer sits in front of it. The main crawler UAs to allow are facebookexternalhit, LinkedInBot, Twitterbot, Slackbot-LinkExpanding, and WhatsApp. While you’re here, confirm the page’s SSL certificate is valid; LinkedInBot and others abort on cert errors and return a blank preview.
Step 4: Force a re-scrape
Every debugger forces a fresh crawl:
- Facebook Debugger: paste URL → “Debug” → “Scrape Again”. If the old image still shows, click it a second time; Facebook frequently needs two passes before the cache updates.
- LinkedIn Post Inspector: paste URL → “Inspect” auto-rescrapes (cache ~7 days). Remember: this only fixes the card for posts shared after the re-scrape, not posts already published.
- Twitter / X: re-submit the URL to
cards-dev.twitter.com/validatorto force X to re-read the page (no preview is shown there anymore), then paste the URL into the Tweet Composer to see the refreshed card. - Telegram: DM
@WebpageBotthe URL, hit “refresh” in the reply.
For bulk refreshes, script the Facebook Graph API ?scrape=true:
curl -X POST "https://graph.facebook.com/?id=https://yourdomain.com/articles/foo&scrape=true&access_token=$FB_TOKEN"
Step 5: Re-export the image to spec if it’s the wrong size
Export at 1200×630 PNG or JPEG, target 300KB–1MB:
# ImageMagick one-liner
convert input.png -resize 1200x630^ -gravity center -extent 1200x630 -quality 85 og.png
# Or sharp (Node.js)
npx sharp-cli -i input.png -o og.png resize 1200 630 --fit cover
Avoid SVG (poor support) and GIF (animated frames usually pick an ugly still).
How to confirm it’s fixed
Don’t trust a single platform. Run these three checks in order:
- Crawler fetch: re-run the step-3
curl -A "facebookexternalhit/1.1" -Icommand and confirmHTTP/2 200pluscontent-type: image/png(orimage/jpeg). - Debugger preview: re-scrape in the Facebook Sharing Debugger and LinkedIn Post Inspector and confirm the wide banner renders, with
og:imageshown as a fullhttps://URL and no warnings. - Real share: post the link in a private channel (a personal Slack DM, a draft tweet in the X Composer, a test LinkedIn post) and visually confirm the large card. This is the only test that reflects exactly what a reader sees.
If the curl returns 200 and the debugger preview is correct but a real share is still wrong, the cause is almost always cache (cause 3) on that specific platform — re-scrape there and share a new post.
Prevention
- Standardize on 1200×630 PNG/JPG OG images, file size under 300KB (1MB hard ceiling); avoid SVG / GIF / WebP.
- Use a helper to coerce
og:imageandog:urlto absolute URLs so per-article authors can’t get it wrong. - Always emit
og:image:width,og:image:height, andog:image:altso the very first share of a new URL renders a large card. - Add a CI check that
curl -A facebookexternalhit ...fetches each new article’sog:imageand asserts 200 plus the correct content-type. - After publishing, immediately trigger a scrape in the Facebook and LinkedIn debuggers so the cache doesn’t block early shares.
- Auto-generate OG images from the article title (
@vercel/og,satori,puppeteer) so “forgot to add an image” can’t happen.
FAQ
Why does my OG image show in Slack but not on LinkedIn? Different caches and different minimums. Slack expands links aggressively and tolerates smaller images; LinkedIn caches ~7 days and downgrades anything under ~1200px wide to a small thumbnail or drops it. Re-scrape in Post Inspector and confirm the image is at least 1200×630.
I updated the image but the old one still appears. How do I force a refresh? The platform cached the previous crawl. Re-scrape in the Facebook Sharing Debugger (“Scrape Again”, sometimes twice) and LinkedIn Post Inspector. For LinkedIn, the refresh only applies to new posts, so share the link again after re-scraping rather than editing the existing post.
Does Twitter / X still have a card validator?
The page at cards-dev.twitter.com/validator still exists but stopped showing a preview back in 2022. It only logs whether X can read your card. To see the actual card, paste the URL into the Tweet Composer, or use a third-party reader like opengraph.dev.
My og:image returns 200 in the browser but the crawler shows no image. Why?
Browsers send your cookies and a normal user-agent; crawlers don’t. The image is likely behind auth, a signed-URL gate, a referrer check, or a UA-based CORS/firewall rule. Re-run the curl with -A "facebookexternalhit/1.1" — if you get a 403/401/302, allowlist the crawler UA at your CDN or move the image to a public static path.
What’s the one size that works on every platform? 1200×630 pixels, 1.91:1 aspect ratio, PNG or JPEG, under 300KB. It satisfies Facebook, LinkedIn, X, Slack, and WhatsApp without per-platform variants.
Related
- Canonical wrong after domain change
- Deploy succeeded but page still shows old content
- Static assets 404
Tags: #Hosting #Debug #Troubleshooting #SEO