OG Image Not Showing? Here's the Actual Debugging Checklist

Your og:image tag is in the page, it points to a real file, and yet the preview card that renders when you paste the link shows no image at all — just a title, maybe a description, and blank space where the picture should be. This is one of the more frustrating classes of bug because everything looks correct at a glance. The fix is almost never guesswork; it's working down a fixed list of things crawlers check that browsers don't, in the order they're most likely to be the culprit.

Start with the raw HTML, not the rendered page

The single most common reason an og:image isn't showing is that it was never in the HTML response the crawler received. Right-click and 'View Page Source' — not the browser's DevTools Elements panel, which shows the DOM after JavaScript has run. Most social crawlers (Facebook's, LinkedIn's, and most others) fetch a page once and parse the raw response; they do not execute client-side JavaScript. If your og:image tag is injected by a React component after hydration, or added via a client-side SEO library that patches the document head at runtime, the crawler never sees it. The browser tab looks perfect. The scrape is empty.

If you're using a framework with server-side rendering or static generation, confirm the meta tags are actually part of the server-rendered output and not deferred to a client component. This is a common mistake when a metadata helper gets called inside a component that's marked for client-side rendering rather than in the page's server-rendered head.

Confirm the tag syntax is exactly right

Once you've confirmed the tag exists in the raw response, check its shape. It needs to be a meta tag with property="og:image" (not name="og:image" — that's a common copy-paste error from mixing up Open Graph's property attribute with the name attribute used by standard meta tags) and a content attribute holding the URL. A missing quote, a stray line break inside the tag, or the tag being placed outside the head element can all cause a parser to silently skip it rather than throw a visible error anywhere you'd notice.

The URL has to be absolute and publicly reachable

og:image content must be a full URL starting with https:// (or http://, though https is effectively required by most platforms now). A relative path like /assets/og.png works fine for an <img> tag rendered in a browser, because the browser resolves it against the current page's domain — but crawlers don't reliably do the same resolution, and a relative og:image is a frequent silent failure. Beyond that, the URL needs to load with no login required, no cookie-gated access, and no redirect chain longer than what the crawler is willing to follow. Test this by opening the exact image URL in a private browsing window with no session. If it doesn't load cleanly there, it won't load for the crawler.

Check robots.txt and hotlink protection

Two infrastructure-level blockers are easy to overlook because they don't affect anything a human notices while browsing the site normally. First, robots.txt rules scoped too broadly can disallow the path your images live under, which some crawlers respect even for asset fetches, not just page crawls. Second, CDN or web server configurations with hotlink protection — rejecting image requests that don't carry an expected referer header — will reject a crawler's fetch outright, since crawlers typically don't send a referer that matches your own domain. If your images are served from a CDN with any kind of referer-based access control, add an explicit allowance for the fetching user agents of major platforms, or disable referer checking on the OG image path specifically.

Watch for size and format rejections

Some platforms silently drop an image rather than showing an error if it falls outside their accepted parameters. An image below roughly 200x200 pixels, a file over a platform's size cap (commonly in the 5-8MB range depending on the platform), or a format outside JPEG/PNG/WebP/GIF can all result in no image appearing, with no visible error anywhere in your own tooling. If your og:image is generated on demand — a dynamic template render, for instance — verify the output dimensions and file size are stable and within normal bounds, not occasionally producing an oversized or malformed file under certain inputs.

Rule out a timeout on a slow-generating image

Crawlers fetch on a short timeout, typically a few seconds. If your og:image points at an endpoint that renders the image on the fly — compositing text onto a template, for example — and that render occasionally takes too long under load, the crawler gives up and the share shows no image. This tends to be intermittent rather than constant, which makes it one of the harder issues to catch by testing manually a single time. If you've ruled out everything else and the failure seems to come and go, check the response time of the image URL directly, independent of the page it's embedded in.

Don't rule out a stale cache before you've actually changed anything

If the image was never showing to begin with, a cached scrape isn't your problem — you haven't published a working version for a cache to have captured. But if you fixed one of the issues above and the image still isn't showing when you re-test on a platform you've already shared the link on, that platform is very likely showing you its stored scrape from before the fix. Force a re-fetch (Facebook's Sharing Debugger has a 'Scrape Again' button; other platforms have their own equivalents) before concluding your fix didn't work.

The full checklist

1. View raw page source (not DevTools) and confirm og:image is present with property, not name
2. Confirm the content value is an absolute https:// URL, not a relative path
3. Open the image URL directly in a private/incognito window to confirm it loads with no auth
4. Check robots.txt isn't disallowing the image path or a fetching user agent
5. Check the image host isn't rejecting requests based on referer (hotlink protection)
6. Confirm the image is above minimum size, under the platform's file size cap, and in a supported format
7. If the image is generated on demand, check its response time isn't intermittently timing out
8. After any fix, force a re-scrape rather than trusting a platform's cached preview

Testing systematically instead of one platform at a time

A mistake worth avoiding: fixing an issue, testing it on a single platform, and assuming it's resolved everywhere. Each platform's crawler has slightly different tolerances — one might accept an image another rejects for being marginally under its minimum size, one might respect a robots.txt rule another ignores, one might follow a redirect chain another gives up on after fewer hops. If you've been debugging against Facebook's Sharing Debugger specifically, that only tells you what Facebook's crawler sees; it says nothing about whether the same page unfurls correctly on LinkedIn or renders a card at all on X. Building a habit of checking at least two or three platforms before considering an og:image issue fully resolved catches a meaningful share of 'fixed on one, still broken on another' cases that would otherwise resurface as a fresh complaint days later.

How useopengraph shortcuts this

Working through each of these by hand — viewing source, opening the image URL separately, checking headers — takes real time even once you know the list. useopengraph's OG image tooling generates images from templates with versioned, immutable render URLs, so the image itself is never the intermittent, on-demand-render problem described above: once a template version is published, its output at that URL never changes, and the render is already generated rather than computed live on each crawler request. Combined with the built-in scanner that fetches a page the way a crawler does and reports exactly which check is failing, most 'og image not showing' cases get diagnosed in one pass instead of a manual walk through eight separate checks.