Pages with no og:image render as blank cards when shared
why does my link show a blank preview when shared on social media Yes - a blank share card happens because the page has no og:image or twitter:image meta tag, or the tag points at a URL that 404s, redirects, or serves over http on an https page. The fix is a static or generated 1200x630 HTTPS image with explicit width and height meta tags. Confirm with `curl -sI` on the resolved image URL.
Seen in 28 of 450 scanned projects (6%). Measured across pages scanned for Open Graph and Twitter Card meta tags with live image resolution checks.
How to tell you have it
- Slack, X, and LinkedIn previews show a gray placeholder or no image at all
- og:image tag is present but points at a small logo instead of a wide card
- the image URL resolves through a redirect or a locale prefix
- share cards look fine on desktop testing but break for other users
- an edited page keeps showing its old preview image for weeks after a change
Why it matters
A social share card is often the first and only impression a link gets before someone decides to click. When og:image is missing, most platforms either fall back to a generic site logo or render nothing, and the post looks broken or untrustworthy next to competitors whose links show a full illustrated card. This is a conversion problem disguised as a metadata problem.
Even when a tag exists, platforms fetch it with their own crawler and do not follow client-side redirects the way a browser does. An og:image value that points through a locale-prefixed URL or a URL that 302s to a CDN often fails silently, and the scraper caches that failure. The page owner never sees the broken state because their own browser resolves the redirect fine.
Serving the image over http while the rest of the site is https triggers mixed-content rejection on strict crawlers, and some platforms refuse to fetch it at all. Similarly, shipping a square 300x300 logo as the og:image produces a cropped or oddly centered card on large-summary layouts that expect a 1200x630 aspect ratio, since no width or height meta tag was declared to hint the correct crop.
A global cache-buster constant, or no cache busting at all, means that once a platform has scraped and cached a preview it can stay stale for up to a year even after the underlying page and its intended image change. Marketing pushes a new campaign image and the old one keeps showing on every re-share, which quietly undermines the update.
How Heygents detects it
Deep Scan fetches the rendered HTML of representative pages and checks for og:image and twitter:image meta tags, then runs curl -sI against the resolved image URL to confirm it returns 200 with an image content-type over https rather than a 400, a redirect, or plain http.
How to fix it
- Confirm the current state with a live request Before changing anything, resolve the exact URL the crawler will hit and check the response code, content type, and protocol.
- Add explicit, absolute meta tags per page Every indexable page needs its own og:image and twitter:image, as absolute HTTPS URLs, plus width and height so platforms do not guess the crop.
- Generate a real 1200x630 card instead of reusing the logo A dedicated share-image route or build step should render title text over a branded background at the correct aspect ratio, not resize the site logo.
- Bust the cache per page, not globally Append a version or content-hash query param that changes only when that page's image actually changes, instead of one shared constant that never updates or that invalidates every page at once.
- Force social platforms to re-scrape after a fix Use each platform's card debugger to purge the cached preview once the URL and image are corrected, since a version bump on the URL alone does not always invalidate an old cached card immediately.
Confirm the current state with a live request
curl -sI https://example.com/blog/post-slug | grep -i og:image
curl -sI https://example.com/og/post-slug.pngAdd explicit, absolute meta tags per page
<meta property="og:image" content="https://example.com/og/post-slug.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:secure_url" content="https://example.com/og/post-slug.png" />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:image" content="https://example.com/og/post-slug.png" />Generate a real 1200x630 card instead of reusing the logo
// pages/api/og/[slug].js style handler
export default async function handler(req, res) {
const { slug } = req.query;
const png = await renderCard({ title: getTitleFor(slug), width: 1200, height: 630 });
res.setHeader('Content-Type', 'image/png');
res.setHeader('Cache-Control', 'public, max-age=3600, s-maxage=86400');
res.send(png);
}Bust the cache per page, not globally
<meta property="og:image" content="https://example.com/og/post-slug.png?v=2026-07-14" />Find this in your own projects, automatically
Heygents runs a read-only Deep Scan across every project you own, finds issues like this one, and hands you a ready-to-run fix an AI agent can execute and verify. A solo developer gets the audit, the backlog and the fix loop in one place.
Open Heygents →Frequently asked questions
Why does the preview work in my browser but not when shared?
Social crawlers use their own fetcher that does not execute client-side JavaScript and does not always follow redirects the way a browser tab does. If og:image points at a URL that only resolves correctly after a client-side redirect or locale routing, the crawler sees a failure while you see a working page.
What is the correct og:image size?
1200x630 pixels is the safe default across Facebook, LinkedIn, and X for a large-summary card, with a roughly 1.91:1 aspect ratio. Declare og:image:width and og:image:height explicitly so platforms do not have to guess or fall back to a smaller default crop.
Can I just use my site logo as the og:image?
You can, but a square logo on a wide card gets cropped or letterboxed and looks unfinished. A purpose-built 1200x630 image with the page title or product screenshot performs better and looks intentional rather than like a missing asset. Re-run the check after deploying to confirm the fetched image now returns a 200 with an image content type.
Why is my updated image not showing after I changed it?
Most platforms cache a scraped preview for days or longer. If the image URL itself did not change, the crawler has no reason to refetch it. Add a per-page version query parameter and re-run the platform's card debugger to force a fresh fetch.