OG Image Not Showing: 8 of My 149 Pages Have None

Bluesky's link-card service told me my own blog index has no image. I had been checking article pages and assuming the rest of the site matched them. A plain GET to cardyb.bsky.app/v1/extract for https://picklog.cc/blog/ came back 200 with a title, a description, and "image":"".

So I audited everything. 149 built HTML files, 141 with an og:image, 8 without, and every single one of the 141 is WebP. Below is what I measured, in the order I would now check a preview that refuses to render.

Gate 1: the page may have no image tag at all

Parsing the built tree found 8 pages with no og:image element: /, /blog/, /about, /contact, /privacy, the 404 page, and two utility pages. I re-checked the five public ones live rather than trusting the files on disk, and all five return HTTP 200 with zero og:image tags.

The distribution is the annoying part. Article pages are generated by a template that emits the card, so they all have one. The hand-maintained pages were written before that template existed and never picked it up. Those hand-maintained pages are exactly the URLs a person pastes into a chat window, while the 141 that render correctly are mostly reached through search. My preview coverage is inverted relative to how links actually get shared.

Gate 2 and 3: check that the crawler is not being blocked

Before blaming a format, confirm the fetch works. I ran 18 crawler user agents against one article page and against its image: facebookexternalhit, facebookcatalog, Twitterbot, Slackbot-LinkExpanding, Slackbot, Discordbot, LinkedInBot, WhatsApp, TelegramBot, Mastodon's http.rb, Bluesky Cardyb, redditbot, Iframely, Embedly, Googlebot, bingbot, Applebot and GPTBot.

All 36 requests returned 200. The page was 24,767 bytes every time, the image 21,288 bytes with content-type: image/webp. That rules the fetch out for this site, which matters because it is a real cause elsewhere: my own origin already returns 403 to Python urllib because of a legacy user-agent blocklist, and a blocklist that catches a preview bot produces exactly the symptom people describe.

Every card on this site is WebP

I fetched all 141 images from storage and decoded them with Pillow. The uniformity is total, which is what you get when one script generates OG images with Python Pillow and nothing else ever writes to that bucket.

Size is not my problem, then. Format might be, and answering that turned out to be much harder than measuring my own files.

What the platforms actually document

I went looking for an official statement of accepted image formats from eight destinations: Meta (which covers Facebook, Messenger and WhatsApp), LinkedIn, X, Slack, Discord, Telegram, Mastodon and Bluesky. Where prose documentation gave nothing I read the implementation instead. Two of the eight produce a real format list, and neither of them puts it in documentation.

Meta's sharing image guide is precise about everything except the thing being asked. It says "The minimum allowed image dimension is 200 x 200 pixels" and "The size of the image file must not exceed 8 MB", and it even specifies that "Our crawler only accepts gzip and deflate encodings", but it never names a single image format. LinkedIn's help page gives "Max file size: 5 MB", "Minimum image dimensions: 1200 (w) x 627 (h) pixels" and "Recommended ratio: 1.91:1", and stops there. Slack's unfurling reference says it reads OpenGraph and X Card metadata without specifying anything about the image.

The two answers come from code. Mastodon's preview_card.rb declares IMAGE_MIME_TYPES = ['image/jpeg', 'image/png', 'image/gif', 'image/webp'] next to LIMIT = 8.megabytes. Bluesky's external embed lexicon declares "accept": ["image/*"] with "maxSize": 1000000. That million-byte ceiling is the tightest cap of the four numbers in the table by a factor of five, and it is the one you are least likely to stumble across, because it lives in a schema file rather than a docs page. Discord's position is public but sideways: an engineering post announcing that "You can now share animated WebP and AVIF content through attachments and embeds", which is not the same artifact as a specification.

The one preview I could watch end to end

Bluesky exposes its card extractor as an open HTTP endpoint, so it is the only destination here where I could observe the full path instead of reading about it. The extract call returns JSON pointing at a proxy URL, and fetching that proxy gave back 21,288 bytes of image/webp with md5 5cf43e8c4cfa599a53abb052e50190e7, byte-identical to the file on my origin. Bluesky accepts the WebP and does not re-encode it.

The proxy also has a quirk worth knowing if you ever debug one of these: a HEAD to the same proxy URL returns 404 with a JSON content type while a GET returns 200 and the image. I reproduced that twice, interleaved with successful GETs. Anyone probing preview infrastructure with curl -I would conclude the image is missing when it is being served fine.

A cache header that changes with the HTTP method

My own origin has a version of the same trap. Asking for a thumbnail with HEAD returns cache-control: no-cache; asking for the identical URL with GET, in the same minute, returns cache-control: public, max-age=31536000, immutable. I reproduced it across three user agents and two different images, and the upload script sets the immutable value explicitly, so the year-long value is the intended one.

This matters for previews because it decides how long a mistake survives. A platform that caches for a year will keep serving a wrong card long after the file is fixed, and platforms differ on whether they honour these headers at all. It is also a direct follow-on from what I found earlier about Supabase Storage cache-control, and it sits on the same bucket where I previously found x-robots-tag on public files behaving unexpectedly. I have observed the difference; I have not established where in the stack it is introduced.

What I have not fixed

The 8 pages still have no og:image as I publish this. The card generator already exists and the images are 21 KB, so this is template wiring rather than work. The open question is the second one: whether to stay WebP-only when half the destinations I checked decline to say what they accept, or emit a PNG twin and stop guessing. I am inclined to add the PNG, on the grounds that a 25 KB duplicate costs nothing and the documentation is not going to improve.

Sources and method: the site audit parsed all 149 built HTML files and then fetched and decoded all 141 images with Pillow on 2026-08-15, and the five public pages listed as having no og:image were re-checked live and returned 200 with zero og:image tags. The 18-user-agent probe ran from one machine in Seoul inside one hour against a single article page and a single image, so it shows those crawlers are not blocked here rather than anything general. Bluesky is the only platform whose extraction I watched end to end. I have no accounts or debugger tokens for Facebook, Messenger, WhatsApp, LinkedIn, Slack, X, Discord or Telegram, so I never saw a rendered preview on any of them, and the platform table is a documentation audit rather than a behaviour test: a blank cell means I could not find a format list in official material, which is not the same as a format being rejected. I cite nothing for X because developer.x.com serves the card page as a client-rendered shell that returns 200 with the spec text absent, and the Wayback snapshot returned 503 on three attempts. Discord's statement comes from an engineering blog about attachments and embeds, and Mastodon's list is from main as read today while instances run older versions. The HEAD and GET header difference is an observation without an established mechanism. One number from my own audit was wrong and never reached this article: the first pass reported a missing x-robots-tag on all 141 images, which was a header-casing bug in my script, and curl confirms the header is present. Nothing described here has been fixed.