og image not showing: 3 of 27 declared files on 30 homepages break a preview rule

FIELD TEST · 2026-09-27 · 30 homepages + 6 own sites · single crawl

Sample and method: 30 homepages and the six sites we run, fetched once each on 27 September 2026 with curl, a desktop Chrome user agent, redirects followed and no JavaScript. We read the declared og:image out of the returned HTML, then fetched that URL and read the real file: its status, its content type and its pixel dimensions.

og image not showing is, on this panel, rarely the tag's fault. Of the 28 homepages that answered, 27 declare an og:image, and three of those 27 files break a rule a share preview enforces: one URL returns a 404, one serves an SVG, and one is a 9.4 MB animated GIF. The tag is present on all three. The file behind it is the problem.

How we measured it

Fixed before the crawl, unchanged after.

1. Request https://<domain>/ once, follow redirects, browser user agent, keep the body.
2. Read every <meta> and keep the first og:image, plus og:image:width and og:image:height if present.
3. Fetch that exact URL and record the HTTP status, the Content-Type and the file size.
4. Read the real pixel dimensions from the downloaded file header, and compare them with any declared dimensions.

One rule kept the panel honest. A page that answered 200 with a challenge shell instead of a homepage was not counted. Two sites, medium.com and nytimes.com, returned 403 and were dropped, leaving 28 of 30.

og image not showing: what the 27 declared files returned

Twenty-four of the 27 files are a JPEG or a PNG that answered 200. Three are not, and each one fails against a rule written down by a platform that has to render the preview.

Each of the first three maps to a documented rule. Meta's sharing image documentation asks that a file "must not exceed 8 MB", and the 9.4 MB GIF is over that line. X's cards reference states plainly that "SVG is not supported" and that only "the first frame of an animated GIF will be used", which covers two of the three. A 404 needs no rule at all.

The last two rows are not failures, they are mismatches. Supabase declares 800 × 600 and serves a file that is 1200 × 600; Wikipedia's logo is 250 × 229, close to the 200 × 200 floor and far from the 1200 × 630 that fills a wide card. Of the 27 declared files, eight are exactly 1200 × 630.

Our own sites are in the same crawl, and two of them are the worst offenders. biaojixia.com and querywin.com declare no og:image on the homepage at all. Two more, byerisk.com and sizemarker.com, serve a clean 1200 × 630 PNG.

What to check when a preview does not show the image

The tag is the easy part, and it is almost never the reason. Work down this list instead.

1. Fetch the og:image URL itself. It must answer 200 with an image content type. A 404 here is invisible in the page source, which is why this step is first.
2. Use a JPEG or a PNG. The card specifications are written around raster images. An SVG is a document, not a raster image, and the X reference rules it out by name.
3. Stay under the size ceiling and near 1200 × 630. Meta documents a 200 × 200 minimum, a 1200 × 630 recommendation and an 8 MB cap; a 9.4 MB file is a preview that never loads.
4. Use an absolute HTTPS URL. Every declaration on this panel was absolute, so this one is not the field's problem — but a relative path is still a common cause elsewhere.
5. If it still does not show, suspect the platform cache. Every major platform caches the card and fetches it back on demand; re-crawling through its debugger is the fix, not editing the tag again.

A missing preview is a broken file far more often than a missing tag.

What this measurement cannot tell us is whether a particular platform actually refused to render one of these three. We fetched the URLs and read what they returned; we did not run a share debugger to watch a card fail. That is the limitation of the piece, and it is the reason we report the file facts rather than a count of broken previews.

Common questions

Why is my og image not showing?

Usually the file, then the cache, then the tag. Check that the URL returns an image with a 200, that it is a raster format, and that it is not oversized. If the file is fine, ask the platform to re-fetch the page.

What size should an og:image be?

Meta's sharing image guidance asks for at least 200 × 200 pixels, recommends 1200 × 630 for high-resolution displays, and caps the file at 8 MB. A 1.91:1 ratio fills a wide card without cropping. On this panel, eight of the 27 declared files were exactly 1200 × 630.

Does og:image affect SEO?

Not as a ranking input, and no Google documentation describes it as one. It affects the card that people see when the page is shared, which is a click-through question rather than a ranking one. Treat a working preview as a distribution fix.

Does Twitter use og:image?

It falls back to it. X's cards reference lists og:image in the Open Graph column for its own image tag, so a page with only og:image and no twitter:image still gets a card.

How did you measure this?

One request per homepage on 27 September 2026, desktop Chrome user agent, redirects followed. We read the first og:image from the returned HTML, fetched that URL, and read the status, content type and dimensions from the response. Two homepages returned 403 and were dropped. We did not open any platform debugger.

The pattern is worth more than the percentage: a declared tag proves nothing about the file behind it. The same gap shows up one level out, in the open graph tag survey, where completeness was counted but the files were not fetched, and the sizes recommended here are the subject of open graph image size. The og:url side has its own check in og url versus canonical, and turning all of it into a page you actually ship is the part QueryWin works on.